of functions returning domain types, update documentation for typtype,
move get_typtype to lsyscache.c (actually, resurrect the old version),
add defense against creating pseudo-typed table columns, fix some
bogus list-parsing in grammar.  Issues remain with respect to alias
handling and type checking; Joe is on those.

 location feature.

in checkretval about which paths are for base or complex return type.

types for Table Functions, as previously proposed on HACKERS. Here is a
brief explanation:

1. Creates a new pg_type typtype: 'p' for pseudo type (currently either
     'b' for base or 'c' for catalog, i.e. a class).

2. Creates new builtin type of typtype='p' named RECORD. This is the
     first of potentially several pseudo types.

3. Modify FROM clause grammer to accept:
     SELECT * FROM my_func() AS m(colname1 type1, colname2 type1, ...)
     where m is the table alias, colname1, etc are the column names, and
     type1, etc are the column types.

4. When typtype == 'p' and the function return type is RECORD, a list
     of column defs is required, and when typtype != 'p', it is
disallowed.

5. A check was added to ensure that the tupdesc provide via the parser
     and the actual return tupdesc match in number and type of
attributes.

When creating a function you can do:
     CREATE FUNCTION foo(text) RETURNS setof RECORD ...

When using it you can do:
     SELECT * from foo(sqlstmt) AS (f1 int, f2 text, f3 timestamp)
       or
     SELECT * from foo(sqlstmt) AS f(f1 int, f2 text, f3 timestamp)
       or
     SELECT * from foo(sqlstmt) f(f1 int, f2 text, f3 timestamp)

Included in the patches are adjustments to the regression test sql and
expected files, and documentation.

p.s.
     This potentially solves (or at least improves) the issue of builtin
     Table Functions. They can be bootstrapped as returning RECORD, and
     we can wrap system views around them with properly specified column
     defs. For example:

     CREATE VIEW pg_settings AS
       SELECT s.name, s.setting
       FROM show_all_settings()AS s(name text, setting text);

     Then we can also add the UPDATE RULE that I previously posted to
     pg_settings, and have pg_settings act like a virtual table, allowing
     settings to be queried and set.


Joe Conway

 Can now do queries of the form: SELECT value IS OF (integer, float8);
Define macros for handling typmod manipulation for date/time types.
 Should be more robust than all of that brute-force inline code.
Rename macros for masking and typmod manipulation to put TIMESTAMP_
 or INTERVAL_ in front of the macro name, to reduce the possibility
 of name space collisions.
Allow bit string constants without fully-specified length declaration.
Try implementing CREATE TABLE/OF as a mapping to inheritance.
 May be appropriate, or may be replace later with something more exactly
 like one might expect from databases without the feature.

 select value IS OF (integer, float8);

 strings. Should go back in and look at doing this a bit more elegantly
 and (hopefully) cheaper. Probably not too bad anyway, but it seems a
 shame to scan the strings twice: once for length for this buffer overrun
 protection, and once to parse the line.
Remove use of pow() in date/time handling; was already gone from everything
 *but* the time data types.
Define macros for handling typmod manipulation for date/time types.
 Should be more robust than all of that brute-force inline code.
Rename macros for masking and typmod manipulation to put TIMESTAMP_
 or INTERVAL_ in front of the macro name, to reduce the possibility
 of name space collisions.

 Should be more robust than all of that brute-force inline code.
Rename macros for masking and typmod manipulation to put TIMESTAMP_
 or INTERVAL_ in front of the macro name, to reduce the possibility
 of name space collisions.

 May not be the long-term solution (some continuing discussion with
 Peter E.) but better than the current mapping of a conversion to integer
 which I'd put in years ago before we had any bit string types at all.
This is already supported in the bit string implementation elsewhere.

Implement conversion between 8-byte integers and bit strings.
 Similar to what is done for 4-byte integers.

Which was true when he submitted it, but is so no longer.

>       please find attached patch to current CVS ( contrib/ltree)
>       Version for 7.2 is distributed as separate package -

I believe that patch also intended to remove contrib/ltree/patch.72

Please use this patch instead of my previously submitted one.

It is just remerged against HEAD for new alter_table.out stuff.

Another reason this patch is useful for _interactive_ users: imagine a
view based on a many way join.  Imagine creating a complicated insert
rule that inserts into all the joined tables and when you insert you get
a check failure, but you need to know which actual table the constraint
was on that failed!

Christopher Kings-Lynne

the statistics collector and makes a number of corrections to the
documentation for SET, SHOW, and COPY.

Neil Conway

ERROR:  ExecInsert: rejected due to CHECK constraint insert_con

To be like this:

ERROR:  ExecInsert: rejected due to CHECK constraint "insert_con" on
"insert_tbl"

Updated regression tests to match.

I got sick of seeing 'rejected due to CHECK constraint "$1" in my log and
not being able to find the bug in our website code...

Christopher Kings-Lynne

Neil Conway

Changes:

July 31, 2002
   Now works on 64-bit platforms.
   Added function lca - lowest common ancestor
   Version for 7.2 is distributed as separate package -
   http://www.sai.msu.su/~megera/postgres/gist/ltree/ltree-7.2.tar.gz

Oleg Bartunov

when compiling psql with GCC 3.1.

Neil Conway

functionality of the command is basically identical to that of
BEGIN; it just accepts a few extra options (only one of which
PostgreSQL currently implements), and is standards-compliant.
The patch includes a simple regression test and documentation.

[ Regression tests removed, per Peter.]

Neil Conway

there was a race condition between the "alter_table" and "rules"
regression tests. Depending on scheduling, sometimes an ALTER
TABLE command would operate on a relation created by the "rules"
tests, leading to unexpected results.

Neil Conway

Neil Conway

whitespaces in identifers of any kind(table names,attribute
names,variables ...) in Pl/pgSQL procedural language.Explicit definition
of bug can be found in Re: [HACKERS] Bug of PL/pgSQL parser

TODO item completed:

        o -Fix PL/PgSQL to handle quoted mixed-case identifiers

eutm

functions. If there are no objections, please apply.

Joe Conway