1
0
mirror of https://github.com/postgres/postgres.git synced 2025-11-16 15:02:33 +03:00
Files
postgres/src/backend/parser
Bruce Momjian 9218689b69 Attached are two patches to implement and document anonymous composite
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
2002-08-04 19:48:11 +00:00
..
2002-04-20 21:56:15 +00:00
2002-06-20 20:29:54 +00:00
2002-06-20 20:29:54 +00:00
2002-06-20 20:29:54 +00:00
1998-08-23 14:43:46 +00:00
2002-06-20 20:29:54 +00:00

This directory does more than tokenize and parse SQL queries.  It also
creates Query structures for the various complex queries that is passed
to the optimizer and then executor.

parser.c	things start here
scan.l		break query into tokens
scansup.c	handle escapes in input
keywords.c	turn keywords into specific tokens
gram.y		parse the tokens and fill query-type-specific structures
analyze.c	handle post-parse processing for each query type
parse_clause.c	handle clauses like WHERE, ORDER BY, GROUP BY, ...
parse_coerce.c	used for coercing expressions of different types
parse_expr.c	handle expressions like col, col + 3, x = 3 or x = 4
parse_oper.c	handle operations in expressions
parse_agg.c	handle aggregates, like SUM(col1),  AVG(col2), ...
parse_func.c	handle functions, table.column and column identifiers
parse_node.c	create nodes for various structures
parse_target.c	handle the result list of the query
parse_relation.c support routines for tables and column handling
parse_type.c	support routines for type handling