"version()", not "version".

Neil Conway

results due to doing arithmetic on uninitialized values.  Add some
documentation about the AT TIME ZONE construct.  Update some other
date/time documentation that seemed out of date for 7.3.

Also, code < and > as &lt;/&gt; for cleaner SGML.

document that scheme.

the SQL99 standard.  (I'm not sure that the character-class features are
quite right, but that can be fixed later.)  Document SQL99 and POSIX
regexps as being different features; provide variants of SUBSTRING for
each.

Rod Taylor

 > Hannu Krosing wrote:
 >
 >> It seems that my last mail on this did not get through to the list
 >> ;(
 >>
 >> Please consider renaming the new builtin function
 >> split(text,text,int)
 >>
 >> to something else, perhaps
 >>
 >> split_part(text,text,int)
 >>
 >> (like date_part)
 >>
 >> The reason for this request is that 3 most popular scripting
 >> languages (perl, python, php) all have also a function with similar
 >> signature, but returning an array instead of single element and the
 >> (optional) third argument is limit (maximum number of splits to
 >> perform)
 >>
 >> I think that it would be good to have similar function in (some
 >> future release of) postgres, but if we now let in a function with
 >> same name and arguments but returning a single string instead an
 >> array of them, then we will need to invent a new and not so easy to
 >> recognise name for the "real" split function.
 >>
 >
 > This is a good point, and I'm not opposed to changing the name, but
 > it is too bad your original email didn't get through before beta1 was
 >  rolled. The change would now require an initdb, which I know we were
 >  trying to avoid once beta started (although we could change it
 > without *requiring* an initdb I suppose).
 >
 > I guess if we do end up needing an initdb for other reasons, we
 > should make this change too. Any other opinions? Is split_part an
 > acceptable name?
 >
 > Also, if we add a todo to produce a "real" split function that
 > returns an array, similar to those languages, I'll take it for 7.4.

No one commented on the choice of name, so the attached patch changes
the name of split(text,text,int) to split_part(text,text,int) per
Hannu's recommendation above. This can be applied without an initdb if
current beta testers are advised to run:

   update pg_proc set proname = 'split_part' where proname = 'split';

in the case they want to use this function. Regression and doc fix is
also included in the patch.

Joe Conway

Bruno Wolff III

replace, split, and to_hex. The patch also moves encode and decode into
alphabetical order (since everything else in the table was).

Joe Conway

Rename debug_print_query to log_statement and rename show_query_stats to
show_statement_stats.

>>" It's also possible to select no escape character by writing ESCAPE ''.
>>In this case there is no way to turn off the special meaning of
>>underscore and percent signs in the pattern."

Joe Conway

> > is a patch to add some cross-referencing.

Oliver Elphick

Add current_database().

> Quick system function to pull out the current database.
>
> I've used this a number of times to allow stored procedures to find out
> where they are.  Especially useful for those that do logging or hit a
> remote server.
>
> It's called current_database() to match with current_user().

It's also a necessity for an informational schema.  The catalog
(database) name is required in a number of places.

Rod Taylor

sets of triggers.  Also modify psql \d command to show foreign key
constraints as such and hide the triggers.  pg_get_constraintdef()
function added to backend to support these.  From Rod Taylor, code
review and some editorialization by Tom Lane.

Patches submitted by Kaori Inaba (i-kaori@sra.co.jp).

has_language_privilege, has_schema_privilege to let SQL queries test
all the new privilege types in 7.3.  Also, add functions pg_table_is_visible,
pg_type_is_visible, pg_function_is_visible, pg_operator_is_visible,
pg_opclass_is_visible to test whether objects contained in schemas are
visible in the current search path.  Do some minor cleanup to centralize
accesses to pg_database, as well.

functions. If there are no objections, please apply.

Joe Conway

as suggested by Josh Berkus.

Second cut attached. This one just adds a boolean option to the existing
function to indicate that implicit schemas are to be included (or not).
I remembered the docs as well this time :-)

Dave Page

Remove ODBC-compatible empty parentheses from calls to SQL99 functions
 for which these parentheses do not match the standard.
Update the ODBC driver to ensure compatibility with the ODBC standard
 for these functions (e.g. CURRENT_TIMESTAMP, CURRENT_USER, etc).
Include a new appendix in the User's Guide which lists the labeled features
 for SQL99 (the labeled features replaced the "basic", "intermediate",
 and "advanced" categories from SQL92). features.sgml does not yet split
 this list into "supported" and "unsupported" lists.

Implement SQL99 SIMILAR TO as a synonym for our existing operator "~".
Implement SQL99 regular expression SUBSTRING(string FROM pat FOR escape).
 Extend the definition to make the FOR clause optional.
 Define textregexsubstr() to actually implement this feature.
Update the regression test to include these new string features.
 All tests pass.
Rename the regular expression support routines from "pg95_xxx" to "pg_xxx".
Define CREATE CHARACTER SET in the parser per SQL99. No implementation yet.

I took the opportunity to remove the pg_proc.proistrusted field.

that we don't upcase the others.

Update has_table_privilege functions to cope with schema-qualified
names in the same way as nextval() and others.

DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause,
similar to TRIGGER syntaxes.  To allow loading of existing pg_dump
files containing COMMENT ON RULE, the COMMENT code will still accept
the old syntax --- but only if the target rulename is unique across
the whole database.