2002-06-18 02:28:11 +02:00
|
|
|
%{
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1996-11-28 06:46:08 +01:00
|
|
|
/*#define YYDEBUG 1*/
|
1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
1997-09-01 08:00:35 +02:00
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* gram.y
|
2009-07-12 19:12:34 +02:00
|
|
|
* POSTGRESQL BISON rules/actions
|
1997-09-01 08:00:35 +02:00
|
|
|
*
|
2023-01-02 21:00:37 +01:00
|
|
|
* Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*
|
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/parser/gram.y
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
* HISTORY
|
1997-09-08 05:20:18 +02:00
|
|
|
* AUTHOR DATE MAJOR EVENT
|
|
|
|
|
* Andrew Yu Sept, 1994 POSTQUEL to SQL conversion
|
|
|
|
|
* Andrew Yu Oct, 1994 lispy code conversion
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
* NOTES
|
1997-09-08 05:20:18 +02:00
|
|
|
* CAPITALS are used to represent terminal symbols.
|
|
|
|
|
* non-capitals are used to represent non-terminals.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2001-01-05 07:34:23 +01:00
|
|
|
* In general, nothing in this file should initiate database accesses
|
|
|
|
|
* nor depend on changeable state (such as SET variables). If you do
|
|
|
|
|
* database accesses, your code will fail when we have aborted the
|
|
|
|
|
* current transaction and are just parsing commands to find the next
|
|
|
|
|
* ROLLBACK or COMMIT. If you make use of SET variables, then you
|
|
|
|
|
* will do the wrong thing in multi-query strings like this:
|
2016-12-23 13:35:01 +01:00
|
|
|
* SET constraint_exclusion TO off; SELECT * FROM foo;
|
2001-01-05 07:34:23 +01:00
|
|
|
* because the entire string is parsed by gram.y before the SET gets
|
|
|
|
|
* executed. Anything that depends on the database or changeable state
|
2007-06-24 00:12:52 +02:00
|
|
|
* should be handled during parse analysis so that it happens at the
|
2016-12-23 13:35:01 +01:00
|
|
|
* right time not the wrong time.
|
2001-01-05 07:34:23 +01:00
|
|
|
*
|
|
|
|
|
* WARNINGS
|
|
|
|
|
* If you use a list, make sure the datum is a node so that the printing
|
|
|
|
|
* routines work.
|
|
|
|
|
*
|
|
|
|
|
* Sometimes we assign constants to makeStrings. Make sure we don't free
|
1997-09-08 05:20:18 +02:00
|
|
|
* those.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#include "postgres.h"
|
2000-09-12 23:07:18 +02:00
|
|
|
|
2001-01-05 07:34:23 +01:00
|
|
|
#include <ctype.h>
|
2002-11-13 01:44:09 +01:00
|
|
|
#include <limits.h>
|
2001-01-05 07:34:23 +01:00
|
|
|
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
#include "access/tableam.h"
|
2002-03-10 07:02:24 +01:00
|
|
|
#include "catalog/index.h"
|
2002-05-12 22:10:05 +02:00
|
|
|
#include "catalog/namespace.h"
|
2016-03-24 03:01:35 +01:00
|
|
|
#include "catalog/pg_am.h"
|
2009-06-18 03:27:02 +02:00
|
|
|
#include "catalog/pg_trigger.h"
|
2006-07-02 04:23:23 +02:00
|
|
|
#include "commands/defrem.h"
|
2012-07-18 16:16:16 +02:00
|
|
|
#include "commands/trigger.h"
|
2022-09-14 05:41:44 +02:00
|
|
|
#include "gramparse.h"
|
2002-03-29 20:06:29 +01:00
|
|
|
#include "nodes/makefuncs.h"
|
2008-09-01 22:42:46 +02:00
|
|
|
#include "nodes/nodeFuncs.h"
|
2009-07-12 19:12:34 +02:00
|
|
|
#include "parser/parser.h"
|
1998-12-18 10:10:39 +01:00
|
|
|
#include "storage/lmgr.h"
|
2002-04-21 21:21:49 +02:00
|
|
|
#include "utils/date.h"
|
2004-06-28 03:19:11 +02:00
|
|
|
#include "utils/datetime.h"
|
|
|
|
|
#include "utils/numeric.h"
|
2007-01-25 12:53:52 +01:00
|
|
|
#include "utils/xml.h"
|
2004-06-28 03:19:11 +02:00
|
|
|
|
1998-07-24 05:32:46 +02:00
|
|
|
|
2012-10-04 23:14:59 +02:00
|
|
|
/*
|
|
|
|
|
* Location tracking support --- simpler than bison's default, since we only
|
|
|
|
|
* want to track the start position not the end position of each nonterminal.
|
|
|
|
|
*/
|
2006-03-14 23:48:25 +01:00
|
|
|
#define YYLLOC_DEFAULT(Current, Rhs, N) \
|
2006-03-15 00:03:20 +01:00
|
|
|
do { \
|
2012-10-04 23:14:59 +02:00
|
|
|
if ((N) > 0) \
|
2006-03-15 00:03:20 +01:00
|
|
|
(Current) = (Rhs)[1]; \
|
|
|
|
|
else \
|
2012-10-04 23:14:59 +02:00
|
|
|
(Current) = (-1); \
|
2006-03-15 00:03:20 +01:00
|
|
|
} while (0)
|
2006-03-14 23:48:25 +01:00
|
|
|
|
2012-10-04 23:14:59 +02:00
|
|
|
/*
|
|
|
|
|
* The above macro assigns -1 (unknown) as the parse location of any
|
Change representation of statement lists, and add statement location info.
This patch makes several changes that improve the consistency of
representation of lists of statements. It's always been the case
that the output of parse analysis is a list of Query nodes, whatever
the types of the individual statements in the list. This patch brings
similar consistency to the outputs of raw parsing and planning steps:
* The output of raw parsing is now always a list of RawStmt nodes;
the statement-type-dependent nodes are one level down from that.
* The output of pg_plan_queries() is now always a list of PlannedStmt
nodes, even for utility statements. In the case of a utility statement,
"planning" just consists of wrapping a CMD_UTILITY PlannedStmt around
the utility node. This list representation is now used in Portal and
CachedPlan plan lists, replacing the former convention of intermixing
PlannedStmts with bare utility-statement nodes.
Now, every list of statements has a consistent head-node type depending
on how far along it is in processing. This allows changing many places
that formerly used generic "Node *" pointers to use a more specific
pointer type, thus reducing the number of IsA() tests and casts needed,
as well as improving code clarity.
Also, the post-parse-analysis representation of DECLARE CURSOR is changed
so that it looks more like EXPLAIN, PREPARE, etc. That is, the contained
SELECT remains a child of the DeclareCursorStmt rather than getting flipped
around to be the other way. It's now true for both Query and PlannedStmt
that utilityStmt is non-null if and only if commandType is CMD_UTILITY.
That allows simplifying a lot of places that were testing both fields.
(I think some of those were just defensive programming, but in many places,
it was actually necessary to avoid confusing DECLARE CURSOR with SELECT.)
Because PlannedStmt carries a canSetTag field, we're also able to get rid
of some ad-hoc rules about how to reconstruct canSetTag for a bare utility
statement; specifically, the assumption that a utility is canSetTag if and
only if it's the only one in its list. While I see no near-term need for
relaxing that restriction, it's nice to get rid of the ad-hocery.
The API of ProcessUtility() is changed so that what it's passed is the
wrapper PlannedStmt not just the bare utility statement. This will affect
all users of ProcessUtility_hook, but the changes are pretty trivial; see
the affected contrib modules for examples of the minimum change needed.
(Most compilers should give pointer-type-mismatch warnings for uncorrected
code.)
There's also a change in the API of ExplainOneQuery_hook, to pass through
cursorOptions instead of expecting hook functions to know what to pick.
This is needed because of the DECLARE CURSOR changes, but really should
have been done in 9.6; it's unlikely that any extant hook functions
know about using CURSOR_OPT_PARALLEL_OK.
Finally, teach gram.y to save statement boundary locations in RawStmt
nodes, and pass those through to Query and PlannedStmt nodes. This allows
more intelligent handling of cases where a source query string contains
multiple statements. This patch doesn't actually do anything with the
information, but a follow-on patch will. (Passing this information through
cleanly is the true motivation for these changes; while I think this is all
good cleanup, it's unlikely we'd have bothered without this end goal.)
catversion bump because addition of location fields to struct Query
affects stored rules.
This patch is by me, but it owes a good deal to Fabien Coelho who did
a lot of preliminary work on the problem, and also reviewed the patch.
Discussion: https://postgr.es/m/alpine.DEB.2.20.1612200926310.29821@lancre
2017-01-14 22:02:35 +01:00
|
|
|
* nonterminal that was reduced from an empty rule, or whose leftmost
|
|
|
|
|
* component was reduced from an empty rule. This is problematic
|
2012-10-04 23:14:59 +02:00
|
|
|
* for nonterminals defined like
|
|
|
|
|
* OptFooList: / * EMPTY * / { ... } | OptFooList Foo { ... } ;
|
|
|
|
|
* because we'll set -1 as the location during the first reduction and then
|
|
|
|
|
* copy it during each subsequent reduction, leaving us with -1 for the
|
|
|
|
|
* location even when the list is not empty. To fix that, do this in the
|
|
|
|
|
* action for the nonempty rule(s):
|
|
|
|
|
* if (@$ < 0) @$ = @2;
|
|
|
|
|
* (Although we have many nonterminals that follow this pattern, we only
|
|
|
|
|
* bother with fixing @$ like this when the nonterminal's parse location
|
|
|
|
|
* is actually referenced in some rule.)
|
Change representation of statement lists, and add statement location info.
This patch makes several changes that improve the consistency of
representation of lists of statements. It's always been the case
that the output of parse analysis is a list of Query nodes, whatever
the types of the individual statements in the list. This patch brings
similar consistency to the outputs of raw parsing and planning steps:
* The output of raw parsing is now always a list of RawStmt nodes;
the statement-type-dependent nodes are one level down from that.
* The output of pg_plan_queries() is now always a list of PlannedStmt
nodes, even for utility statements. In the case of a utility statement,
"planning" just consists of wrapping a CMD_UTILITY PlannedStmt around
the utility node. This list representation is now used in Portal and
CachedPlan plan lists, replacing the former convention of intermixing
PlannedStmts with bare utility-statement nodes.
Now, every list of statements has a consistent head-node type depending
on how far along it is in processing. This allows changing many places
that formerly used generic "Node *" pointers to use a more specific
pointer type, thus reducing the number of IsA() tests and casts needed,
as well as improving code clarity.
Also, the post-parse-analysis representation of DECLARE CURSOR is changed
so that it looks more like EXPLAIN, PREPARE, etc. That is, the contained
SELECT remains a child of the DeclareCursorStmt rather than getting flipped
around to be the other way. It's now true for both Query and PlannedStmt
that utilityStmt is non-null if and only if commandType is CMD_UTILITY.
That allows simplifying a lot of places that were testing both fields.
(I think some of those were just defensive programming, but in many places,
it was actually necessary to avoid confusing DECLARE CURSOR with SELECT.)
Because PlannedStmt carries a canSetTag field, we're also able to get rid
of some ad-hoc rules about how to reconstruct canSetTag for a bare utility
statement; specifically, the assumption that a utility is canSetTag if and
only if it's the only one in its list. While I see no near-term need for
relaxing that restriction, it's nice to get rid of the ad-hocery.
The API of ProcessUtility() is changed so that what it's passed is the
wrapper PlannedStmt not just the bare utility statement. This will affect
all users of ProcessUtility_hook, but the changes are pretty trivial; see
the affected contrib modules for examples of the minimum change needed.
(Most compilers should give pointer-type-mismatch warnings for uncorrected
code.)
There's also a change in the API of ExplainOneQuery_hook, to pass through
cursorOptions instead of expecting hook functions to know what to pick.
This is needed because of the DECLARE CURSOR changes, but really should
have been done in 9.6; it's unlikely that any extant hook functions
know about using CURSOR_OPT_PARALLEL_OK.
Finally, teach gram.y to save statement boundary locations in RawStmt
nodes, and pass those through to Query and PlannedStmt nodes. This allows
more intelligent handling of cases where a source query string contains
multiple statements. This patch doesn't actually do anything with the
information, but a follow-on patch will. (Passing this information through
cleanly is the true motivation for these changes; while I think this is all
good cleanup, it's unlikely we'd have bothered without this end goal.)
catversion bump because addition of location fields to struct Query
affects stored rules.
This patch is by me, but it owes a good deal to Fabien Coelho who did
a lot of preliminary work on the problem, and also reviewed the patch.
Discussion: https://postgr.es/m/alpine.DEB.2.20.1612200926310.29821@lancre
2017-01-14 22:02:35 +01:00
|
|
|
*
|
|
|
|
|
* A cleaner answer would be to make YYLLOC_DEFAULT scan all the Rhs
|
|
|
|
|
* locations until it's found one that's not -1. Then we'd get a correct
|
|
|
|
|
* location for any nonterminal that isn't entirely empty. But this way
|
|
|
|
|
* would add overhead to every rule reduction, and so far there's not been
|
|
|
|
|
* a compelling reason to pay that overhead.
|
2012-10-04 23:14:59 +02:00
|
|
|
*/
|
|
|
|
|
|
2008-09-02 22:37:55 +02:00
|
|
|
/*
|
|
|
|
|
* Bison doesn't allocate anything that needs to live across parser calls,
|
|
|
|
|
* so we can easily have it use palloc instead of malloc. This prevents
|
2022-09-06 06:41:58 +02:00
|
|
|
* memory leaks if we error out during parsing.
|
2008-09-02 22:37:55 +02:00
|
|
|
*/
|
|
|
|
|
#define YYMALLOC palloc
|
|
|
|
|
#define YYFREE pfree
|
|
|
|
|
|
2009-01-22 21:16:10 +01:00
|
|
|
/* Private struct for the result of privilege_target production */
|
|
|
|
|
typedef struct PrivTarget
|
|
|
|
|
{
|
2009-10-12 22:39:42 +02:00
|
|
|
GrantTargetType targtype;
|
2017-10-12 00:35:19 +02:00
|
|
|
ObjectType objtype;
|
2009-01-22 21:16:10 +01:00
|
|
|
List *objs;
|
|
|
|
|
} PrivTarget;
|
|
|
|
|
|
2014-07-10 21:01:31 +02:00
|
|
|
/* Private struct for the result of import_qualification production */
|
|
|
|
|
typedef struct ImportQual
|
|
|
|
|
{
|
|
|
|
|
ImportForeignSchemaType type;
|
|
|
|
|
List *table_names;
|
|
|
|
|
} ImportQual;
|
|
|
|
|
|
2020-04-07 22:22:13 +02:00
|
|
|
/* Private struct for the result of opt_select_limit production */
|
|
|
|
|
typedef struct SelectLimit
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
Node *limitOffset;
|
|
|
|
|
Node *limitCount;
|
2020-04-07 22:22:13 +02:00
|
|
|
LimitOption limitOption;
|
|
|
|
|
} SelectLimit;
|
|
|
|
|
|
Implement GROUP BY DISTINCT
With grouping sets, it's possible that some of the grouping sets are
duplicate. This is especially common with CUBE and ROLLUP clauses. For
example GROUP BY CUBE (a,b), CUBE (b,c) is equivalent to
GROUP BY GROUPING SETS (
(a, b, c),
(a, b, c),
(a, b, c),
(a, b),
(a, b),
(a, b),
(a),
(a),
(a),
(c, a),
(c, a),
(c, a),
(c),
(b, c),
(b),
()
)
Some of the grouping sets are calculated multiple times, which is mostly
unnecessary. This commit implements a new GROUP BY DISTINCT feature, as
defined in the SQL standard, which eliminates the duplicate sets.
Author: Vik Fearing
Reviewed-by: Erik Rijkers, Georgios Kokolatos, Tomas Vondra
Discussion: https://postgr.es/m/bf3805a8-d7d1-ae61-fece-761b7ff41ecc@postgresfriends.org
2021-03-18 17:45:38 +01:00
|
|
|
/* Private struct for the result of group_clause production */
|
|
|
|
|
typedef struct GroupClause
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
bool distinct;
|
|
|
|
|
List *list;
|
Implement GROUP BY DISTINCT
With grouping sets, it's possible that some of the grouping sets are
duplicate. This is especially common with CUBE and ROLLUP clauses. For
example GROUP BY CUBE (a,b), CUBE (b,c) is equivalent to
GROUP BY GROUPING SETS (
(a, b, c),
(a, b, c),
(a, b, c),
(a, b),
(a, b),
(a, b),
(a),
(a),
(a),
(c, a),
(c, a),
(c, a),
(c),
(b, c),
(b),
()
)
Some of the grouping sets are calculated multiple times, which is mostly
unnecessary. This commit implements a new GROUP BY DISTINCT feature, as
defined in the SQL standard, which eliminates the duplicate sets.
Author: Vik Fearing
Reviewed-by: Erik Rijkers, Georgios Kokolatos, Tomas Vondra
Discussion: https://postgr.es/m/bf3805a8-d7d1-ae61-fece-761b7ff41ecc@postgresfriends.org
2021-03-18 17:45:38 +01:00
|
|
|
} GroupClause;
|
|
|
|
|
|
2021-12-08 11:09:44 +01:00
|
|
|
/* Private structs for the result of key_actions and key_action productions */
|
|
|
|
|
typedef struct KeyAction
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
char action;
|
|
|
|
|
List *cols;
|
2021-12-08 11:09:44 +01:00
|
|
|
} KeyAction;
|
|
|
|
|
|
|
|
|
|
typedef struct KeyActions
|
|
|
|
|
{
|
|
|
|
|
KeyAction *updateAction;
|
|
|
|
|
KeyAction *deleteAction;
|
|
|
|
|
} KeyActions;
|
|
|
|
|
|
2011-06-16 01:05:11 +02:00
|
|
|
/* ConstraintAttributeSpec yields an integer bitmask of these flags: */
|
|
|
|
|
#define CAS_NOT_DEFERRABLE 0x01
|
|
|
|
|
#define CAS_DEFERRABLE 0x02
|
|
|
|
|
#define CAS_INITIALLY_IMMEDIATE 0x04
|
|
|
|
|
#define CAS_INITIALLY_DEFERRED 0x08
|
|
|
|
|
#define CAS_NOT_VALID 0x10
|
2012-07-24 21:49:54 +02:00
|
|
|
#define CAS_NO_INHERIT 0x20
|
2011-06-16 01:05:11 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2009-07-13 04:02:20 +02:00
|
|
|
#define parser_yyerror(msg) scanner_yyerror(msg, yyscanner)
|
|
|
|
|
#define parser_errposition(pos) scanner_errposition(pos, yyscanner)
|
|
|
|
|
|
2009-11-09 19:38:48 +01:00
|
|
|
static void base_yyerror(YYLTYPE *yylloc, core_yyscan_t yyscanner,
|
2009-07-13 04:02:20 +02:00
|
|
|
const char *msg);
|
Change representation of statement lists, and add statement location info.
This patch makes several changes that improve the consistency of
representation of lists of statements. It's always been the case
that the output of parse analysis is a list of Query nodes, whatever
the types of the individual statements in the list. This patch brings
similar consistency to the outputs of raw parsing and planning steps:
* The output of raw parsing is now always a list of RawStmt nodes;
the statement-type-dependent nodes are one level down from that.
* The output of pg_plan_queries() is now always a list of PlannedStmt
nodes, even for utility statements. In the case of a utility statement,
"planning" just consists of wrapping a CMD_UTILITY PlannedStmt around
the utility node. This list representation is now used in Portal and
CachedPlan plan lists, replacing the former convention of intermixing
PlannedStmts with bare utility-statement nodes.
Now, every list of statements has a consistent head-node type depending
on how far along it is in processing. This allows changing many places
that formerly used generic "Node *" pointers to use a more specific
pointer type, thus reducing the number of IsA() tests and casts needed,
as well as improving code clarity.
Also, the post-parse-analysis representation of DECLARE CURSOR is changed
so that it looks more like EXPLAIN, PREPARE, etc. That is, the contained
SELECT remains a child of the DeclareCursorStmt rather than getting flipped
around to be the other way. It's now true for both Query and PlannedStmt
that utilityStmt is non-null if and only if commandType is CMD_UTILITY.
That allows simplifying a lot of places that were testing both fields.
(I think some of those were just defensive programming, but in many places,
it was actually necessary to avoid confusing DECLARE CURSOR with SELECT.)
Because PlannedStmt carries a canSetTag field, we're also able to get rid
of some ad-hoc rules about how to reconstruct canSetTag for a bare utility
statement; specifically, the assumption that a utility is canSetTag if and
only if it's the only one in its list. While I see no near-term need for
relaxing that restriction, it's nice to get rid of the ad-hocery.
The API of ProcessUtility() is changed so that what it's passed is the
wrapper PlannedStmt not just the bare utility statement. This will affect
all users of ProcessUtility_hook, but the changes are pretty trivial; see
the affected contrib modules for examples of the minimum change needed.
(Most compilers should give pointer-type-mismatch warnings for uncorrected
code.)
There's also a change in the API of ExplainOneQuery_hook, to pass through
cursorOptions instead of expecting hook functions to know what to pick.
This is needed because of the DECLARE CURSOR changes, but really should
have been done in 9.6; it's unlikely that any extant hook functions
know about using CURSOR_OPT_PARALLEL_OK.
Finally, teach gram.y to save statement boundary locations in RawStmt
nodes, and pass those through to Query and PlannedStmt nodes. This allows
more intelligent handling of cases where a source query string contains
multiple statements. This patch doesn't actually do anything with the
information, but a follow-on patch will. (Passing this information through
cleanly is the true motivation for these changes; while I think this is all
good cleanup, it's unlikely we'd have bothered without this end goal.)
catversion bump because addition of location fields to struct Query
affects stored rules.
This patch is by me, but it owes a good deal to Fabien Coelho who did
a lot of preliminary work on the problem, and also reviewed the patch.
Discussion: https://postgr.es/m/alpine.DEB.2.20.1612200926310.29821@lancre
2017-01-14 22:02:35 +01:00
|
|
|
static RawStmt *makeRawStmt(Node *stmt, int stmt_location);
|
|
|
|
|
static void updateRawStmtEnd(RawStmt *rs, int end_location);
|
2009-07-13 04:02:20 +02:00
|
|
|
static Node *makeColumnRef(char *colname, List *indirection,
|
2009-11-09 19:38:48 +01:00
|
|
|
int location, core_yyscan_t yyscanner);
|
2008-08-29 01:09:48 +02:00
|
|
|
static Node *makeTypeCast(Node *arg, TypeName *typename, int location);
|
|
|
|
|
static Node *makeStringConst(char *str, int location);
|
|
|
|
|
static Node *makeStringConstCast(char *str, int location, TypeName *typename);
|
|
|
|
|
static Node *makeIntConst(int val, int location);
|
|
|
|
|
static Node *makeFloatConst(char *str, int location);
|
2022-01-14 10:46:49 +01:00
|
|
|
static Node *makeBoolAConst(bool state, int location);
|
2008-08-29 01:09:48 +02:00
|
|
|
static Node *makeBitStringConst(char *str, int location);
|
|
|
|
|
static Node *makeNullAConst(int location);
|
Remove Value node struct
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and the node
type don't match most of the time, and so it has to be treated
specially a lot. There doesn't seem to be any value in the special
construct. There is very little code that wants to accept all Value
variants but nothing else (and even if it did, this doesn't provide
any convenient way to check it), and most code wants either just one
particular node type (usually String), or it accepts a broader set of
node types besides just Value.
This change removes the Value struct and node type and replaces them
by separate Integer, Float, String, and BitString node types that are
proper node types and structs of their own and behave mostly like
normal node types.
Also, this removes the T_Null node tag, which was previously also a
possible variant of Value but wasn't actually used outside of the
Value contained in A_Const. Replace that by an isnull field in
A_Const.
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/5ba6bc5b-3f95-04f2-2419-f8ddb4c046fb@enterprisedb.com
2021-09-09 07:58:12 +02:00
|
|
|
static Node *makeAConst(Node *v, int location);
|
2016-12-28 18:00:00 +01:00
|
|
|
static RoleSpec *makeRoleSpec(RoleSpecType type, int location);
|
2009-11-09 19:38:48 +01:00
|
|
|
static void check_qualified_name(List *names, core_yyscan_t yyscanner);
|
|
|
|
|
static List *check_func_name(List *names, core_yyscan_t yyscanner);
|
|
|
|
|
static List *check_indirection(List *indirection, core_yyscan_t yyscanner);
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
static List *extractArgTypes(List *parameters);
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
static List *extractAggrArgTypes(List *aggrargs);
|
|
|
|
|
static List *makeOrderedSetArgs(List *directargs, List *orderedargs,
|
|
|
|
|
core_yyscan_t yyscanner);
|
2000-11-05 01:15:54 +01:00
|
|
|
static void insertSelectOptions(SelectStmt *stmt,
|
2006-04-30 20:30:40 +02:00
|
|
|
List *sortClause, List *lockingClause,
|
2020-04-07 22:22:13 +02:00
|
|
|
SelectLimit *limitClause,
|
2009-07-13 04:02:20 +02:00
|
|
|
WithClause *withClause,
|
2009-11-09 19:38:48 +01:00
|
|
|
core_yyscan_t yyscanner);
|
2000-11-05 01:15:54 +01:00
|
|
|
static Node *makeSetOp(SetOperation op, bool all, Node *larg, Node *rarg);
|
2006-03-14 23:48:25 +01:00
|
|
|
static Node *doNegate(Node *n, int location);
|
Remove Value node struct
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and the node
type don't match most of the time, and so it has to be treated
specially a lot. There doesn't seem to be any value in the special
construct. There is very little code that wants to accept all Value
variants but nothing else (and even if it did, this doesn't provide
any convenient way to check it), and most code wants either just one
particular node type (usually String), or it accepts a broader set of
node types besides just Value.
This change removes the Value struct and node type and replaces them
by separate Integer, Float, String, and BitString node types that are
proper node types and structs of their own and behave mostly like
normal node types.
Also, this removes the T_Null node tag, which was previously also a
possible variant of Value but wasn't actually used outside of the
Value contained in A_Const. Replace that by an isnull field in
A_Const.
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/5ba6bc5b-3f95-04f2-2419-f8ddb4c046fb@enterprisedb.com
2021-09-09 07:58:12 +02:00
|
|
|
static void doNegateFloat(Float *v);
|
2014-06-16 21:55:05 +02:00
|
|
|
static Node *makeAndExpr(Node *lexpr, Node *rexpr, int location);
|
|
|
|
|
static Node *makeOrExpr(Node *lexpr, Node *rexpr, int location);
|
|
|
|
|
static Node *makeNotExpr(Node *expr, int location);
|
2008-08-29 01:09:48 +02:00
|
|
|
static Node *makeAArrayExpr(List *elements, int location);
|
|
|
|
|
static Node *makeXmlExpr(XmlExprOp op, char *name, List *named_args,
|
|
|
|
|
List *args, int location);
|
2008-07-18 05:32:53 +02:00
|
|
|
static List *mergeTableFuncParameters(List *func_args, List *columns);
|
|
|
|
|
static TypeName *TableFuncTypeName(List *columns);
|
2010-09-26 13:41:03 +02:00
|
|
|
static RangeVar *makeRangeVarFromAnyName(List *names, int position, core_yyscan_t yyscanner);
|
2022-09-20 22:09:30 +02:00
|
|
|
static RangeVar *makeRangeVarFromQualifiedName(char *name, List *namelist, int location,
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
core_yyscan_t yyscanner);
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
static void SplitColQualList(List *qualList,
|
|
|
|
|
List **constraintList, CollateClause **collClause,
|
|
|
|
|
core_yyscan_t yyscanner);
|
2011-06-16 01:05:11 +02:00
|
|
|
static void processCASbits(int cas_bits, int location, const char *constrType,
|
|
|
|
|
bool *deferrable, bool *initdeferred, bool *not_valid,
|
2012-07-24 21:49:54 +02:00
|
|
|
bool *no_inherit, core_yyscan_t yyscanner);
|
2022-11-03 16:25:54 +01:00
|
|
|
static PartitionStrategy parsePartitionStrategy(char *strategy);
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
static void preprocess_pubobj_list(List *pubobjspec_list,
|
|
|
|
|
core_yyscan_t yyscanner);
|
2013-02-01 04:31:58 +01:00
|
|
|
static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
|
1997-11-25 23:07:18 +01:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
%}
|
|
|
|
|
|
2009-07-13 04:02:20 +02:00
|
|
|
%pure-parser
|
2008-11-26 09:45:12 +01:00
|
|
|
%expect 0
|
2014-05-29 01:21:01 +02:00
|
|
|
%name-prefix="base_yy"
|
2006-03-14 23:48:25 +01:00
|
|
|
%locations
|
2002-03-21 17:02:16 +01:00
|
|
|
|
2009-11-09 19:38:48 +01:00
|
|
|
%parse-param {core_yyscan_t yyscanner}
|
|
|
|
|
%lex-param {core_yyscan_t yyscanner}
|
2009-07-13 04:02:20 +02:00
|
|
|
|
1997-09-08 05:20:18 +02:00
|
|
|
%union
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
core_YYSTYPE core_yystype;
|
2009-11-09 19:38:48 +01:00
|
|
|
/* these fields must match core_YYSTYPE: */
|
2022-05-13 07:17:29 +02:00
|
|
|
int ival;
|
|
|
|
|
char *str;
|
|
|
|
|
const char *keyword;
|
|
|
|
|
|
|
|
|
|
char chr;
|
|
|
|
|
bool boolean;
|
|
|
|
|
JoinType jtype;
|
|
|
|
|
DropBehavior dbehavior;
|
|
|
|
|
OnCommitAction oncommit;
|
|
|
|
|
List *list;
|
|
|
|
|
Node *node;
|
|
|
|
|
ObjectType objtype;
|
|
|
|
|
TypeName *typnam;
|
|
|
|
|
FunctionParameter *fun_param;
|
2005-03-29 19:58:51 +02:00
|
|
|
FunctionParameterMode fun_param_mode;
|
2022-05-13 07:17:29 +02:00
|
|
|
ObjectWithArgs *objwithargs;
|
|
|
|
|
DefElem *defelt;
|
|
|
|
|
SortBy *sortby;
|
|
|
|
|
WindowDef *windef;
|
|
|
|
|
JoinExpr *jexpr;
|
|
|
|
|
IndexElem *ielem;
|
|
|
|
|
StatsElem *selem;
|
|
|
|
|
Alias *alias;
|
|
|
|
|
RangeVar *range;
|
|
|
|
|
IntoClause *into;
|
|
|
|
|
WithClause *with;
|
|
|
|
|
InferClause *infer;
|
|
|
|
|
OnConflictClause *onconflict;
|
|
|
|
|
A_Indices *aind;
|
|
|
|
|
ResTarget *target;
|
|
|
|
|
struct PrivTarget *privtarget;
|
|
|
|
|
AccessPriv *accesspriv;
|
|
|
|
|
struct ImportQual *importqual;
|
|
|
|
|
InsertStmt *istmt;
|
|
|
|
|
VariableSetStmt *vsetstmt;
|
|
|
|
|
PartitionElem *partelem;
|
|
|
|
|
PartitionSpec *partspec;
|
|
|
|
|
PartitionBoundSpec *partboundspec;
|
|
|
|
|
RoleSpec *rolespec;
|
|
|
|
|
PublicationObjSpec *publicationobjectspec;
|
|
|
|
|
struct SelectLimit *selectlimit;
|
|
|
|
|
SetQuantifier setquantifier;
|
|
|
|
|
struct GroupClause *groupclause;
|
|
|
|
|
MergeWhenClause *mergewhen;
|
|
|
|
|
struct KeyActions *keyactions;
|
|
|
|
|
struct KeyAction *keyaction;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
2021-04-07 21:30:08 +02:00
|
|
|
%type <node> stmt toplevel_stmt schema_stmt routine_body_stmt
|
2021-05-07 10:17:42 +02:00
|
|
|
AlterEventTrigStmt AlterCollationStmt
|
2010-10-25 05:04:37 +02:00
|
|
|
AlterDatabaseStmt AlterDatabaseSetStmt AlterDomainStmt AlterEnumStmt
|
|
|
|
|
AlterFdwStmt AlterForeignServerStmt AlterGroupStmt
|
2016-04-05 23:38:54 +02:00
|
|
|
AlterObjectDependsStmt AlterObjectSchemaStmt AlterOwnerStmt
|
2020-03-06 18:19:29 +01:00
|
|
|
AlterOperatorStmt AlterTypeStmt AlterSeqStmt AlterSystemStmt AlterTableStmt
|
2020-06-11 08:21:24 +02:00
|
|
|
AlterTblSpcStmt AlterExtensionStmt AlterExtensionContentsStmt
|
2017-08-01 02:36:32 +02:00
|
|
|
AlterCompositeTypeStmt AlterUserMappingStmt
|
Allow setting statistics target for extended statistics
When building statistics, we need to decide how many rows to sample and
how accurate the resulting statistics should be. Until now, it was not
possible to explicitly define statistics target for extended statistics
objects, the value was always computed from the per-attribute targets
with a fallback to the system-wide default statistics target.
That's a bit inconvenient, as it ties together the statistics target set
for per-column and extended statistics. In some cases it may be useful
to require larger sample / higher accuracy for extended statics (or the
other way around), but with this approach that's not possible.
So this commit introduces a new command, allowing to specify statistics
target for individual extended statistics objects, overriding the value
derived from per-attribute targets (and the system default).
ALTER STATISTICS stat_name SET STATISTICS target_value;
When determining statistics target for an extended statistics object we
first look at this explicitly set value. When this value is -1, we fall
back to the old formula, looking at the per-attribute targets first and
then the system default. This means the behavior is backwards compatible
with older PostgreSQL releases.
Author: Tomas Vondra
Discussion: https://postgr.es/m/20190618213357.vli3i23vpkset2xd@development
Reviewed-by: Kirk Jamison, Dean Rasheed
2019-09-10 20:09:27 +02:00
|
|
|
AlterRoleStmt AlterRoleSetStmt AlterPolicyStmt AlterStatsStmt
|
2009-10-05 21:24:49 +02:00
|
|
|
AlterDefaultPrivilegesStmt DefACLAction
|
2017-11-30 14:46:13 +01:00
|
|
|
AnalyzeStmt CallStmt ClosePortalStmt ClusterStmt CommentStmt
|
2002-09-22 23:44:43 +02:00
|
|
|
ConstraintsSetStmt CopyStmt CreateAsStmt CreateCastStmt
|
2011-02-08 22:08:41 +01:00
|
|
|
CreateDomainStmt CreateExtensionStmt CreateGroupStmt CreateOpClassStmt
|
2007-01-23 06:07:18 +01:00
|
|
|
CreateOpFamilyStmt AlterOpFamilyStmt CreatePLangStmt
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
CreateSchemaStmt CreateSeqStmt CreateStmt CreateStatsStmt CreateTableSpaceStmt
|
2011-01-02 05:48:11 +01:00
|
|
|
CreateFdwStmt CreateForeignServerStmt CreateForeignTableStmt
|
2018-09-26 13:26:24 +02:00
|
|
|
CreateAssertionStmt CreateTransformStmt CreateTrigStmt CreateEventTrigStmt
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
CreateUserStmt CreateUserMappingStmt CreateRoleStmt CreatePolicyStmt
|
2009-09-23 01:43:43 +02:00
|
|
|
CreatedbStmt DeclareCursorStmt DefineStmt DeleteStmt DiscardStmt DoStmt
|
2020-06-11 11:18:15 +02:00
|
|
|
DropOpClassStmt DropOpFamilyStmt DropStmt
|
2018-09-26 13:26:24 +02:00
|
|
|
DropCastStmt DropRoleStmt
|
2017-08-01 02:36:32 +02:00
|
|
|
DropdbStmt DropTableSpaceStmt
|
2015-04-26 16:33:14 +02:00
|
|
|
DropTransformStmt
|
2017-02-22 05:10:07 +01:00
|
|
|
DropUserMappingStmt ExplainStmt FetchStmt
|
2014-07-10 21:01:31 +02:00
|
|
|
GrantStmt GrantRoleStmt ImportForeignSchemaStmt IndexStmt InsertStmt
|
2022-03-28 16:45:58 +02:00
|
|
|
ListenStmt LoadStmt LockStmt MergeStmt NotifyStmt ExplainableStmt PreparableStmt
|
2005-03-14 01:19:37 +01:00
|
|
|
CreateFunctionStmt AlterFunctionStmt ReindexStmt RemoveAggrStmt
|
2021-04-07 21:30:08 +02:00
|
|
|
RemoveFuncStmt RemoveOperStmt RenameStmt ReturnStmt RevokeStmt RevokeRoleStmt
|
2002-09-22 23:44:43 +02:00
|
|
|
RuleActionStmt RuleActionStmtOrEmpty RuleStmt
|
2021-04-07 21:30:08 +02:00
|
|
|
SecLabelStmt SelectStmt TransactionStmt TransactionStmtLegacy TruncateStmt
|
2002-09-22 23:44:43 +02:00
|
|
|
UnlistenStmt UpdateStmt VacuumStmt
|
|
|
|
|
VariableResetStmt VariableSetStmt VariableShowStmt
|
|
|
|
|
ViewStmt CheckPointStmt CreateConversionStmt
|
|
|
|
|
DeallocateStmt PrepareStmt ExecuteStmt
|
2005-11-21 13:49:33 +01:00
|
|
|
DropOwnedStmt ReassignOwnedStmt
|
2007-08-21 03:11:32 +02:00
|
|
|
AlterTSConfigurationStmt AlterTSDictionaryStmt
|
2016-03-24 03:01:35 +01:00
|
|
|
CreateMatViewStmt RefreshMatViewStmt CreateAmStmt
|
2017-01-19 18:00:00 +01:00
|
|
|
CreatePublicationStmt AlterPublicationStmt
|
|
|
|
|
CreateSubscriptionStmt AlterSubscriptionStmt DropSubscriptionStmt
|
2002-09-22 23:44:43 +02:00
|
|
|
|
|
|
|
|
%type <node> select_no_parens select_with_parens select_clause
|
2006-08-02 03:59:48 +02:00
|
|
|
simple_select values_clause
|
2021-01-04 17:52:00 +01:00
|
|
|
PLpgSQL_Expr PLAssignStmt
|
2000-07-14 17:43:57 +02:00
|
|
|
|
2022-07-22 12:57:01 +02:00
|
|
|
%type <str> opt_single_name
|
|
|
|
|
%type <list> opt_qualified_name
|
2022-07-22 19:23:39 +02:00
|
|
|
%type <boolean> opt_concurrently
|
2022-07-22 12:57:01 +02:00
|
|
|
%type <dbehavior> opt_drop_behavior
|
|
|
|
|
|
2007-01-23 06:07:18 +01:00
|
|
|
%type <node> alter_column_default opclass_item opclass_drop alter_using
|
2007-01-09 03:14:16 +01:00
|
|
|
%type <ival> add_drop opt_asc_desc opt_nulls_order
|
2002-07-01 17:27:56 +02:00
|
|
|
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
%type <node> alter_table_cmd alter_type_cmd opt_collate_clause
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
replica_identity partition_cmd index_partition_cmd
|
2010-09-26 13:41:03 +02:00
|
|
|
%type <list> alter_table_cmds alter_type_cmds
|
2017-04-06 14:33:16 +02:00
|
|
|
%type <list> alter_identity_column_option_list
|
|
|
|
|
%type <defelt> alter_identity_column_option
|
2004-05-05 06:48:48 +02:00
|
|
|
|
2014-07-02 01:02:21 +02:00
|
|
|
%type <list> createdb_opt_list createdb_opt_items copy_opt_list
|
2011-02-12 03:25:20 +01:00
|
|
|
transaction_mode_list
|
|
|
|
|
create_extension_opt_list alter_extension_opt_list
|
2014-07-02 01:02:21 +02:00
|
|
|
%type <defelt> createdb_opt_item copy_opt_item
|
2011-02-12 03:25:20 +01:00
|
|
|
transaction_mode_item
|
|
|
|
|
create_extension_opt_item alter_extension_opt_item
|
1997-11-07 08:02:10 +01:00
|
|
|
|
2002-09-22 23:44:43 +02:00
|
|
|
%type <ival> opt_lock lock_type cast_context
|
2020-11-30 12:27:37 +01:00
|
|
|
%type <str> utility_option_name
|
|
|
|
|
%type <defelt> utility_option_elem
|
|
|
|
|
%type <list> utility_option_list
|
|
|
|
|
%type <node> utility_option_arg
|
2019-11-12 06:36:13 +01:00
|
|
|
%type <defelt> drop_option
|
2020-04-20 19:42:12 +02:00
|
|
|
%type <boolean> opt_or_replace opt_no
|
2022-08-25 16:06:02 +02:00
|
|
|
opt_grant_grant_option
|
2008-10-28 15:09:45 +01:00
|
|
|
opt_nowait opt_if_exists opt_with_data
|
2019-03-24 10:33:14 +01:00
|
|
|
opt_transaction_chain
|
2022-08-25 16:06:02 +02:00
|
|
|
%type <list> grant_role_opt_list
|
|
|
|
|
%type <defelt> grant_role_opt
|
|
|
|
|
%type <node> grant_role_opt_value
|
2014-10-07 22:23:34 +02:00
|
|
|
%type <ival> opt_nowait_or_skip
|
1998-12-18 10:10:39 +01:00
|
|
|
|
2009-10-08 00:14:26 +02:00
|
|
|
%type <list> OptRoleList AlterOptRoleList
|
|
|
|
|
%type <defelt> CreateOptRoleElem AlterOptRoleElem
|
1997-12-04 01:28:15 +01:00
|
|
|
|
2008-12-19 17:25:19 +01:00
|
|
|
%type <str> opt_type
|
|
|
|
|
%type <str> foreign_server_version opt_foreign_server_version
|
2009-10-08 00:14:26 +02:00
|
|
|
%type <str> opt_in_database
|
2008-12-19 17:25:19 +01:00
|
|
|
|
2022-07-22 12:57:01 +02:00
|
|
|
%type <str> parameter_name
|
2022-04-06 19:24:33 +02:00
|
|
|
%type <list> OptSchemaEltList parameter_name_list
|
2002-03-21 17:02:16 +01:00
|
|
|
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
%type <chr> am_type
|
|
|
|
|
|
2010-10-10 19:43:33 +02:00
|
|
|
%type <boolean> TriggerForSpec TriggerForType
|
|
|
|
|
%type <ival> TriggerActionTime
|
2009-10-15 00:14:25 +02:00
|
|
|
%type <list> TriggerEvents TriggerOneEvent
|
Remove Value node struct
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and the node
type don't match most of the time, and so it has to be treated
specially a lot. There doesn't seem to be any value in the special
construct. There is very little code that wants to accept all Value
variants but nothing else (and even if it did, this doesn't provide
any convenient way to check it), and most code wants either just one
particular node type (usually String), or it accepts a broader set of
node types besides just Value.
This change removes the Value struct and node type and replaces them
by separate Integer, Float, String, and BitString node types that are
proper node types and structs of their own and behave mostly like
normal node types.
Also, this removes the T_Null node tag, which was previously also a
possible variant of Value but wasn't actually used outside of the
Value contained in A_Const. Replace that by an isnull field in
A_Const.
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/5ba6bc5b-3f95-04f2-2419-f8ddb4c046fb@enterprisedb.com
2021-09-09 07:58:12 +02:00
|
|
|
%type <node> TriggerFuncArg
|
2009-11-20 21:38:12 +01:00
|
|
|
%type <node> TriggerWhen
|
2016-11-04 16:49:50 +01:00
|
|
|
%type <str> TransitionRelName
|
|
|
|
|
%type <boolean> TransitionRowOrTable TransitionOldOrNew
|
|
|
|
|
%type <node> TriggerTransition
|
1997-09-01 08:00:35 +02:00
|
|
|
|
2012-07-18 16:16:16 +02:00
|
|
|
%type <list> event_trigger_when_list event_trigger_value_list
|
|
|
|
|
%type <defelt> event_trigger_when_item
|
|
|
|
|
%type <chr> enable_trigger
|
|
|
|
|
|
2009-11-06 00:24:27 +01:00
|
|
|
%type <str> copy_file_name
|
2020-06-10 22:58:46 +02:00
|
|
|
access_method_clause attr_name
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
table_access_method_clause name cursor_name file_name
|
2022-07-22 12:57:01 +02:00
|
|
|
cluster_index_specification
|
2002-04-09 22:35:55 +02:00
|
|
|
|
2004-04-05 05:07:26 +02:00
|
|
|
%type <list> func_name handler_name qual_Op qual_all_Op subquery_Op
|
2022-07-22 12:57:01 +02:00
|
|
|
opt_inline_handler opt_validator validator_clause
|
2011-02-08 22:04:18 +01:00
|
|
|
opt_collate
|
1997-08-21 03:34:44 +02:00
|
|
|
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
%type <range> qualified_name insert_target OptConstrFromTable
|
2002-03-21 17:02:16 +01:00
|
|
|
|
2009-11-06 00:24:27 +01:00
|
|
|
%type <str> all_Op MathOp
|
1996-07-09 08:22:35 +02:00
|
|
|
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
%type <str> row_security_cmd RowSecurityDefaultForCmd
|
2016-12-05 21:50:55 +01:00
|
|
|
%type <boolean> RowSecurityDefaultPermissive
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
%type <node> RowSecurityOptionalWithCheck RowSecurityOptionalExpr
|
|
|
|
|
%type <list> RowSecurityDefaultToRole RowSecurityOptionalToRole
|
|
|
|
|
|
2002-09-22 23:44:43 +02:00
|
|
|
%type <str> iso_level opt_encoding
|
2016-12-28 18:00:00 +01:00
|
|
|
%type <rolespec> grantee
|
2001-06-10 01:21:55 +02:00
|
|
|
%type <list> grantee_list
|
2009-01-22 21:16:10 +01:00
|
|
|
%type <accesspriv> privilege
|
2002-09-22 23:44:43 +02:00
|
|
|
%type <list> privileges privilege_list
|
2002-02-19 00:11:58 +01:00
|
|
|
%type <privtarget> privilege_target
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
%type <objwithargs> function_with_argtypes aggregate_with_argtypes operator_with_argtypes
|
|
|
|
|
%type <list> function_with_argtypes_list aggregate_with_argtypes_list operator_with_argtypes_list
|
2009-10-05 21:24:49 +02:00
|
|
|
%type <ival> defacl_privilege_target
|
|
|
|
|
%type <defelt> DefACLOption
|
|
|
|
|
%type <list> DefACLOptionList
|
2014-07-10 21:01:31 +02:00
|
|
|
%type <ival> import_qualification_type
|
|
|
|
|
%type <importqual> import_qualification
|
2017-10-04 00:53:44 +02:00
|
|
|
%type <node> vacuum_relation
|
2020-04-07 22:22:13 +02:00
|
|
|
%type <selectlimit> opt_select_limit select_limit limit_clause
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2021-04-07 21:30:08 +02:00
|
|
|
%type <list> parse_toplevel stmtmulti routine_body_stmt_list
|
2002-09-22 23:44:43 +02:00
|
|
|
OptTableElementList TableElementList OptInherit definition
|
2010-01-29 00:21:13 +01:00
|
|
|
OptTypedTableElementList TypedTableElementList
|
2009-02-02 20:31:40 +01:00
|
|
|
reloptions opt_reloptions
|
2021-01-22 22:26:22 +01:00
|
|
|
OptWith opt_definition func_args func_args_list
|
2008-12-04 18:51:28 +01:00
|
|
|
func_args_with_defaults func_args_with_defaults_list
|
Allow aggregate functions to be VARIADIC.
There's no inherent reason why an aggregate function can't be variadic
(even VARIADIC ANY) if its transition function can handle the case.
Indeed, this patch to add the feature touches none of the planner or
executor, and little of the parser; the main missing stuff was DDL and
pg_dump support.
It is true that variadic aggregates can create the same sort of ambiguity
about parameters versus ORDER BY keys that was complained of when we
(briefly) had both one- and two-argument forms of string_agg(). However,
the policy formed in response to that discussion only said that we'd not
create any built-in aggregates with varying numbers of arguments, not that
we shouldn't allow users to do it. So the logical extension of that is
we can allow users to make variadic aggregates as long as we're wary about
shipping any such in core.
In passing, this patch allows aggregate function arguments to be named, to
the extent of remembering the names in pg_proc and dumping them in pg_dump.
You can't yet call an aggregate using named-parameter notation. That seems
like a likely future extension, but it'll take some work, and it's not what
this patch is really about. Likewise, there's still some work needed to
make window functions handle VARIADIC fully, but I left that for another
day.
initdb forced because of new aggvariadic field in Aggref parse nodes.
2013-09-03 23:08:38 +02:00
|
|
|
aggr_args aggr_args_list
|
2021-04-07 21:30:08 +02:00
|
|
|
func_as createfunc_opt_list opt_createfunc_opt_list alterfunc_opt_list
|
Allow aggregate functions to be VARIADIC.
There's no inherent reason why an aggregate function can't be variadic
(even VARIADIC ANY) if its transition function can handle the case.
Indeed, this patch to add the feature touches none of the planner or
executor, and little of the parser; the main missing stuff was DDL and
pg_dump support.
It is true that variadic aggregates can create the same sort of ambiguity
about parameters versus ORDER BY keys that was complained of when we
(briefly) had both one- and two-argument forms of string_agg(). However,
the policy formed in response to that discussion only said that we'd not
create any built-in aggregates with varying numbers of arguments, not that
we shouldn't allow users to do it. So the logical extension of that is
we can allow users to make variadic aggregates as long as we're wary about
shipping any such in core.
In passing, this patch allows aggregate function arguments to be named, to
the extent of remembering the names in pg_proc and dumping them in pg_dump.
You can't yet call an aggregate using named-parameter notation. That seems
like a likely future extension, but it'll take some work, and it's not what
this patch is really about. Likewise, there's still some work needed to
make window functions handle VARIADIC fully, but I left that for another
day.
initdb forced because of new aggvariadic field in Aggref parse nodes.
2013-09-03 23:08:38 +02:00
|
|
|
old_aggr_definition old_aggr_list
|
2002-09-22 23:44:43 +02:00
|
|
|
oper_argtypes RuleActionList RuleActionMulti
|
2006-07-04 00:45:41 +02:00
|
|
|
opt_column_list columnList opt_name_list
|
2022-07-21 20:23:13 +02:00
|
|
|
sort_clause opt_sort_clause sortby_list index_params
|
2022-07-22 12:57:01 +02:00
|
|
|
stats_params
|
2018-04-07 22:00:39 +02:00
|
|
|
opt_include opt_c_include index_including_params
|
2014-01-22 04:49:22 +01:00
|
|
|
name_list role_list from_clause from_list opt_array_bounds
|
2014-12-30 17:57:23 +01:00
|
|
|
qualified_name_list any_name any_name_list type_name_list
|
2004-06-09 21:08:20 +02:00
|
|
|
any_operator expr_list attrs
|
2021-01-22 22:26:22 +01:00
|
|
|
distinct_clause opt_distinct_clause
|
2013-12-15 02:23:26 +01:00
|
|
|
target_list opt_target_list insert_column_list set_target_list
|
2022-03-28 16:45:58 +02:00
|
|
|
merge_values_clause
|
Improve handling of "UPDATE ... SET (column_list) = row_constructor".
Previously, the right-hand side of a multiple-column assignment, if it
wasn't a sub-SELECT, had to be a simple parenthesized expression list,
because gram.y was responsible for "bursting" the construct into
independent column assignments. This had the minor defect that you
couldn't write ROW (though you should be able to, since the standard says
this is a row constructor), and the rather larger defect that unlike other
uses of row constructors, we would not expand a "foo.*" item into multiple
columns.
Fix that by changing the RHS to be just "a_expr" in the grammar, leaving
it to transformMultiAssignRef to separate the elements of a RowExpr;
which it will do only after performing standard transformation of the
RowExpr, so that "foo.*" behaves as expected.
The key reason we didn't do that before was the hard-wired handling of
DEFAULT tokens (SetToDefault nodes). This patch deals with that issue by
allowing DEFAULT in any a_expr and having parse analysis throw an error
if SetToDefault is found in an unexpected place. That's an improvement
anyway since the error can be more specific than just "syntax error".
The SQL standard suggests that the RHS could be any a_expr yielding a
suitable row value. This patch doesn't really move the goal posts in that
respect --- you're still limited to RowExpr or a sub-SELECT --- but it does
fix the grammar restriction, so it provides some tangible progress towards
a full implementation. And the limitation is now documented by an explicit
error message rather than an unhelpful "syntax error".
Discussion: <8542.1479742008@sss.pgh.pa.us>
2016-11-22 21:19:57 +01:00
|
|
|
set_clause_list set_clause
|
|
|
|
|
def_list operator_def_list indirection opt_indirection
|
Implement GROUP BY DISTINCT
With grouping sets, it's possible that some of the grouping sets are
duplicate. This is especially common with CUBE and ROLLUP clauses. For
example GROUP BY CUBE (a,b), CUBE (b,c) is equivalent to
GROUP BY GROUPING SETS (
(a, b, c),
(a, b, c),
(a, b, c),
(a, b),
(a, b),
(a, b),
(a),
(a),
(a),
(c, a),
(c, a),
(c, a),
(c),
(b, c),
(b),
()
)
Some of the grouping sets are calculated multiple times, which is mostly
unnecessary. This commit implements a new GROUP BY DISTINCT feature, as
defined in the SQL standard, which eliminates the duplicate sets.
Author: Vik Fearing
Reviewed-by: Erik Rijkers, Georgios Kokolatos, Tomas Vondra
Discussion: https://postgr.es/m/bf3805a8-d7d1-ae61-fece-761b7ff41ecc@postgresfriends.org
2021-03-18 17:45:38 +01:00
|
|
|
reloption_list TriggerFuncArgs opclass_item_list opclass_drop_list
|
2010-11-24 20:20:39 +01:00
|
|
|
opclass_purpose opt_opfamily transaction_mode_list_or_empty
|
2010-09-26 13:41:03 +02:00
|
|
|
OptTableFuncElementList TableFuncElementList opt_type_modifiers
|
2007-01-23 06:07:18 +01:00
|
|
|
prep_type_clause
|
2006-08-12 04:52:06 +02:00
|
|
|
execute_param_clause using_clause returning_clause
|
2009-12-26 17:55:21 +01:00
|
|
|
opt_enum_val_list enum_val_list table_func_column_list
|
2008-12-19 17:25:19 +01:00
|
|
|
create_generic_options alter_generic_options
|
2009-09-23 01:43:43 +02:00
|
|
|
relation_expr_list dostmt_opt_list
|
2015-04-26 16:33:14 +02:00
|
|
|
transform_element_list transform_type_list
|
2016-11-04 16:49:50 +01:00
|
|
|
TriggerTransitions TriggerReferencing
|
2017-10-04 00:53:44 +02:00
|
|
|
vacuum_relation_list opt_vacuum_relation_list
|
2022-04-07 18:13:13 +02:00
|
|
|
drop_option_list pub_obj_list
|
2002-09-22 23:44:43 +02:00
|
|
|
|
2021-04-07 21:30:08 +02:00
|
|
|
%type <node> opt_routine_body
|
Implement GROUP BY DISTINCT
With grouping sets, it's possible that some of the grouping sets are
duplicate. This is especially common with CUBE and ROLLUP clauses. For
example GROUP BY CUBE (a,b), CUBE (b,c) is equivalent to
GROUP BY GROUPING SETS (
(a, b, c),
(a, b, c),
(a, b, c),
(a, b),
(a, b),
(a, b),
(a),
(a),
(a),
(c, a),
(c, a),
(c, a),
(c),
(b, c),
(b),
()
)
Some of the grouping sets are calculated multiple times, which is mostly
unnecessary. This commit implements a new GROUP BY DISTINCT feature, as
defined in the SQL standard, which eliminates the duplicate sets.
Author: Vik Fearing
Reviewed-by: Erik Rijkers, Georgios Kokolatos, Tomas Vondra
Discussion: https://postgr.es/m/bf3805a8-d7d1-ae61-fece-761b7ff41ecc@postgresfriends.org
2021-03-18 17:45:38 +01:00
|
|
|
%type <groupclause> group_clause
|
Support GROUPING SETS, CUBE and ROLLUP.
This SQL standard functionality allows to aggregate data by different
GROUP BY clauses at once. Each grouping set returns rows with columns
grouped by in other sets set to NULL.
This could previously be achieved by doing each grouping as a separate
query, conjoined by UNION ALLs. Besides being considerably more concise,
grouping sets will in many cases be faster, requiring only one scan over
the underlying data.
The current implementation of grouping sets only supports using sorting
for input. Individual sets that share a sort order are computed in one
pass. If there are sets that don't share a sort order, additional sort &
aggregation steps are performed. These additional passes are sourced by
the previous sort step; thus avoiding repeated scans of the source data.
The code is structured in a way that adding support for purely using
hash aggregation or a mix of hashing and sorting is possible. Sorting
was chosen to be supported first, as it is the most generic method of
implementation.
Instead of, as in an earlier versions of the patch, representing the
chain of sort and aggregation steps as full blown planner and executor
nodes, all but the first sort are performed inside the aggregation node
itself. This avoids the need to do some unusual gymnastics to handle
having to return aggregated and non-aggregated tuples from underlying
nodes, as well as having to shut down underlying nodes early to limit
memory usage. The optimizer still builds Sort/Agg node to describe each
phase, but they're not part of the plan tree, but instead additional
data for the aggregation node. They're a convenient and preexisting way
to describe aggregation and sorting. The first (and possibly only) sort
step is still performed as a separate execution step. That retains
similarity with existing group by plans, makes rescans fairly simple,
avoids very deep plans (leading to slow explains) and easily allows to
avoid the sorting step if the underlying data is sorted by other means.
A somewhat ugly side of this patch is having to deal with a grammar
ambiguity between the new CUBE keyword and the cube extension/functions
named cube (and rollup). To avoid breaking existing deployments of the
cube extension it has not been renamed, neither has cube been made a
reserved keyword. Instead precedence hacking is used to make GROUP BY
cube(..) refer to the CUBE grouping sets feature, and not the function
cube(). To actually group by a function cube(), unlikely as that might
be, the function name has to be quoted.
Needs a catversion bump because stored rules may change.
Author: Andrew Gierth and Atri Sharma, with contributions from Andres Freund
Reviewed-By: Andres Freund, Noah Misch, Tom Lane, Svenne Krap, Tomas
Vondra, Erik Rijkers, Marti Raudsepp, Pavel Stehule
Discussion: CAOeZVidmVRe2jU6aMk_5qkxnB7dfmPROzM7Ur8JPW5j8Y5X-Lw@mail.gmail.com
2015-05-16 03:40:59 +02:00
|
|
|
%type <list> group_by_list
|
|
|
|
|
%type <node> group_by_item empty_grouping_set rollup_clause cube_clause
|
|
|
|
|
%type <node> grouping_sets_clause
|
|
|
|
|
|
2011-02-19 06:06:18 +01:00
|
|
|
%type <list> opt_fdw_options fdw_options
|
|
|
|
|
%type <defelt> fdw_option
|
|
|
|
|
|
2007-02-20 18:32:18 +01:00
|
|
|
%type <range> OptTempTableName
|
2013-03-04 01:23:31 +01:00
|
|
|
%type <into> into_clause create_as_target create_mv_target
|
2002-03-21 17:02:16 +01:00
|
|
|
|
2009-09-23 01:43:43 +02:00
|
|
|
%type <defelt> createfunc_opt_item common_func_opt_item dostmt_opt_item
|
Allow aggregate functions to be VARIADIC.
There's no inherent reason why an aggregate function can't be variadic
(even VARIADIC ANY) if its transition function can handle the case.
Indeed, this patch to add the feature touches none of the planner or
executor, and little of the parser; the main missing stuff was DDL and
pg_dump support.
It is true that variadic aggregates can create the same sort of ambiguity
about parameters versus ORDER BY keys that was complained of when we
(briefly) had both one- and two-argument forms of string_agg(). However,
the policy formed in response to that discussion only said that we'd not
create any built-in aggregates with varying numbers of arguments, not that
we shouldn't allow users to do it. So the logical extension of that is
we can allow users to make variadic aggregates as long as we're wary about
shipping any such in core.
In passing, this patch allows aggregate function arguments to be named, to
the extent of remembering the names in pg_proc and dumping them in pg_dump.
You can't yet call an aggregate using named-parameter notation. That seems
like a likely future extension, but it'll take some work, and it's not what
this patch is really about. Likewise, there's still some work needed to
make window functions handle VARIADIC fully, but I left that for another
day.
initdb forced because of new aggvariadic field in Aggref parse nodes.
2013-09-03 23:08:38 +02:00
|
|
|
%type <fun_param> func_arg func_arg_with_default table_func_column aggr_arg
|
2005-03-29 19:58:51 +02:00
|
|
|
%type <fun_param_mode> arg_class
|
2006-04-15 19:45:46 +02:00
|
|
|
%type <typnam> func_return func_type
|
1998-02-11 05:09:54 +01:00
|
|
|
|
2017-05-09 16:20:42 +02:00
|
|
|
%type <boolean> opt_trusted opt_restart_seqs
|
2010-12-13 18:34:26 +01:00
|
|
|
%type <ival> OptTemp
|
2013-03-04 01:23:31 +01:00
|
|
|
%type <ival> OptNoLog
|
2004-01-11 00:28:45 +01:00
|
|
|
%type <oncommit> OnCommitOption
|
1998-02-11 05:09:54 +01:00
|
|
|
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
%type <ival> for_locking_strength
|
2006-04-30 20:30:40 +02:00
|
|
|
%type <node> for_locking_item
|
|
|
|
|
%type <list> for_locking_clause opt_for_locking_clause for_locking_items
|
2005-08-01 22:31:16 +02:00
|
|
|
%type <list> locked_rels_list
|
Implement GROUP BY DISTINCT
With grouping sets, it's possible that some of the grouping sets are
duplicate. This is especially common with CUBE and ROLLUP clauses. For
example GROUP BY CUBE (a,b), CUBE (b,c) is equivalent to
GROUP BY GROUPING SETS (
(a, b, c),
(a, b, c),
(a, b, c),
(a, b),
(a, b),
(a, b),
(a),
(a),
(a),
(c, a),
(c, a),
(c, a),
(c),
(b, c),
(b),
()
)
Some of the grouping sets are calculated multiple times, which is mostly
unnecessary. This commit implements a new GROUP BY DISTINCT feature, as
defined in the SQL standard, which eliminates the duplicate sets.
Author: Vik Fearing
Reviewed-by: Erik Rijkers, Georgios Kokolatos, Tomas Vondra
Discussion: https://postgr.es/m/bf3805a8-d7d1-ae61-fece-761b7ff41ecc@postgresfriends.org
2021-03-18 17:45:38 +01:00
|
|
|
%type <setquantifier> set_quantifier
|
1997-09-01 08:00:35 +02:00
|
|
|
|
2020-11-12 07:48:36 +01:00
|
|
|
%type <node> join_qual
|
2000-09-12 23:07:18 +02:00
|
|
|
%type <jtype> join_type
|
1999-02-23 08:42:41 +01:00
|
|
|
|
2002-09-22 23:44:43 +02:00
|
|
|
%type <list> extract_list overlay_list position_list
|
2002-11-02 19:41:22 +01:00
|
|
|
%type <list> substr_list trim_list
|
2008-09-11 17:27:30 +02:00
|
|
|
%type <list> opt_interval interval_second
|
2020-03-26 08:14:00 +01:00
|
|
|
%type <str> unicode_normal_form
|
1997-09-01 08:00:35 +02:00
|
|
|
|
2009-07-27 01:34:18 +02:00
|
|
|
%type <boolean> opt_instead
|
2022-07-22 12:57:01 +02:00
|
|
|
%type <boolean> opt_unique opt_verbose opt_full
|
2018-01-09 16:12:58 +01:00
|
|
|
%type <boolean> opt_freeze opt_analyze opt_default opt_recheck
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
%type <defelt> opt_binary copy_delimiter
|
1996-07-09 08:22:35 +02:00
|
|
|
|
Add support for piping COPY to/from an external program.
This includes backend "COPY TO/FROM PROGRAM '...'" syntax, and corresponding
psql \copy syntax. Like with reading/writing files, the backend version is
superuser-only, and in the psql version, the program is run in the client.
In the passing, the psql \copy STDIN/STDOUT syntax is subtly changed: if you
the stdin/stdout is quoted, it's now interpreted as a filename. For example,
"\copy foo from 'stdin'" now reads from a file called 'stdin', not from
standard input. Before this, there was no way to specify a filename called
stdin, stdout, pstdin or pstdout.
This creates a new function in pgport, wait_result_to_str(), which can
be used to convert the exit status of a process, as returned by wait(3),
to a human-readable string.
Etsuro Fujita, reviewed by Amit Kapila.
2013-02-27 17:17:21 +01:00
|
|
|
%type <boolean> copy_from opt_program
|
2002-06-20 18:00:44 +02:00
|
|
|
|
2020-11-12 07:48:36 +01:00
|
|
|
%type <ival> event cursor_options opt_hold opt_set_data
|
2020-06-13 09:03:28 +02:00
|
|
|
%type <objtype> object_type_any_name object_type_name object_type_name_on_any_name
|
|
|
|
|
drop_type_name
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2020-04-07 22:22:13 +02:00
|
|
|
%type <node> fetch_args select_limit_value
|
2009-08-19 01:40:20 +02:00
|
|
|
offset_clause select_offset_value
|
2018-05-21 18:02:17 +02:00
|
|
|
select_fetch_first_value I_or_F_const
|
2008-10-22 13:00:34 +02:00
|
|
|
%type <ival> row_or_rows first_or_next
|
1999-02-08 15:14:32 +01:00
|
|
|
|
2017-04-06 14:33:16 +02:00
|
|
|
%type <list> OptSeqOptList SeqOptList OptParenthesizedSeqOptList
|
2008-06-15 03:25:54 +02:00
|
|
|
%type <defelt> SeqOptElem
|
1997-04-02 06:01:03 +02:00
|
|
|
|
2000-10-05 21:11:39 +02:00
|
|
|
%type <istmt> insert_rest
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
%type <infer> opt_conf_expr
|
|
|
|
|
%type <onconflict> opt_on_conflict
|
2022-03-28 16:45:58 +02:00
|
|
|
%type <mergewhen> merge_insert merge_update merge_delete
|
|
|
|
|
|
|
|
|
|
%type <node> merge_when_clause opt_merge_when_condition
|
|
|
|
|
%type <list> merge_when_list
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2014-09-02 09:06:58 +02:00
|
|
|
%type <vsetstmt> generic_set set_rest set_rest_more generic_reset reset_rest
|
|
|
|
|
SetResetClause FunctionSetResetClause
|
2002-05-17 03:19:19 +02:00
|
|
|
|
2010-01-29 00:21:13 +01:00
|
|
|
%type <node> TableElement TypedTableElement ConstraintElem TableFuncElement
|
|
|
|
|
%type <node> columnDef columnOptions
|
2015-07-14 17:17:55 +02:00
|
|
|
%type <defelt> def_elem reloption_elem old_aggr_elem operator_def_elem
|
2007-06-11 03:16:30 +02:00
|
|
|
%type <node> def_arg columnElem where_clause where_or_current_clause
|
2015-12-23 03:05:16 +01:00
|
|
|
a_expr b_expr c_expr AexprConst indirection_el opt_slice_bound
|
2017-03-08 16:39:37 +01:00
|
|
|
columnref in_expr having_clause func_table xmltable array_expr
|
2021-03-25 10:06:32 +01:00
|
|
|
OptWhereClause operator_def_arg
|
2013-12-10 15:34:37 +01:00
|
|
|
%type <list> rowsfrom_item rowsfrom_list opt_col_def_list
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
%type <boolean> opt_ordinality
|
2009-12-07 06:22:23 +01:00
|
|
|
%type <list> ExclusionConstraintList ExclusionConstraintElem
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
%type <list> func_arg_list func_arg_list_opt
|
2009-10-08 04:39:25 +02:00
|
|
|
%type <node> func_arg_expr
|
Support GROUPING SETS, CUBE and ROLLUP.
This SQL standard functionality allows to aggregate data by different
GROUP BY clauses at once. Each grouping set returns rows with columns
grouped by in other sets set to NULL.
This could previously be achieved by doing each grouping as a separate
query, conjoined by UNION ALLs. Besides being considerably more concise,
grouping sets will in many cases be faster, requiring only one scan over
the underlying data.
The current implementation of grouping sets only supports using sorting
for input. Individual sets that share a sort order are computed in one
pass. If there are sets that don't share a sort order, additional sort &
aggregation steps are performed. These additional passes are sourced by
the previous sort step; thus avoiding repeated scans of the source data.
The code is structured in a way that adding support for purely using
hash aggregation or a mix of hashing and sorting is possible. Sorting
was chosen to be supported first, as it is the most generic method of
implementation.
Instead of, as in an earlier versions of the patch, representing the
chain of sort and aggregation steps as full blown planner and executor
nodes, all but the first sort are performed inside the aggregation node
itself. This avoids the need to do some unusual gymnastics to handle
having to return aggregated and non-aggregated tuples from underlying
nodes, as well as having to shut down underlying nodes early to limit
memory usage. The optimizer still builds Sort/Agg node to describe each
phase, but they're not part of the plan tree, but instead additional
data for the aggregation node. They're a convenient and preexisting way
to describe aggregation and sorting. The first (and possibly only) sort
step is still performed as a separate execution step. That retains
similarity with existing group by plans, makes rescans fairly simple,
avoids very deep plans (leading to slow explains) and easily allows to
avoid the sorting step if the underlying data is sorted by other means.
A somewhat ugly side of this patch is having to deal with a grammar
ambiguity between the new CUBE keyword and the cube extension/functions
named cube (and rollup). To avoid breaking existing deployments of the
cube extension it has not been renamed, neither has cube been made a
reserved keyword. Instead precedence hacking is used to make GROUP BY
cube(..) refer to the CUBE grouping sets feature, and not the function
cube(). To actually group by a function cube(), unlikely as that might
be, the function name has to be quoted.
Needs a catversion bump because stored rules may change.
Author: Andrew Gierth and Atri Sharma, with contributions from Andres Freund
Reviewed-By: Andres Freund, Noah Misch, Tom Lane, Svenne Krap, Tomas
Vondra, Erik Rijkers, Marti Raudsepp, Pavel Stehule
Discussion: CAOeZVidmVRe2jU6aMk_5qkxnB7dfmPROzM7Ur8JPW5j8Y5X-Lw@mail.gmail.com
2015-05-16 03:40:59 +02:00
|
|
|
%type <list> row explicit_row implicit_row type_list array_expr_list
|
2002-09-22 23:44:43 +02:00
|
|
|
%type <node> case_expr case_arg when_clause case_default
|
1998-12-04 16:34:49 +01:00
|
|
|
%type <list> when_clause_list
|
2021-02-01 13:54:59 +01:00
|
|
|
%type <node> opt_search_clause opt_cycle_clause
|
Allow user control of CTE materialization, and change the default behavior.
Historically we've always materialized the full output of a CTE query,
treating WITH as an optimization fence (so that, for example, restrictions
from the outer query cannot be pushed into it). This is appropriate when
the CTE query is INSERT/UPDATE/DELETE, or is recursive; but when the CTE
query is non-recursive and side-effect-free, there's no hazard of changing
the query results by pushing restrictions down.
Another argument for materialization is that it can avoid duplicate
computation of an expensive WITH query --- but that only applies if
the WITH query is called more than once in the outer query. Even then
it could still be a net loss, if each call has restrictions that
would allow just a small part of the WITH query to be computed.
Hence, let's change the behavior for WITH queries that are non-recursive
and side-effect-free. By default, we will inline them into the outer
query (removing the optimization fence) if they are called just once.
If they are called more than once, we will keep the old behavior by
default, but the user can override this and force inlining by specifying
NOT MATERIALIZED. Lastly, the user can force the old behavior by
specifying MATERIALIZED; this would mainly be useful when the query had
deliberately been employing WITH as an optimization fence to prevent a
poor choice of plan.
Andreas Karlsson, Andrew Gierth, David Fetter
Discussion: https://postgr.es/m/87sh48ffhb.fsf@news-spur.riddles.org.uk
2019-02-16 22:11:12 +01:00
|
|
|
%type <ival> sub_type opt_materialized
|
Remove Value node struct
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and the node
type don't match most of the time, and so it has to be treated
specially a lot. There doesn't seem to be any value in the special
construct. There is very little code that wants to accept all Value
variants but nothing else (and even if it did, this doesn't provide
any convenient way to check it), and most code wants either just one
particular node type (usually String), or it accepts a broader set of
node types besides just Value.
This change removes the Value struct and node type and replaces them
by separate Integer, Float, String, and BitString node types that are
proper node types and structs of their own and behave mostly like
normal node types.
Also, this removes the T_Null node tag, which was previously also a
possible variant of Value but wasn't actually used outside of the
Value contained in A_Const. Replace that by an isnull field in
A_Const.
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/5ba6bc5b-3f95-04f2-2419-f8ddb4c046fb@enterprisedb.com
2021-09-09 07:58:12 +02:00
|
|
|
%type <node> NumericOnly
|
2010-06-13 19:43:13 +02:00
|
|
|
%type <list> NumericOnly_list
|
2021-03-31 17:09:24 +02:00
|
|
|
%type <alias> alias_clause opt_alias_clause opt_alias_clause_for_join_using
|
2012-08-08 01:02:54 +02:00
|
|
|
%type <list> func_alias_clause
|
2003-08-17 21:58:06 +02:00
|
|
|
%type <sortby> sortby
|
Implement operator class parameters
PostgreSQL provides set of template index access methods, where opclasses have
much freedom in the semantics of indexing. These index AMs are GiST, GIN,
SP-GiST and BRIN. There opclasses define representation of keys, operations on
them and supported search strategies. So, it's natural that opclasses may be
faced some tradeoffs, which require user-side decision. This commit implements
opclass parameters allowing users to set some values, which tell opclass how to
index the particular dataset.
This commit doesn't introduce new storage in system catalog. Instead it uses
pg_attribute.attoptions, which is used for table column storage options but
unused for index attributes.
In order to evade changing signature of each opclass support function, we
implement unified way to pass options to opclass support functions. Options
are set to fn_expr as the constant bytea expression. It's possible due to the
fact that opclass support functions are executed outside of expressions, so
fn_expr is unused for them.
This commit comes with some examples of opclass options usage. We parametrize
signature length in GiST. That applies to multiple opclasses: tsvector_ops,
gist__intbig_ops, gist_ltree_ops, gist__ltree_ops, gist_trgm_ops and
gist_hstore_ops. Also we parametrize maximum number of integer ranges for
gist__int_ops. However, the main future usage of this feature is expected
to be json, where users would be able to specify which way to index particular
json parts.
Catversion is bumped.
Discussion: https://postgr.es/m/d22c3a18-31c7-1879-fc11-4c1ce2f5e5af%40postgrespro.ru
Author: Nikita Glukhov, revised by me
Reviwed-by: Nikolay Shaplov, Robert Haas, Tom Lane, Tomas Vondra, Alvaro Herrera
2020-03-30 18:17:11 +02:00
|
|
|
%type <ielem> index_elem index_elem_options
|
Extended statistics on expressions
Allow defining extended statistics on expressions, not just just on
simple column references. With this commit, expressions are supported
by all existing extended statistics kinds, improving the same types of
estimates. A simple example may look like this:
CREATE TABLE t (a int);
CREATE STATISTICS s ON mod(a,10), mod(a,20) FROM t;
ANALYZE t;
The collected statistics are useful e.g. to estimate queries with those
expressions in WHERE or GROUP BY clauses:
SELECT * FROM t WHERE mod(a,10) = 0 AND mod(a,20) = 0;
SELECT 1 FROM t GROUP BY mod(a,10), mod(a,20);
This introduces new internal statistics kind 'e' (expressions) which is
built automatically when the statistics object definition includes any
expressions. This represents single-expression statistics, as if there
was an expression index (but without the index maintenance overhead).
The statistics is stored in pg_statistics_ext_data as an array of
composite types, which is possible thanks to 79f6a942bd.
CREATE STATISTICS allows building statistics on a single expression, in
which case in which case it's not possible to specify statistics kinds.
A new system view pg_stats_ext_exprs can be used to display expression
statistics, similarly to pg_stats and pg_stats_ext views.
ALTER TABLE ... ALTER COLUMN ... TYPE now treats indexes the same way it
treats indexes, i.e. it drops and recreates the statistics. This means
all statistics are reset, and we no longer try to preserve at least the
functional dependencies. This should not be a major issue in practice,
as the functional dependencies actually rely on per-column statistics,
which were always reset anyway.
Author: Tomas Vondra
Reviewed-by: Justin Pryzby, Dean Rasheed, Zhihong Yu
Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com
2021-03-26 23:22:01 +01:00
|
|
|
%type <selem> stats_param
|
2000-09-12 23:07:18 +02:00
|
|
|
%type <node> table_ref
|
|
|
|
|
%type <jexpr> joined_table
|
|
|
|
|
%type <range> relation_expr
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
%type <range> extended_relation_expr
|
2006-01-22 06:20:35 +01:00
|
|
|
%type <range> relation_expr_opt_alias
|
Redesign tablesample method API, and do extensive code review.
The original implementation of TABLESAMPLE modeled the tablesample method
API on index access methods, which wasn't a good choice because, without
specialized DDL commands, there's no way to build an extension that can
implement a TSM. (Raw inserts into system catalogs are not an acceptable
thing to do, because we can't undo them during DROP EXTENSION, nor will
pg_upgrade behave sanely.) Instead adopt an API more like procedural
language handlers or foreign data wrappers, wherein the only SQL-level
support object needed is a single handler function identified by having
a special return type. This lets us get rid of the supporting catalog
altogether, so that no custom DDL support is needed for the feature.
Adjust the API so that it can support non-constant tablesample arguments
(the original coding assumed we could evaluate the argument expressions at
ExecInitSampleScan time, which is undesirable even if it weren't outright
unsafe), and discourage sampling methods from looking at invisible tuples.
Make sure that the BERNOULLI and SYSTEM methods are genuinely repeatable
within and across queries, as required by the SQL standard, and deal more
honestly with methods that can't support that requirement.
Make a full code-review pass over the tablesample additions, and fix
assorted bugs, omissions, infelicities, and cosmetic issues (such as
failure to put the added code stanzas in a consistent ordering).
Improve EXPLAIN's output of tablesample plans, too.
Back-patch to 9.5 so that we don't have to support the original API
in production.
2015-07-25 20:39:00 +02:00
|
|
|
%type <node> tablesample_clause opt_repeatable_clause
|
Improve handling of "UPDATE ... SET (column_list) = row_constructor".
Previously, the right-hand side of a multiple-column assignment, if it
wasn't a sub-SELECT, had to be a simple parenthesized expression list,
because gram.y was responsible for "bursting" the construct into
independent column assignments. This had the minor defect that you
couldn't write ROW (though you should be able to, since the standard says
this is a row constructor), and the rather larger defect that unlike other
uses of row constructors, we would not expand a "foo.*" item into multiple
columns.
Fix that by changing the RHS to be just "a_expr" in the grammar, leaving
it to transformMultiAssignRef to separate the elements of a RowExpr;
which it will do only after performing standard transformation of the
RowExpr, so that "foo.*" behaves as expected.
The key reason we didn't do that before was the hard-wired handling of
DEFAULT tokens (SetToDefault nodes). This patch deals with that issue by
allowing DEFAULT in any a_expr and having parse analysis throw an error
if SetToDefault is found in an unexpected place. That's an improvement
anyway since the error can be more specific than just "syntax error".
The SQL standard suggests that the RHS could be any a_expr yielding a
suitable row value. This patch doesn't really move the goal posts in that
respect --- you're still limited to RowExpr or a sub-SELECT --- but it does
fix the grammar restriction, so it provides some tangible progress towards
a full implementation. And the limitation is now documented by an explicit
error message rather than an unhelpful "syntax error".
Discussion: <8542.1479742008@sss.pgh.pa.us>
2016-11-22 21:19:57 +01:00
|
|
|
%type <target> target_el set_target insert_column_item
|
2002-09-22 23:44:43 +02:00
|
|
|
|
2008-12-19 17:25:19 +01:00
|
|
|
%type <str> generic_option_name
|
|
|
|
|
%type <node> generic_option_arg
|
2009-04-04 23:12:31 +02:00
|
|
|
%type <defelt> generic_option_elem alter_generic_option_elem
|
2008-12-19 17:25:19 +01:00
|
|
|
%type <list> generic_option_list alter_generic_option_list
|
2015-05-15 13:09:57 +02:00
|
|
|
|
Fix a few issues with REINDEX grammar
This addresses a couple of bugs in the REINDEX grammar, introduced by
83011ce:
- A name was never specified for DATABASE/SYSTEM, even if the query
included one. This caused such REINDEX queries to always work with any
object name, but we should complain if the object name specified does
not match the name of the database we are connected to. A test is added
for this case in the main regression test suite, provided by Álvaro.
- REINDEX SYSTEM CONCURRENTLY [name] was getting rejected in the
parser. Concurrent rebuilds are not supported for catalogs but the
error provided at execution time is more helpful for the user, and
allowing this flavor results in a simplification of the parsing logic.
- REINDEX DATABASE CONCURRENTLY was rebuilding the index in a
non-concurrent way, as the option was not being appended correctly in
the list of DefElems in ReindexStmt (REINDEX (CONCURRENTLY) DATABASE was
working fine. A test is added in the TAP tests of reindexdb for this
case, where we already have a REINDEX DATABASE CONCURRENTLY query
running on a small-ish instance. This relies on the work done in
2cbc3c1 for SYSTEM, but here we check if the OIDs of the index relations
match or not after the concurrent rebuild. Note that in order to get
this part to work, I had to tweak the tests so as the index OID and
names are saved separately. This change not affect the reliability or
of the coverage of the existing tests.
While on it, I have implemented a tweak in the grammar to reduce the
parsing by one branch, simplifying things even more.
Author: Michael Paquier, Álvaro Herrera
Discussion: https://postgr.es/m/YttqI6O64wDxGn0K@paquier.xyz
2022-07-26 03:16:26 +02:00
|
|
|
%type <ival> reindex_target_relation reindex_target_all
|
2022-07-22 19:23:39 +02:00
|
|
|
%type <list> opt_reindex_option_list
|
2015-05-15 13:09:57 +02:00
|
|
|
|
2009-09-21 22:10:21 +02:00
|
|
|
%type <node> copy_generic_opt_arg copy_generic_opt_arg_list_item
|
|
|
|
|
%type <defelt> copy_generic_opt_elem
|
|
|
|
|
%type <list> copy_generic_opt_list copy_generic_opt_arg_list
|
|
|
|
|
%type <list> copy_options
|
2008-12-19 17:25:19 +01:00
|
|
|
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
%type <typnam> Typename SimpleTypename ConstTypename
|
2022-09-01 23:07:14 +02:00
|
|
|
GenericType Numeric opt_float
|
2002-09-22 23:44:43 +02:00
|
|
|
Character ConstCharacter
|
|
|
|
|
CharacterWithLength CharacterWithoutLength
|
|
|
|
|
ConstDatetime ConstInterval
|
|
|
|
|
Bit ConstBit BitWithLength BitWithoutLength
|
2002-05-03 02:32:19 +02:00
|
|
|
%type <str> character
|
1998-04-08 08:39:01 +02:00
|
|
|
%type <str> extract_arg
|
2012-04-21 04:46:20 +02:00
|
|
|
%type <boolean> opt_varying opt_timezone opt_no_inherit
|
1997-10-25 07:56:41 +02:00
|
|
|
|
2005-07-31 19:19:22 +02:00
|
|
|
%type <ival> Iconst SignedIconst
|
2010-02-16 23:34:57 +01:00
|
|
|
%type <str> Sconst comment_text notify_payload
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
%type <str> RoleId opt_boolean_or_string
|
2007-09-03 20:46:30 +02:00
|
|
|
%type <list> var_list
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
%type <str> ColId ColLabel BareColLabel
|
2013-06-03 02:09:20 +02:00
|
|
|
%type <str> NonReservedWord NonReservedWord_or_Sconst
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
%type <str> var_name type_function_name param_name
|
2021-01-04 17:52:00 +01:00
|
|
|
%type <str> createdb_opt_name plassign_target
|
2002-09-22 23:44:43 +02:00
|
|
|
%type <node> var_value zone_value
|
2016-12-28 18:00:00 +01:00
|
|
|
%type <rolespec> auth_ident RoleSpec opt_granted_by
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
%type <publicationobjectspec> PublicationObjSpec
|
1997-10-25 07:56:41 +02:00
|
|
|
|
2006-12-30 22:21:56 +01:00
|
|
|
%type <keyword> unreserved_keyword type_func_name_keyword
|
2002-09-22 23:44:43 +02:00
|
|
|
%type <keyword> col_name_keyword reserved_keyword
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
%type <keyword> bare_label_keyword
|
2002-05-02 20:44:11 +02:00
|
|
|
|
2006-12-30 22:21:56 +01:00
|
|
|
%type <node> TableConstraint TableLikeClause
|
2009-10-12 21:49:24 +02:00
|
|
|
%type <ival> TableLikeOptionList TableLikeOption
|
2022-07-13 12:21:45 +02:00
|
|
|
%type <str> column_compression opt_column_compression column_storage opt_column_storage
|
2000-03-01 06:18:20 +01:00
|
|
|
%type <list> ColQualList
|
2002-09-22 23:44:43 +02:00
|
|
|
%type <node> ColConstraint ColConstraintElem ConstraintAttr
|
2021-12-08 11:09:44 +01:00
|
|
|
%type <ival> key_match
|
|
|
|
|
%type <keyaction> key_delete key_update key_action
|
|
|
|
|
%type <keyactions> key_actions
|
2011-06-16 01:05:11 +02:00
|
|
|
%type <ival> ConstraintAttributeSpec ConstraintAttributeElem
|
2011-01-25 21:42:03 +01:00
|
|
|
%type <str> ExistingIndex
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1999-09-29 18:06:40 +02:00
|
|
|
%type <list> constraints_set_list
|
2002-06-17 22:27:43 +02:00
|
|
|
%type <boolean> constraints_set_mode
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
%type <str> OptTableSpace OptConsTableSpace
|
2016-12-28 18:00:00 +01:00
|
|
|
%type <rolespec> OptTableSpaceOwner
|
2013-07-18 23:10:16 +02:00
|
|
|
%type <ival> opt_check_option
|
1999-09-29 18:06:40 +02:00
|
|
|
|
2010-09-28 02:55:27 +02:00
|
|
|
%type <str> opt_provider security_label
|
|
|
|
|
|
2006-12-21 17:05:16 +01:00
|
|
|
%type <target> xml_attribute_el
|
|
|
|
|
%type <list> xml_attribute_list xml_attributes
|
2006-12-24 01:29:20 +01:00
|
|
|
%type <node> xml_root_version opt_xml_root_standalone
|
2010-08-05 06:21:54 +02:00
|
|
|
%type <node> xmlexists_argument
|
2007-02-03 15:06:56 +01:00
|
|
|
%type <ival> document_or_content
|
2023-03-15 21:58:59 +01:00
|
|
|
%type <boolean> xml_indent_option xml_whitespace_option
|
2017-03-08 16:39:37 +01:00
|
|
|
%type <list> xmltable_column_list xmltable_column_option_list
|
|
|
|
|
%type <node> xmltable_column_el
|
|
|
|
|
%type <defelt> xmltable_column_option_el
|
|
|
|
|
%type <list> xml_namespace_list
|
|
|
|
|
%type <target> xml_namespace_el
|
2006-12-21 17:05:16 +01:00
|
|
|
|
2013-06-28 16:18:00 +02:00
|
|
|
%type <node> func_application func_expr_common_subexpr
|
|
|
|
|
%type <node> func_expr func_expr_windowless
|
2011-11-01 20:50:00 +01:00
|
|
|
%type <node> common_table_expr
|
|
|
|
|
%type <with> with_clause opt_with_clause
|
2008-10-04 23:56:55 +02:00
|
|
|
%type <list> cte_list
|
|
|
|
|
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
%type <list> within_group_clause
|
|
|
|
|
%type <node> filter_clause
|
2008-12-28 19:54:01 +01:00
|
|
|
%type <list> window_clause window_definition_list opt_partition_clause
|
|
|
|
|
%type <windef> window_definition over_clause window_specification
|
2010-02-12 18:33:21 +01:00
|
|
|
opt_frame_clause frame_extent frame_bound
|
Support all SQL:2011 options for window frame clauses.
This patch adds the ability to use "RANGE offset PRECEDING/FOLLOWING"
frame boundaries in window functions. We'd punted on that back in the
original patch to add window functions, because it was not clear how to
do it in a reasonably data-type-extensible fashion. That problem is
resolved here by adding the ability for btree operator classes to provide
an "in_range" support function that defines how to add or subtract the
RANGE offset value. Factoring it this way also allows the operator class
to avoid overflow problems near the ends of the datatype's range, if it
wishes to expend effort on that. (In the committed patch, the integer
opclasses handle that issue, but it did not seem worth the trouble to
avoid overflow failures for datetime types.)
The patch includes in_range support for the integer_ops opfamily
(int2/int4/int8) as well as the standard datetime types. Support for
other numeric types has been requested, but that seems like suitable
material for a follow-on patch.
In addition, the patch adds GROUPS mode which counts the offset in
ORDER-BY peer groups rather than rows, and it adds the frame_exclusion
options specified by SQL:2011. As far as I can see, we are now fully
up to spec on window framing options.
Existing behaviors remain unchanged, except that I changed the errcode
for a couple of existing error reports to meet the SQL spec's expectation
that negative "offset" values should be reported as SQLSTATE 22013.
Internally and in relevant parts of the documentation, we now consistently
use the terminology "offset PRECEDING/FOLLOWING" rather than "value
PRECEDING/FOLLOWING", since the term "value" is confusingly vague.
Oliver Ford, reviewed and whacked around some by me
Discussion: https://postgr.es/m/CAGMVOdu9sivPAxbNN0X+q19Sfv9edEPv=HibOJhB14TJv_RCQg@mail.gmail.com
2018-02-07 06:06:50 +01:00
|
|
|
%type <ival> opt_window_exclusion_clause
|
2008-12-28 19:54:01 +01:00
|
|
|
%type <str> opt_existing_window_name
|
2012-09-22 18:53:31 +02:00
|
|
|
%type <boolean> opt_if_not_exists
|
2022-02-03 11:29:54 +01:00
|
|
|
%type <boolean> opt_unique_null_treatment
|
2017-04-06 14:33:16 +02:00
|
|
|
%type <ival> generated_when override_kind
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
%type <partspec> PartitionSpec OptPartitionSpec
|
|
|
|
|
%type <partelem> part_elem
|
|
|
|
|
%type <list> part_params
|
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
|
|
|
%type <partboundspec> PartitionBoundSpec
|
2019-01-25 11:27:59 +01:00
|
|
|
%type <list> hash_partbound
|
Add hash partitioning.
Hash partitioning is useful when you want to partition a growing data
set evenly. This can be useful to keep table sizes reasonable, which
makes maintenance operations such as VACUUM faster, or to enable
partition-wise join.
At present, we still depend on constraint exclusion for partitioning
pruning, and the shape of the partition constraints for hash
partitioning is such that that doesn't work. Work is underway to fix
that, which should both improve performance and make partitioning
pruning work with hash partitioning.
Amul Sul, reviewed and tested by Dilip Kumar, Ashutosh Bapat, Yugo
Nagata, Rajkumar Raghuwanshi, Jesper Pedersen, and by me. A few
final tweaks also by me.
Discussion: http://postgr.es/m/CAAJ_b96fhpJAP=ALbETmeLk1Uni_GFZD938zgenhF49qgDTjaQ@mail.gmail.com
2017-11-10 00:07:25 +01:00
|
|
|
%type <defelt> hash_partbound_elem
|
2002-03-21 17:02:16 +01:00
|
|
|
|
Allow configurable LZ4 TOAST compression.
There is now a per-column COMPRESSION option which can be set to pglz
(the default, and the only option in up until now) or lz4. Or, if you
like, you can set the new default_toast_compression GUC to lz4, and
then that will be the default for new table columns for which no value
is specified. We don't have lz4 support in the PostgreSQL code, so
to use lz4 compression, PostgreSQL must be built --with-lz4.
In general, TOAST compression means compression of individual column
values, not the whole tuple, and those values can either be compressed
inline within the tuple or compressed and then stored externally in
the TOAST table, so those properties also apply to this feature.
Prior to this commit, a TOAST pointer has two unused bits as part of
the va_extsize field, and a compessed datum has two unused bits as
part of the va_rawsize field. These bits are unused because the length
of a varlena is limited to 1GB; we now use them to indicate the
compression type that was used. This means we only have bit space for
2 more built-in compresison types, but we could work around that
problem, if necessary, by introducing a new vartag_external value for
any further types we end up wanting to add. Hopefully, it won't be
too important to offer a wide selection of algorithms here, since
each one we add not only takes more coding but also adds a build
dependency for every packager. Nevertheless, it seems worth doing
at least this much, because LZ4 gets better compression than PGLZ
with less CPU usage.
It's possible for LZ4-compressed datums to leak into composite type
values stored on disk, just as it is for PGLZ. It's also possible for
LZ4-compressed attributes to be copied into a different table via SQL
commands such as CREATE TABLE AS or INSERT .. SELECT. It would be
expensive to force such values to be decompressed, so PostgreSQL has
never done so. For the same reasons, we also don't force recompression
of already-compressed values even if the target table prefers a
different compression method than was used for the source data. These
architectural decisions are perhaps arguable but revisiting them is
well beyond the scope of what seemed possible to do as part of this
project. However, it's relatively cheap to recompress as part of
VACUUM FULL or CLUSTER, so this commit adjusts those commands to do
so, if the configured compression method of the table happens not to
match what was used for some column value stored therein.
Dilip Kumar. The original patches on which this work was based were
written by Ildus Kurbangaliev, and those were patches were based on
even earlier work by Nikita Glukhov, but the design has since changed
very substantially, since allow a potentially large number of
compression methods that could be added and dropped on a running
system proved too problematic given some of the architectural issues
mentioned above; the choice of which specific compression method to
add first is now different; and a lot of the code has been heavily
refactored. More recently, Justin Przyby helped quite a bit with
testing and reviewing and this version also includes some code
contributions from him. Other design input and review from Tomas
Vondra, Álvaro Herrera, Andres Freund, Oleg Bartunov, Alexander
Korotkov, and me.
Discussion: http://postgr.es/m/20170907194236.4cefce96%40wp.localdomain
Discussion: http://postgr.es/m/CAFiTN-uUpX3ck%3DK0mLEk-G_kUQY%3DSNOTeqdaNRR9FMdQrHKebw%40mail.gmail.com
2021-03-19 20:10:38 +01:00
|
|
|
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
%type <node> json_format_clause_opt
|
|
|
|
|
json_value_expr
|
|
|
|
|
json_output_clause_opt
|
|
|
|
|
json_name_and_value
|
|
|
|
|
json_aggregate_func
|
|
|
|
|
|
|
|
|
|
%type <list> json_name_and_value_list
|
|
|
|
|
json_value_expr_list
|
|
|
|
|
json_array_aggregate_order_by_clause_opt
|
|
|
|
|
|
|
|
|
|
%type <ival> json_encoding_clause_opt
|
SQL/JSON: support the IS JSON predicate
This patch introduces the SQL standard IS JSON predicate. It operates
on text and bytea values representing JSON, as well as on the json and
jsonb types. Each test has IS and IS NOT variants and supports a WITH
UNIQUE KEYS flag. The tests are:
IS JSON [VALUE]
IS JSON ARRAY
IS JSON OBJECT
IS JSON SCALAR
These should be self-explanatory.
The WITH UNIQUE KEYS flag makes these return false when duplicate keys
exist in any object within the value, not necessarily directly contained
in the outermost object.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Author: Andrew Dunstan <andrew@dunslane.net>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-31 22:34:04 +02:00
|
|
|
json_predicate_type_constraint
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
|
|
|
|
|
%type <boolean> json_key_uniqueness_constraint_opt
|
|
|
|
|
json_object_constructor_null_clause_opt
|
|
|
|
|
json_array_constructor_null_clause_opt
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*
|
2009-07-14 22:24:10 +02:00
|
|
|
* Non-keyword token types. These are hard-wired into the "flex" lexer.
|
|
|
|
|
* They must be listed first so that their numeric codes do not depend on
|
2017-04-05 06:38:25 +02:00
|
|
|
* the set of keywords. PL/pgSQL depends on this so that it can share the
|
|
|
|
|
* same lexer. If you add/change tokens here, fix PL/pgSQL to match!
|
2009-07-14 22:24:10 +02:00
|
|
|
*
|
Reduce size of backend scanner's tables.
Previously, the core scanner's yy_transition[] array had 37045 elements.
Since that number is larger than INT16_MAX, Flex generated the array to
contain 32-bit integers. By reimplementing some of the bulkier scanner
rules, this patch reduces the array to 20495 elements. The much smaller
total length, combined with the consequent use of 16-bit integers for
the array elements reduces the binary size by over 200kB. This was
accomplished in two ways:
1. Consolidate handling of quote continuations into a new start condition,
rather than duplicating that logic for five different string types.
2. Treat Unicode strings and identifiers followed by a UESCAPE sequence
as three separate tokens, rather than one. The logic to de-escape
Unicode strings is moved to the filter code in parser.c, which already
had the ability to provide special processing for token sequences.
While we could have implemented the conversion in the grammar, that
approach was rejected for performance and maintainability reasons.
Performance in microbenchmarks of raw parsing seems equal or slightly
faster in most cases, and it's reasonable to expect that in real-world
usage (with more competition for the CPU cache) there will be a larger
win. The exception is UESCAPE sequences; lexing those is about 10%
slower, primarily because the scanner now has to be called three times
rather than one. This seems acceptable since that feature is very
rarely used.
The psql and epcg lexers are likewise modified, primarily because we
want to keep them all in sync. Since those lexers don't use the
space-hogging -CF option, the space savings is much less, but it's
still good for perhaps 10kB apiece.
While at it, merge the ecpg lexer's handling of C-style comments used
in SQL and in C. Those have different rules regarding nested comments,
but since we already have the ability to keep track of the previous
start condition, we can use that to handle both cases within a single
start condition. This matches the core scanner more closely.
John Naylor
Discussion: https://postgr.es/m/CACPNZCvaoa3EgVWm5yZhcSTX6RAtaLgniCPcBVOCwm8h3xpWkw@mail.gmail.com
2020-01-13 21:04:31 +01:00
|
|
|
* UIDENT and USCONST are reduced to IDENT and SCONST in parser.c, so that
|
|
|
|
|
* they need no productions here; but we must assign token codes to them.
|
|
|
|
|
*
|
2010-05-30 20:10:41 +02:00
|
|
|
* DOT_DOT is unused in the core SQL grammar, and so will always provoke
|
2017-04-05 06:38:25 +02:00
|
|
|
* parse errors. It is needed by PL/pgSQL.
|
2009-07-14 22:24:10 +02:00
|
|
|
*/
|
Reduce size of backend scanner's tables.
Previously, the core scanner's yy_transition[] array had 37045 elements.
Since that number is larger than INT16_MAX, Flex generated the array to
contain 32-bit integers. By reimplementing some of the bulkier scanner
rules, this patch reduces the array to 20495 elements. The much smaller
total length, combined with the consequent use of 16-bit integers for
the array elements reduces the binary size by over 200kB. This was
accomplished in two ways:
1. Consolidate handling of quote continuations into a new start condition,
rather than duplicating that logic for five different string types.
2. Treat Unicode strings and identifiers followed by a UESCAPE sequence
as three separate tokens, rather than one. The logic to de-escape
Unicode strings is moved to the filter code in parser.c, which already
had the ability to provide special processing for token sequences.
While we could have implemented the conversion in the grammar, that
approach was rejected for performance and maintainability reasons.
Performance in microbenchmarks of raw parsing seems equal or slightly
faster in most cases, and it's reasonable to expect that in real-world
usage (with more competition for the CPU cache) there will be a larger
win. The exception is UESCAPE sequences; lexing those is about 10%
slower, primarily because the scanner now has to be called three times
rather than one. This seems acceptable since that feature is very
rarely used.
The psql and epcg lexers are likewise modified, primarily because we
want to keep them all in sync. Since those lexers don't use the
space-hogging -CF option, the space savings is much less, but it's
still good for perhaps 10kB apiece.
While at it, merge the ecpg lexer's handling of C-style comments used
in SQL and in C. Those have different rules regarding nested comments,
but since we already have the ability to keep track of the previous
start condition, we can use that to handle both cases within a single
start condition. This matches the core scanner more closely.
John Naylor
Discussion: https://postgr.es/m/CACPNZCvaoa3EgVWm5yZhcSTX6RAtaLgniCPcBVOCwm8h3xpWkw@mail.gmail.com
2020-01-13 21:04:31 +01:00
|
|
|
%token <str> IDENT UIDENT FCONST SCONST USCONST BCONST XCONST Op
|
2009-07-14 22:24:10 +02:00
|
|
|
%token <ival> ICONST PARAM
|
Allow named parameters to be specified using => in addition to :=
SQL has standardized on => as the use of to specify named parameters,
and we've wanted for many years to support the same syntax ourselves,
but this has been complicated by the possible use of => as an operator
name. In PostgreSQL 9.0, we began emitting a warning when an operator
named => was defined, and in PostgreSQL 9.2, we stopped shipping a
=>(text, text) operator as part of hstore. By the time the next major
version of PostgreSQL is released, => will have been deprecated for a
full five years, so hopefully there won't be too many people still
relying on it. We continue to support := for compatibility with
previous PostgreSQL releases.
Pavel Stehule, reviewed by Petr Jelinek, with a few documentation
tweaks by me.
2015-03-10 15:59:11 +01:00
|
|
|
%token TYPECAST DOT_DOT COLON_EQUALS EQUALS_GREATER
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
%token LESS_EQUALS GREATER_EQUALS NOT_EQUALS
|
2009-07-14 22:24:10 +02:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If you want to make any keyword changes, update the keyword table in
|
|
|
|
|
* src/include/parser/kwlist.h and add new keywords to the appropriate one
|
|
|
|
|
* of the reserved-or-not-so-reserved keyword lists, below; search
|
|
|
|
|
* this file for "Keyword category lists".
|
1997-10-25 07:56:41 +02:00
|
|
|
*/
|
|
|
|
|
|
2002-05-19 17:16:55 +02:00
|
|
|
/* ordinary key words in alphabetical order */
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
%token <keyword> ABORT_P ABSENT ABSOLUTE_P ACCESS ACTION ADD_P ADMIN AFTER
|
2007-03-20 00:38:32 +01:00
|
|
|
AGGREGATE ALL ALSO ALTER ALWAYS ANALYSE ANALYZE AND ANY ARRAY AS ASC
|
2021-04-07 21:30:08 +02:00
|
|
|
ASENSITIVE ASSERTION ASSIGNMENT ASYMMETRIC ATOMIC AT ATTACH ATTRIBUTE AUTHORIZATION
|
2002-05-19 17:16:55 +02:00
|
|
|
|
2003-02-10 05:44:47 +01:00
|
|
|
BACKWARD BEFORE BEGIN_P BETWEEN BIGINT BINARY BIT
|
2021-02-01 13:54:59 +01:00
|
|
|
BOOLEAN_P BOTH BREADTH BY
|
2002-05-19 17:16:55 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
CACHE CALL CALLED CASCADE CASCADED CASE CAST CATALOG_P CHAIN CHAR_P
|
2002-09-22 23:44:43 +02:00
|
|
|
CHARACTER CHARACTERISTICS CHECK CHECKPOINT CLASS CLOSE
|
2017-03-08 16:39:37 +01:00
|
|
|
CLUSTER COALESCE COLLATE COLLATION COLUMN COLUMNS COMMENT COMMENTS COMMIT
|
2022-09-01 23:07:14 +02:00
|
|
|
COMMITTED COMPRESSION CONCURRENTLY CONFIGURATION CONFLICT
|
Allow configurable LZ4 TOAST compression.
There is now a per-column COMPRESSION option which can be set to pglz
(the default, and the only option in up until now) or lz4. Or, if you
like, you can set the new default_toast_compression GUC to lz4, and
then that will be the default for new table columns for which no value
is specified. We don't have lz4 support in the PostgreSQL code, so
to use lz4 compression, PostgreSQL must be built --with-lz4.
In general, TOAST compression means compression of individual column
values, not the whole tuple, and those values can either be compressed
inline within the tuple or compressed and then stored externally in
the TOAST table, so those properties also apply to this feature.
Prior to this commit, a TOAST pointer has two unused bits as part of
the va_extsize field, and a compessed datum has two unused bits as
part of the va_rawsize field. These bits are unused because the length
of a varlena is limited to 1GB; we now use them to indicate the
compression type that was used. This means we only have bit space for
2 more built-in compresison types, but we could work around that
problem, if necessary, by introducing a new vartag_external value for
any further types we end up wanting to add. Hopefully, it won't be
too important to offer a wide selection of algorithms here, since
each one we add not only takes more coding but also adds a build
dependency for every packager. Nevertheless, it seems worth doing
at least this much, because LZ4 gets better compression than PGLZ
with less CPU usage.
It's possible for LZ4-compressed datums to leak into composite type
values stored on disk, just as it is for PGLZ. It's also possible for
LZ4-compressed attributes to be copied into a different table via SQL
commands such as CREATE TABLE AS or INSERT .. SELECT. It would be
expensive to force such values to be decompressed, so PostgreSQL has
never done so. For the same reasons, we also don't force recompression
of already-compressed values even if the target table prefers a
different compression method than was used for the source data. These
architectural decisions are perhaps arguable but revisiting them is
well beyond the scope of what seemed possible to do as part of this
project. However, it's relatively cheap to recompress as part of
VACUUM FULL or CLUSTER, so this commit adjusts those commands to do
so, if the configured compression method of the table happens not to
match what was used for some column value stored therein.
Dilip Kumar. The original patches on which this work was based were
written by Ildus Kurbangaliev, and those were patches were based on
even earlier work by Nikita Glukhov, but the design has since changed
very substantially, since allow a potentially large number of
compression methods that could be added and dropped on a running
system proved too problematic given some of the architectural issues
mentioned above; the choice of which specific compression method to
add first is now different; and a lot of the code has been heavily
refactored. More recently, Justin Przyby helped quite a bit with
testing and reviewing and this version also includes some code
contributions from him. Other design input and review from Tomas
Vondra, Álvaro Herrera, Andres Freund, Oleg Bartunov, Alexander
Korotkov, and me.
Discussion: http://postgr.es/m/20170907194236.4cefce96%40wp.localdomain
Discussion: http://postgr.es/m/CAFiTN-uUpX3ck%3DK0mLEk-G_kUQY%3DSNOTeqdaNRR9FMdQrHKebw%40mail.gmail.com
2021-03-19 20:10:38 +01:00
|
|
|
CONNECTION CONSTRAINT CONSTRAINTS CONTENT_P CONTINUE_P CONVERSION_P COPY
|
|
|
|
|
COST CREATE CROSS CSV CUBE CURRENT_P
|
2008-10-27 10:37:47 +01:00
|
|
|
CURRENT_CATALOG CURRENT_DATE CURRENT_ROLE CURRENT_SCHEMA
|
2007-06-11 03:16:30 +02:00
|
|
|
CURRENT_TIME CURRENT_TIMESTAMP CURRENT_USER CURSOR CYCLE
|
2002-05-19 17:16:55 +02:00
|
|
|
|
2008-10-21 10:38:16 +02:00
|
|
|
DATA_P DATABASE DAY_P DEALLOCATE DEC DECIMAL_P DECLARE DEFAULT DEFAULTS
|
2021-02-01 13:54:59 +01:00
|
|
|
DEFERRABLE DEFERRED DEFINER DELETE_P DELIMITER DELIMITERS DEPENDS DEPTH DESC
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
DETACH DICTIONARY DISABLE_P DISCARD DISTINCT DO DOCUMENT_P DOMAIN_P
|
|
|
|
|
DOUBLE_P DROP
|
2002-05-19 17:16:55 +02:00
|
|
|
|
2022-09-01 23:07:14 +02:00
|
|
|
EACH ELSE ENABLE_P ENCODING ENCRYPTED END_P ENUM_P ESCAPE EVENT EXCEPT
|
|
|
|
|
EXCLUDE EXCLUDING EXCLUSIVE EXECUTE EXISTS EXPLAIN EXPRESSION
|
2011-02-08 22:08:41 +01:00
|
|
|
EXTENSION EXTERNAL EXTRACT
|
2002-05-19 17:16:55 +02:00
|
|
|
|
ALTER TABLE ... DETACH PARTITION ... CONCURRENTLY
Allow a partition be detached from its partitioned table without
blocking concurrent queries, by running in two transactions and only
requiring ShareUpdateExclusive in the partitioned table.
Because it runs in two transactions, it cannot be used in a transaction
block. This is the main reason to use dedicated syntax: so that users
can choose to use the original mode if they need it. But also, it
doesn't work when a default partition exists (because an exclusive lock
would still need to be obtained on it, in order to change its partition
constraint.)
In case the second transaction is cancelled or a crash occurs, there's
ALTER TABLE .. DETACH PARTITION .. FINALIZE, which executes the final
steps.
The main trick to make this work is the addition of column
pg_inherits.inhdetachpending, initially false; can only be set true in
the first part of this command. Once that is committed, concurrent
transactions that use a PartitionDirectory will include or ignore
partitions so marked: in optimizer they are ignored if the row is marked
committed for the snapshot; in executor they are always included. As a
result, and because of the way PartitionDirectory caches partition
descriptors, queries that were planned before the detach will see the
rows in the detached partition and queries that are planned after the
detach, won't.
A CHECK constraint is created that duplicates the partition constraint.
This is probably not strictly necessary, and some users will prefer to
remove it afterwards, but if the partition is re-attached to a
partitioned table, the constraint needn't be rechecked.
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Reviewed-by: Amit Langote <amitlangote09@gmail.com>
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>
Discussion: https://postgr.es/m/20200803234854.GA24158@alvherre.pgsql
2021-03-25 22:00:28 +01:00
|
|
|
FALSE_P FAMILY FETCH FILTER FINALIZE FIRST_P FLOAT_P FOLLOWING FOR
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
FORCE FOREIGN FORMAT FORWARD FREEZE FROM FULL FUNCTION FUNCTIONS
|
2002-05-19 17:16:55 +02:00
|
|
|
|
Support all SQL:2011 options for window frame clauses.
This patch adds the ability to use "RANGE offset PRECEDING/FOLLOWING"
frame boundaries in window functions. We'd punted on that back in the
original patch to add window functions, because it was not clear how to
do it in a reasonably data-type-extensible fashion. That problem is
resolved here by adding the ability for btree operator classes to provide
an "in_range" support function that defines how to add or subtract the
RANGE offset value. Factoring it this way also allows the operator class
to avoid overflow problems near the ends of the datatype's range, if it
wishes to expend effort on that. (In the committed patch, the integer
opclasses handle that issue, but it did not seem worth the trouble to
avoid overflow failures for datetime types.)
The patch includes in_range support for the integer_ops opfamily
(int2/int4/int8) as well as the standard datetime types. Support for
other numeric types has been requested, but that seems like suitable
material for a follow-on patch.
In addition, the patch adds GROUPS mode which counts the offset in
ORDER-BY peer groups rather than rows, and it adds the frame_exclusion
options specified by SQL:2011. As far as I can see, we are now fully
up to spec on window framing options.
Existing behaviors remain unchanged, except that I changed the errcode
for a couple of existing error reports to meet the SQL spec's expectation
that negative "offset" values should be reported as SQLSTATE 22013.
Internally and in relevant parts of the documentation, we now consistently
use the terminology "offset PRECEDING/FOLLOWING" rather than "value
PRECEDING/FOLLOWING", since the term "value" is confusingly vague.
Oliver Ford, reviewed and whacked around some by me
Discussion: https://postgr.es/m/CAGMVOdu9sivPAxbNN0X+q19Sfv9edEPv=HibOJhB14TJv_RCQg@mail.gmail.com
2018-02-07 06:06:50 +01:00
|
|
|
GENERATED GLOBAL GRANT GRANTED GREATEST GROUP_P GROUPING GROUPS
|
2002-06-18 19:56:41 +02:00
|
|
|
|
2005-12-27 05:00:08 +01:00
|
|
|
HANDLER HAVING HEADER_P HOLD HOUR_P
|
2002-05-19 17:16:55 +02:00
|
|
|
|
2018-04-07 22:00:39 +02:00
|
|
|
IDENTITY_P IF_P ILIKE IMMEDIATE IMMUTABLE IMPLICIT_P IMPORT_P IN_P INCLUDE
|
2023-03-15 21:58:59 +01:00
|
|
|
INCLUDING INCREMENT INDENT INDEX INDEXES INHERIT INHERITS INITIALLY INLINE_P
|
2010-02-08 05:33:55 +01:00
|
|
|
INNER_P INOUT INPUT_P INSENSITIVE INSERT INSTEAD INT_P INTEGER
|
2008-05-17 01:36:05 +02:00
|
|
|
INTERSECT INTERVAL INTO INVOKER IS ISNULL ISOLATION
|
2002-05-19 17:16:55 +02:00
|
|
|
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
JOIN JSON JSON_ARRAY JSON_ARRAYAGG JSON_OBJECT JSON_OBJECTAGG
|
2002-11-02 19:41:22 +01:00
|
|
|
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
KEY KEYS
|
2002-05-19 17:16:55 +02:00
|
|
|
|
2014-07-02 01:02:21 +02:00
|
|
|
LABEL LANGUAGE LARGE_P LAST_P LATERAL_P
|
2012-08-08 01:02:54 +02:00
|
|
|
LEADING LEAKPROOF LEAST LEFT LEVEL LIKE LIMIT LISTEN LOAD LOCAL
|
2020-04-08 10:37:27 +02:00
|
|
|
LOCALTIME LOCALTIMESTAMP LOCATION LOCK_P LOCKED LOGGED
|
2002-05-19 17:16:55 +02:00
|
|
|
|
2022-03-28 16:45:58 +02:00
|
|
|
MAPPING MATCH MATCHED MATERIALIZED MAXVALUE MERGE METHOD
|
|
|
|
|
MINUTE_P MINVALUE MODE MONTH_P MOVE
|
2002-05-19 17:16:55 +02:00
|
|
|
|
2022-09-01 23:07:14 +02:00
|
|
|
NAME_P NAMES NATIONAL NATURAL NCHAR NEW NEXT NFC NFD NFKC NFKD NO NONE
|
|
|
|
|
NORMALIZE NORMALIZED
|
2017-05-12 14:57:01 +02:00
|
|
|
NOT NOTHING NOTIFY NOTNULL NOWAIT NULL_P NULLIF
|
2010-12-29 11:05:03 +01:00
|
|
|
NULLS_P NUMERIC
|
2002-06-18 19:56:41 +02:00
|
|
|
|
2022-09-01 23:07:14 +02:00
|
|
|
OBJECT_P OF OFF OFFSET OIDS OLD ON ONLY OPERATOR OPTION OPTIONS OR
|
Support all SQL:2011 options for window frame clauses.
This patch adds the ability to use "RANGE offset PRECEDING/FOLLOWING"
frame boundaries in window functions. We'd punted on that back in the
original patch to add window functions, because it was not clear how to
do it in a reasonably data-type-extensible fashion. That problem is
resolved here by adding the ability for btree operator classes to provide
an "in_range" support function that defines how to add or subtract the
RANGE offset value. Factoring it this way also allows the operator class
to avoid overflow problems near the ends of the datatype's range, if it
wishes to expend effort on that. (In the committed patch, the integer
opclasses handle that issue, but it did not seem worth the trouble to
avoid overflow failures for datetime types.)
The patch includes in_range support for the integer_ops opfamily
(int2/int4/int8) as well as the standard datetime types. Support for
other numeric types has been requested, but that seems like suitable
material for a follow-on patch.
In addition, the patch adds GROUPS mode which counts the offset in
ORDER-BY peer groups rather than rows, and it adds the frame_exclusion
options specified by SQL:2011. As far as I can see, we are now fully
up to spec on window framing options.
Existing behaviors remain unchanged, except that I changed the errcode
for a couple of existing error reports to meet the SQL spec's expectation
that negative "offset" values should be reported as SQLSTATE 22013.
Internally and in relevant parts of the documentation, we now consistently
use the terminology "offset PRECEDING/FOLLOWING" rather than "value
PRECEDING/FOLLOWING", since the term "value" is confusingly vague.
Oliver Ford, reviewed and whacked around some by me
Discussion: https://postgr.es/m/CAGMVOdu9sivPAxbNN0X+q19Sfv9edEPv=HibOJhB14TJv_RCQg@mail.gmail.com
2018-02-07 06:06:50 +01:00
|
|
|
ORDER ORDINALITY OTHERS OUT_P OUTER_P
|
|
|
|
|
OVER OVERLAPS OVERLAY OVERRIDING OWNED OWNER
|
2002-05-19 17:16:55 +02:00
|
|
|
|
2022-09-01 23:07:14 +02:00
|
|
|
PARALLEL PARAMETER PARSER PARTIAL PARTITION PASSING PASSWORD
|
|
|
|
|
PLACING PLANS POLICY
|
2015-09-16 21:38:47 +02:00
|
|
|
POSITION PRECEDING PRECISION PRESERVE PREPARE PREPARED PRIMARY
|
2017-11-30 14:46:13 +01:00
|
|
|
PRIOR PRIVILEGES PROCEDURAL PROCEDURE PROCEDURES PROGRAM PUBLICATION
|
2002-05-19 17:16:55 +02:00
|
|
|
|
2022-09-01 23:07:14 +02:00
|
|
|
QUOTE
|
2004-04-19 19:22:31 +02:00
|
|
|
|
Rename parser token REF to REF_P to avoid a symbol conflict.
In the latest version of Apple's macOS SDK, <sys/socket.h>
fails to compile if "REF" is #define'd as something.
Apple may or may not agree that this is a bug, and even if
they do accept the bug report I filed, they probably won't
fix it very quickly. In the meantime, our back branches will all
fail to compile gram.y. v15 and HEAD currently escape the problem
thanks to the refactoring done in 98e93a1fc, but that's purely
accidental. Moreover, since that patch removed a widely-visible
inclusion of <netdb.h>, back-patching it seems too likely to break
third-party code.
Instead, change the token's code name to REF_P, following our usual
convention for naming parser tokens that are likely to have symbol
conflicts. The effects of that should be localized to the grammar
and immediately surrounding files, so it seems like a safer answer.
Per project policy that we want to keep recently-out-of-support
branches buildable on modern systems, back-patch all the way to 9.2.
Discussion: https://postgr.es/m/1803927.1665938411@sss.pgh.pa.us
2022-10-16 21:27:04 +02:00
|
|
|
RANGE READ REAL REASSIGN RECHECK RECURSIVE REF_P REFERENCES REFERENCING
|
2016-11-04 16:49:50 +01:00
|
|
|
REFRESH REINDEX RELATIVE_P RELEASE RENAME REPEATABLE REPLACE REPLICA
|
2021-04-07 21:30:08 +02:00
|
|
|
RESET RESTART RESTRICT RETURN RETURNING RETURNS REVOKE RIGHT ROLE ROLLBACK ROLLUP
|
2017-11-30 14:46:13 +01:00
|
|
|
ROUTINE ROUTINES ROW ROWS RULE
|
2002-05-19 17:16:55 +02:00
|
|
|
|
SQL/JSON: support the IS JSON predicate
This patch introduces the SQL standard IS JSON predicate. It operates
on text and bytea values representing JSON, as well as on the json and
jsonb types. Each test has IS and IS NOT variants and supports a WITH
UNIQUE KEYS flag. The tests are:
IS JSON [VALUE]
IS JSON ARRAY
IS JSON OBJECT
IS JSON SCALAR
These should be self-explanatory.
The WITH UNIQUE KEYS flag makes these return false when duplicate keys
exist in any object within the value, not necessarily directly contained
in the outermost object.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Author: Andrew Dunstan <andrew@dunslane.net>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-31 22:34:04 +02:00
|
|
|
SAVEPOINT SCALAR SCHEMA SCHEMAS SCROLL SEARCH SECOND_P SECURITY SELECT
|
|
|
|
|
SEQUENCE SEQUENCES
|
2022-09-01 23:07:14 +02:00
|
|
|
SERIALIZABLE SERVER SESSION SESSION_USER SET SETS SETOF SHARE SHOW
|
|
|
|
|
SIMILAR SIMPLE SKIP SMALLINT SNAPSHOT SOME SQL_P STABLE STANDALONE_P
|
|
|
|
|
START STATEMENT STATISTICS STDIN STDOUT STORAGE STORED STRICT_P STRIP_P
|
Introduce SYSTEM_USER
SYSTEM_USER is a reserved keyword of the SQL specification that,
roughly described, is aimed at reporting some information about the
system user who has connected to the database server. It may include
implementation-specific information about the means by the user
connected, like an authentication method.
This commit implements SYSTEM_USER as of auth_method:identity, where
"auth_method" is a keyword about the authentication method used to log
into the server (like peer, md5, scram-sha-256, gss, etc.) and
"identity" is the authentication identity as introduced by 9afffcb (peer
sets authn to the OS user name, gss to the user principal, etc.). This
format has been suggested by Tom Lane.
Note that thanks to d951052, SYSTEM_USER is available to parallel
workers.
Bump catalog version.
Author: Bertrand Drouvot
Reviewed-by: Jacob Champion, Joe Conway, Álvaro Herrera, Michael Paquier
Discussion: https://postgr.es/m/7e692b8c-0b11-45db-1cad-3afc5b57409f@amazon.com
2022-09-29 08:05:40 +02:00
|
|
|
SUBSCRIPTION SUBSTRING SUPPORT SYMMETRIC SYSID SYSTEM_P SYSTEM_USER
|
2002-05-19 17:16:55 +02:00
|
|
|
|
2015-05-15 20:37:10 +02:00
|
|
|
TABLE TABLES TABLESAMPLE TABLESPACE TEMP TEMPLATE TEMPORARY TEXT_P THEN
|
2020-04-08 10:37:27 +02:00
|
|
|
TIES TIME TIMESTAMP TO TRAILING TRANSACTION TRANSFORM
|
Support all SQL:2011 options for window frame clauses.
This patch adds the ability to use "RANGE offset PRECEDING/FOLLOWING"
frame boundaries in window functions. We'd punted on that back in the
original patch to add window functions, because it was not clear how to
do it in a reasonably data-type-extensible fashion. That problem is
resolved here by adding the ability for btree operator classes to provide
an "in_range" support function that defines how to add or subtract the
RANGE offset value. Factoring it this way also allows the operator class
to avoid overflow problems near the ends of the datatype's range, if it
wishes to expend effort on that. (In the committed patch, the integer
opclasses handle that issue, but it did not seem worth the trouble to
avoid overflow failures for datetime types.)
The patch includes in_range support for the integer_ops opfamily
(int2/int4/int8) as well as the standard datetime types. Support for
other numeric types has been requested, but that seems like suitable
material for a follow-on patch.
In addition, the patch adds GROUPS mode which counts the offset in
ORDER-BY peer groups rather than rows, and it adds the frame_exclusion
options specified by SQL:2011. As far as I can see, we are now fully
up to spec on window framing options.
Existing behaviors remain unchanged, except that I changed the errcode
for a couple of existing error reports to meet the SQL spec's expectation
that negative "offset" values should be reported as SQLSTATE 22013.
Internally and in relevant parts of the documentation, we now consistently
use the terminology "offset PRECEDING/FOLLOWING" rather than "value
PRECEDING/FOLLOWING", since the term "value" is confusingly vague.
Oliver Ford, reviewed and whacked around some by me
Discussion: https://postgr.es/m/CAGMVOdu9sivPAxbNN0X+q19Sfv9edEPv=HibOJhB14TJv_RCQg@mail.gmail.com
2018-02-07 06:06:50 +01:00
|
|
|
TREAT TRIGGER TRIM TRUE_P
|
2011-12-19 23:05:19 +01:00
|
|
|
TRUNCATE TRUSTED TYPE_P TYPES_P
|
2002-05-19 17:16:55 +02:00
|
|
|
|
2022-09-01 23:07:14 +02:00
|
|
|
UESCAPE UNBOUNDED UNCOMMITTED UNENCRYPTED UNION UNIQUE UNKNOWN
|
Reduce size of backend scanner's tables.
Previously, the core scanner's yy_transition[] array had 37045 elements.
Since that number is larger than INT16_MAX, Flex generated the array to
contain 32-bit integers. By reimplementing some of the bulkier scanner
rules, this patch reduces the array to 20495 elements. The much smaller
total length, combined with the consequent use of 16-bit integers for
the array elements reduces the binary size by over 200kB. This was
accomplished in two ways:
1. Consolidate handling of quote continuations into a new start condition,
rather than duplicating that logic for five different string types.
2. Treat Unicode strings and identifiers followed by a UESCAPE sequence
as three separate tokens, rather than one. The logic to de-escape
Unicode strings is moved to the filter code in parser.c, which already
had the ability to provide special processing for token sequences.
While we could have implemented the conversion in the grammar, that
approach was rejected for performance and maintainability reasons.
Performance in microbenchmarks of raw parsing seems equal or slightly
faster in most cases, and it's reasonable to expect that in real-world
usage (with more competition for the CPU cache) there will be a larger
win. The exception is UESCAPE sequences; lexing those is about 10%
slower, primarily because the scanner now has to be called three times
rather than one. This seems acceptable since that feature is very
rarely used.
The psql and epcg lexers are likewise modified, primarily because we
want to keep them all in sync. Since those lexers don't use the
space-hogging -CF option, the space savings is much less, but it's
still good for perhaps 10kB apiece.
While at it, merge the ecpg lexer's handling of C-style comments used
in SQL and in C. Those have different rules regarding nested comments,
but since we already have the ability to keep track of the previous
start condition, we can use that to handle both cases within a single
start condition. This matches the core scanner more closely.
John Naylor
Discussion: https://postgr.es/m/CACPNZCvaoa3EgVWm5yZhcSTX6RAtaLgniCPcBVOCwm8h3xpWkw@mail.gmail.com
2020-01-13 21:04:31 +01:00
|
|
|
UNLISTEN UNLOGGED UNTIL UPDATE USER USING
|
2002-05-19 17:16:55 +02:00
|
|
|
|
2011-02-08 13:23:20 +01:00
|
|
|
VACUUM VALID VALIDATE VALIDATOR VALUE_P VALUES VARCHAR VARIADIC VARYING
|
2014-01-19 00:56:40 +01:00
|
|
|
VERBOSE VERSION_P VIEW VIEWS VOLATILE
|
2006-12-21 17:05:16 +01:00
|
|
|
|
2020-04-08 10:37:27 +02:00
|
|
|
WHEN WHERE WHITESPACE_P WINDOW WITH WITHIN WITHOUT WORK WRAPPER WRITE
|
2002-05-19 17:16:55 +02:00
|
|
|
|
2017-03-08 16:39:37 +01:00
|
|
|
XML_P XMLATTRIBUTES XMLCONCAT XMLELEMENT XMLEXISTS XMLFOREST XMLNAMESPACES
|
|
|
|
|
XMLPARSE XMLPI XMLROOT XMLSERIALIZE XMLTABLE
|
2002-06-18 19:56:41 +02:00
|
|
|
|
2006-12-24 01:29:20 +01:00
|
|
|
YEAR_P YES_P
|
2002-06-18 19:56:41 +02:00
|
|
|
|
2002-05-19 17:16:55 +02:00
|
|
|
ZONE
|
2002-05-17 20:32:52 +02:00
|
|
|
|
2009-07-14 22:24:10 +02:00
|
|
|
/*
|
|
|
|
|
* The grammar thinks these are keywords, but they are not in the kwlist.h
|
2006-05-27 19:38:46 +02:00
|
|
|
* list and so can never be entered directly. The filter in parser.c
|
Improve parser's one-extra-token lookahead mechanism.
There are a couple of places in our grammar that fail to be strict LALR(1),
by requiring more than a single token of lookahead to decide what to do.
Up to now we've dealt with that by using a filter between the lexer and
parser that merges adjacent tokens into one in the places where two tokens
of lookahead are necessary. But that creates a number of user-visible
anomalies, for instance that you can't name a CTE "ordinality" because
"WITH ordinality AS ..." triggers folding of WITH and ORDINALITY into one
token. I realized that there's a better way.
In this patch, we still do the lookahead basically as before, but we never
merge the second token into the first; we replace just the first token by
a special lookahead symbol when one of the lookahead pairs is seen.
This requires a couple extra productions in the grammar, but it involves
fewer special tokens, so that the grammar tables come out a bit smaller
than before. The filter logic is no slower than before, perhaps a bit
faster.
I also fixed the filter logic so that when backing up after a lookahead,
the current token's terminator is correctly restored; this eliminates some
weird behavior in error message issuance, as is shown by the one change in
existing regression test outputs.
I believe that this patch entirely eliminates odd behaviors caused by
lookahead for WITH. It doesn't really improve the situation for NULLS
followed by FIRST/LAST unfortunately: those sequences still act like a
reserved word, even though there are cases where they should be seen as two
ordinary identifiers, eg "SELECT nulls first FROM ...". I experimented
with additional grammar hacks but couldn't find any simple solution for
that. Still, this is better than before, and it seems much more likely
that we *could* somehow solve the NULLS case on the basis of this filter
behavior than the previous one.
2015-02-24 23:53:42 +01:00
|
|
|
* creates these tokens when required (based on looking one token ahead).
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
*
|
|
|
|
|
* NOT_LA exists so that productions such as NOT LIKE can be given the same
|
|
|
|
|
* precedence as LIKE; otherwise they'd effectively have the same precedence
|
|
|
|
|
* as NOT, at least with respect to their left-hand subexpression.
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
* FORMAT_LA, NULLS_LA, WITH_LA, and WITHOUT_LA are needed to make the grammar
|
|
|
|
|
* LALR(1).
|
2006-05-27 19:38:46 +02:00
|
|
|
*/
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
%token FORMAT_LA NOT_LA NULLS_LA WITH_LA WITHOUT_LA
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2021-01-04 17:03:22 +01:00
|
|
|
/*
|
|
|
|
|
* The grammar likewise thinks these tokens are keywords, but they are never
|
|
|
|
|
* generated by the scanner. Rather, they can be injected by parser.c as
|
|
|
|
|
* the initial token of the string (using the lookahead-token mechanism
|
|
|
|
|
* implemented there). This provides a way to tell the grammar to parse
|
|
|
|
|
* something other than the usual list of SQL commands.
|
|
|
|
|
*/
|
|
|
|
|
%token MODE_TYPE_NAME
|
2021-01-04 17:52:00 +01:00
|
|
|
%token MODE_PLPGSQL_EXPR
|
|
|
|
|
%token MODE_PLPGSQL_ASSIGN1
|
|
|
|
|
%token MODE_PLPGSQL_ASSIGN2
|
|
|
|
|
%token MODE_PLPGSQL_ASSIGN3
|
2021-01-04 17:03:22 +01:00
|
|
|
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
|
2009-07-14 22:24:10 +02:00
|
|
|
/* Precedence: lowest to highest */
|
2006-01-22 21:03:16 +01:00
|
|
|
%nonassoc SET /* see relation_expr_opt_alias */
|
2000-09-12 23:07:18 +02:00
|
|
|
%left UNION EXCEPT
|
|
|
|
|
%left INTERSECT
|
1997-10-25 07:56:41 +02:00
|
|
|
%left OR
|
|
|
|
|
%left AND
|
|
|
|
|
%right NOT
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
%nonassoc IS ISNULL NOTNULL /* IS sets precedence for IS NULL, etc */
|
|
|
|
|
%nonassoc '<' '>' '=' LESS_EQUALS GREATER_EQUALS NOT_EQUALS
|
|
|
|
|
%nonassoc BETWEEN IN_P LIKE ILIKE SIMILAR NOT_LA
|
|
|
|
|
%nonassoc ESCAPE /* ESCAPE must be just above LIKE/ILIKE/SIMILAR */
|
SQL/JSON: support the IS JSON predicate
This patch introduces the SQL standard IS JSON predicate. It operates
on text and bytea values representing JSON, as well as on the json and
jsonb types. Each test has IS and IS NOT variants and supports a WITH
UNIQUE KEYS flag. The tests are:
IS JSON [VALUE]
IS JSON ARRAY
IS JSON OBJECT
IS JSON SCALAR
These should be self-explanatory.
The WITH UNIQUE KEYS flag makes these return false when duplicate keys
exist in any object within the value, not necessarily directly contained
in the outermost object.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Author: Andrew Dunstan <andrew@dunslane.net>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-31 22:34:04 +02:00
|
|
|
|
|
|
|
|
/* SQL/JSON related keywords */
|
|
|
|
|
%nonassoc UNIQUE JSON
|
|
|
|
|
%nonassoc KEYS OBJECT_P SCALAR VALUE_P
|
2023-04-04 14:04:30 +02:00
|
|
|
%nonassoc WITH WITHOUT
|
SQL/JSON: support the IS JSON predicate
This patch introduces the SQL standard IS JSON predicate. It operates
on text and bytea values representing JSON, as well as on the json and
jsonb types. Each test has IS and IS NOT variants and supports a WITH
UNIQUE KEYS flag. The tests are:
IS JSON [VALUE]
IS JSON ARRAY
IS JSON OBJECT
IS JSON SCALAR
These should be self-explanatory.
The WITH UNIQUE KEYS flag makes these return false when duplicate keys
exist in any object within the value, not necessarily directly contained
in the outermost object.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Author: Andrew Dunstan <andrew@dunslane.net>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-31 22:34:04 +02:00
|
|
|
|
2008-12-28 19:54:01 +01:00
|
|
|
/*
|
2020-09-19 21:11:26 +02:00
|
|
|
* To support target_el without AS, it used to be necessary to assign IDENT an
|
|
|
|
|
* explicit precedence just less than Op. While that's not really necessary
|
|
|
|
|
* since we removed postfix operators, it's still helpful to do so because
|
|
|
|
|
* there are some other unreserved keywords that need precedence assignments.
|
|
|
|
|
* If those keywords have the same precedence as IDENT then they clearly act
|
|
|
|
|
* the same as non-keywords, reducing the risk of unwanted precedence effects.
|
2010-02-12 18:33:21 +01:00
|
|
|
*
|
2020-09-19 21:11:26 +02:00
|
|
|
* We need to do this for PARTITION, RANGE, ROWS, and GROUPS to support
|
|
|
|
|
* opt_existing_window_name (see comment there).
|
Support GROUPING SETS, CUBE and ROLLUP.
This SQL standard functionality allows to aggregate data by different
GROUP BY clauses at once. Each grouping set returns rows with columns
grouped by in other sets set to NULL.
This could previously be achieved by doing each grouping as a separate
query, conjoined by UNION ALLs. Besides being considerably more concise,
grouping sets will in many cases be faster, requiring only one scan over
the underlying data.
The current implementation of grouping sets only supports using sorting
for input. Individual sets that share a sort order are computed in one
pass. If there are sets that don't share a sort order, additional sort &
aggregation steps are performed. These additional passes are sourced by
the previous sort step; thus avoiding repeated scans of the source data.
The code is structured in a way that adding support for purely using
hash aggregation or a mix of hashing and sorting is possible. Sorting
was chosen to be supported first, as it is the most generic method of
implementation.
Instead of, as in an earlier versions of the patch, representing the
chain of sort and aggregation steps as full blown planner and executor
nodes, all but the first sort are performed inside the aggregation node
itself. This avoids the need to do some unusual gymnastics to handle
having to return aggregated and non-aggregated tuples from underlying
nodes, as well as having to shut down underlying nodes early to limit
memory usage. The optimizer still builds Sort/Agg node to describe each
phase, but they're not part of the plan tree, but instead additional
data for the aggregation node. They're a convenient and preexisting way
to describe aggregation and sorting. The first (and possibly only) sort
step is still performed as a separate execution step. That retains
similarity with existing group by plans, makes rescans fairly simple,
avoids very deep plans (leading to slow explains) and easily allows to
avoid the sorting step if the underlying data is sorted by other means.
A somewhat ugly side of this patch is having to deal with a grammar
ambiguity between the new CUBE keyword and the cube extension/functions
named cube (and rollup). To avoid breaking existing deployments of the
cube extension it has not been renamed, neither has cube been made a
reserved keyword. Instead precedence hacking is used to make GROUP BY
cube(..) refer to the CUBE grouping sets feature, and not the function
cube(). To actually group by a function cube(), unlikely as that might
be, the function name has to be quoted.
Needs a catversion bump because stored rules may change.
Author: Andrew Gierth and Atri Sharma, with contributions from Andres Freund
Reviewed-By: Andres Freund, Noah Misch, Tom Lane, Svenne Krap, Tomas
Vondra, Erik Rijkers, Marti Raudsepp, Pavel Stehule
Discussion: CAOeZVidmVRe2jU6aMk_5qkxnB7dfmPROzM7Ur8JPW5j8Y5X-Lw@mail.gmail.com
2015-05-16 03:40:59 +02:00
|
|
|
*
|
2010-02-12 18:33:21 +01:00
|
|
|
* The frame_bound productions UNBOUNDED PRECEDING and UNBOUNDED FOLLOWING
|
|
|
|
|
* are even messier: since UNBOUNDED is an unreserved keyword (per spec!),
|
|
|
|
|
* there is no principled way to distinguish these from the productions
|
|
|
|
|
* a_expr PRECEDING/FOLLOWING. We hack this up by giving UNBOUNDED slightly
|
|
|
|
|
* lower precedence than PRECEDING and FOLLOWING. At present this doesn't
|
|
|
|
|
* appear to cause UNBOUNDED to be treated differently from other unreserved
|
|
|
|
|
* keywords anywhere else in the grammar, but it's definitely risky. We can
|
|
|
|
|
* blame any funny behavior of UNBOUNDED on the SQL standard, though.
|
2020-09-19 21:11:26 +02:00
|
|
|
*
|
|
|
|
|
* To support CUBE and ROLLUP in GROUP BY without reserving them, we give them
|
|
|
|
|
* an explicit priority lower than '(', so that a rule with CUBE '(' will shift
|
|
|
|
|
* rather than reducing a conflicting rule that takes CUBE as a function name.
|
|
|
|
|
* Using the same precedence as IDENT seems right for the reasons given above.
|
2008-12-28 19:54:01 +01:00
|
|
|
*/
|
2020-09-19 21:11:26 +02:00
|
|
|
%nonassoc UNBOUNDED /* ideally would have same precedence as IDENT */
|
|
|
|
|
%nonassoc IDENT PARTITION RANGE ROWS GROUPS PRECEDING FOLLOWING CUBE ROLLUP
|
2002-04-17 01:08:12 +02:00
|
|
|
%left Op OPERATOR /* multi-character ops and user-defined operators */
|
1997-10-25 07:56:41 +02:00
|
|
|
%left '+' '-'
|
1999-07-09 23:59:59 +02:00
|
|
|
%left '*' '/' '%'
|
|
|
|
|
%left '^'
|
1997-10-25 07:56:41 +02:00
|
|
|
/* Unary Operators */
|
2011-05-06 02:38:52 +02:00
|
|
|
%left AT /* sets precedence for AT TIME ZONE */
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
%left COLLATE
|
1997-10-25 07:56:41 +02:00
|
|
|
%right UMINUS
|
|
|
|
|
%left '[' ']'
|
2000-11-05 01:15:54 +01:00
|
|
|
%left '(' ')'
|
1999-12-10 04:01:05 +01:00
|
|
|
%left TYPECAST
|
2002-03-29 20:06:29 +01:00
|
|
|
%left '.'
|
2002-09-06 00:52:48 +02:00
|
|
|
/*
|
|
|
|
|
* These might seem to be low-precedence, but actually they are not part
|
|
|
|
|
* of the arithmetic hierarchy at all in their use as JOIN operators.
|
|
|
|
|
* We make them high-precedence to support their use as function names.
|
|
|
|
|
* They wouldn't be given a precedence at all, were it not that we need
|
|
|
|
|
* left-associativity among the JOIN rules themselves.
|
|
|
|
|
*/
|
2006-03-07 02:00:19 +01:00
|
|
|
%left JOIN CROSS LEFT FULL RIGHT INNER_P NATURAL
|
2009-11-09 19:38:48 +01:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
%%
|
|
|
|
|
|
1999-10-05 20:14:31 +02:00
|
|
|
/*
|
2009-07-13 04:02:20 +02:00
|
|
|
* The target production for the whole parse.
|
2021-01-04 17:03:22 +01:00
|
|
|
*
|
|
|
|
|
* Ordinarily we parse a list of statements, but if we see one of the
|
|
|
|
|
* special MODE_XXX symbols as first token, we parse something else.
|
|
|
|
|
* The options here correspond to enum RawParseMode, which see for details.
|
1999-10-05 20:14:31 +02:00
|
|
|
*/
|
2021-01-04 17:03:22 +01:00
|
|
|
parse_toplevel:
|
|
|
|
|
stmtmulti
|
2009-07-13 04:02:20 +02:00
|
|
|
{
|
|
|
|
|
pg_yyget_extra(yyscanner)->parsetree = $1;
|
Suppress variable-set-but-not-used warnings from clang 15.
clang 15+ will issue a set-but-not-used warning when the only
use of a variable is in autoincrements (e.g., "foo++;").
That's perfectly sensible, but it detects a few more cases that
we'd not noticed before. Silence the warnings with our usual
methods, such as PG_USED_FOR_ASSERTS_ONLY, or in one case by
actually removing a useless variable.
One thing that we can't nicely get rid of is that with %pure-parser,
Bison emits "yynerrs" as a local variable that falls foul of this
warning. To silence those, I inserted "(void) yynerrs;" in the
top-level productions of affected grammars.
Per recently-established project policy, this is a candidate
for back-patching into out-of-support branches: it suppresses
annoying compiler warnings but changes no behavior. Hence,
back-patch to 9.5, which is as far as these patches go without
issues. (A preliminary check shows that the prior branches
need some other set-but-not-used cleanups too, so I'll leave
them for another day.)
Discussion: https://postgr.es/m/514615.1663615243@sss.pgh.pa.us
2022-09-20 18:04:37 +02:00
|
|
|
(void) yynerrs; /* suppress compiler warning */
|
2009-07-13 04:02:20 +02:00
|
|
|
}
|
2021-01-04 17:03:22 +01:00
|
|
|
| MODE_TYPE_NAME Typename
|
|
|
|
|
{
|
|
|
|
|
pg_yyget_extra(yyscanner)->parsetree = list_make1($2);
|
|
|
|
|
}
|
2021-01-04 17:52:00 +01:00
|
|
|
| MODE_PLPGSQL_EXPR PLpgSQL_Expr
|
|
|
|
|
{
|
|
|
|
|
pg_yyget_extra(yyscanner)->parsetree =
|
|
|
|
|
list_make1(makeRawStmt($2, 0));
|
|
|
|
|
}
|
|
|
|
|
| MODE_PLPGSQL_ASSIGN1 PLAssignStmt
|
|
|
|
|
{
|
|
|
|
|
PLAssignStmt *n = (PLAssignStmt *) $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-01-04 17:52:00 +01:00
|
|
|
n->nnames = 1;
|
|
|
|
|
pg_yyget_extra(yyscanner)->parsetree =
|
|
|
|
|
list_make1(makeRawStmt((Node *) n, 0));
|
|
|
|
|
}
|
|
|
|
|
| MODE_PLPGSQL_ASSIGN2 PLAssignStmt
|
|
|
|
|
{
|
|
|
|
|
PLAssignStmt *n = (PLAssignStmt *) $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-01-04 17:52:00 +01:00
|
|
|
n->nnames = 2;
|
|
|
|
|
pg_yyget_extra(yyscanner)->parsetree =
|
|
|
|
|
list_make1(makeRawStmt((Node *) n, 0));
|
|
|
|
|
}
|
|
|
|
|
| MODE_PLPGSQL_ASSIGN3 PLAssignStmt
|
|
|
|
|
{
|
|
|
|
|
PLAssignStmt *n = (PLAssignStmt *) $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-01-04 17:52:00 +01:00
|
|
|
n->nnames = 3;
|
|
|
|
|
pg_yyget_extra(yyscanner)->parsetree =
|
|
|
|
|
list_make1(makeRawStmt((Node *) n, 0));
|
|
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-12-20 21:33:12 +01:00
|
|
|
|
Change representation of statement lists, and add statement location info.
This patch makes several changes that improve the consistency of
representation of lists of statements. It's always been the case
that the output of parse analysis is a list of Query nodes, whatever
the types of the individual statements in the list. This patch brings
similar consistency to the outputs of raw parsing and planning steps:
* The output of raw parsing is now always a list of RawStmt nodes;
the statement-type-dependent nodes are one level down from that.
* The output of pg_plan_queries() is now always a list of PlannedStmt
nodes, even for utility statements. In the case of a utility statement,
"planning" just consists of wrapping a CMD_UTILITY PlannedStmt around
the utility node. This list representation is now used in Portal and
CachedPlan plan lists, replacing the former convention of intermixing
PlannedStmts with bare utility-statement nodes.
Now, every list of statements has a consistent head-node type depending
on how far along it is in processing. This allows changing many places
that formerly used generic "Node *" pointers to use a more specific
pointer type, thus reducing the number of IsA() tests and casts needed,
as well as improving code clarity.
Also, the post-parse-analysis representation of DECLARE CURSOR is changed
so that it looks more like EXPLAIN, PREPARE, etc. That is, the contained
SELECT remains a child of the DeclareCursorStmt rather than getting flipped
around to be the other way. It's now true for both Query and PlannedStmt
that utilityStmt is non-null if and only if commandType is CMD_UTILITY.
That allows simplifying a lot of places that were testing both fields.
(I think some of those were just defensive programming, but in many places,
it was actually necessary to avoid confusing DECLARE CURSOR with SELECT.)
Because PlannedStmt carries a canSetTag field, we're also able to get rid
of some ad-hoc rules about how to reconstruct canSetTag for a bare utility
statement; specifically, the assumption that a utility is canSetTag if and
only if it's the only one in its list. While I see no near-term need for
relaxing that restriction, it's nice to get rid of the ad-hocery.
The API of ProcessUtility() is changed so that what it's passed is the
wrapper PlannedStmt not just the bare utility statement. This will affect
all users of ProcessUtility_hook, but the changes are pretty trivial; see
the affected contrib modules for examples of the minimum change needed.
(Most compilers should give pointer-type-mismatch warnings for uncorrected
code.)
There's also a change in the API of ExplainOneQuery_hook, to pass through
cursorOptions instead of expecting hook functions to know what to pick.
This is needed because of the DECLARE CURSOR changes, but really should
have been done in 9.6; it's unlikely that any extant hook functions
know about using CURSOR_OPT_PARALLEL_OK.
Finally, teach gram.y to save statement boundary locations in RawStmt
nodes, and pass those through to Query and PlannedStmt nodes. This allows
more intelligent handling of cases where a source query string contains
multiple statements. This patch doesn't actually do anything with the
information, but a follow-on patch will. (Passing this information through
cleanly is the true motivation for these changes; while I think this is all
good cleanup, it's unlikely we'd have bothered without this end goal.)
catversion bump because addition of location fields to struct Query
affects stored rules.
This patch is by me, but it owes a good deal to Fabien Coelho who did
a lot of preliminary work on the problem, and also reviewed the patch.
Discussion: https://postgr.es/m/alpine.DEB.2.20.1612200926310.29821@lancre
2017-01-14 22:02:35 +01:00
|
|
|
/*
|
|
|
|
|
* At top level, we wrap each stmt with a RawStmt node carrying start location
|
|
|
|
|
* and length of the stmt's text. Notice that the start loc/len are driven
|
|
|
|
|
* entirely from semicolon locations (@2). It would seem natural to use
|
|
|
|
|
* @1 or @3 to get the true start location of a stmt, but that doesn't work
|
|
|
|
|
* for statements that can start with empty nonterminals (opt_with_clause is
|
|
|
|
|
* the main offender here); as noted in the comments for YYLLOC_DEFAULT,
|
|
|
|
|
* we'd get -1 for the location in such cases.
|
|
|
|
|
* We also take care to discard empty statements entirely.
|
|
|
|
|
*/
|
2021-04-07 21:30:08 +02:00
|
|
|
stmtmulti: stmtmulti ';' toplevel_stmt
|
2009-07-13 04:02:20 +02:00
|
|
|
{
|
Change representation of statement lists, and add statement location info.
This patch makes several changes that improve the consistency of
representation of lists of statements. It's always been the case
that the output of parse analysis is a list of Query nodes, whatever
the types of the individual statements in the list. This patch brings
similar consistency to the outputs of raw parsing and planning steps:
* The output of raw parsing is now always a list of RawStmt nodes;
the statement-type-dependent nodes are one level down from that.
* The output of pg_plan_queries() is now always a list of PlannedStmt
nodes, even for utility statements. In the case of a utility statement,
"planning" just consists of wrapping a CMD_UTILITY PlannedStmt around
the utility node. This list representation is now used in Portal and
CachedPlan plan lists, replacing the former convention of intermixing
PlannedStmts with bare utility-statement nodes.
Now, every list of statements has a consistent head-node type depending
on how far along it is in processing. This allows changing many places
that formerly used generic "Node *" pointers to use a more specific
pointer type, thus reducing the number of IsA() tests and casts needed,
as well as improving code clarity.
Also, the post-parse-analysis representation of DECLARE CURSOR is changed
so that it looks more like EXPLAIN, PREPARE, etc. That is, the contained
SELECT remains a child of the DeclareCursorStmt rather than getting flipped
around to be the other way. It's now true for both Query and PlannedStmt
that utilityStmt is non-null if and only if commandType is CMD_UTILITY.
That allows simplifying a lot of places that were testing both fields.
(I think some of those were just defensive programming, but in many places,
it was actually necessary to avoid confusing DECLARE CURSOR with SELECT.)
Because PlannedStmt carries a canSetTag field, we're also able to get rid
of some ad-hoc rules about how to reconstruct canSetTag for a bare utility
statement; specifically, the assumption that a utility is canSetTag if and
only if it's the only one in its list. While I see no near-term need for
relaxing that restriction, it's nice to get rid of the ad-hocery.
The API of ProcessUtility() is changed so that what it's passed is the
wrapper PlannedStmt not just the bare utility statement. This will affect
all users of ProcessUtility_hook, but the changes are pretty trivial; see
the affected contrib modules for examples of the minimum change needed.
(Most compilers should give pointer-type-mismatch warnings for uncorrected
code.)
There's also a change in the API of ExplainOneQuery_hook, to pass through
cursorOptions instead of expecting hook functions to know what to pick.
This is needed because of the DECLARE CURSOR changes, but really should
have been done in 9.6; it's unlikely that any extant hook functions
know about using CURSOR_OPT_PARALLEL_OK.
Finally, teach gram.y to save statement boundary locations in RawStmt
nodes, and pass those through to Query and PlannedStmt nodes. This allows
more intelligent handling of cases where a source query string contains
multiple statements. This patch doesn't actually do anything with the
information, but a follow-on patch will. (Passing this information through
cleanly is the true motivation for these changes; while I think this is all
good cleanup, it's unlikely we'd have bothered without this end goal.)
catversion bump because addition of location fields to struct Query
affects stored rules.
This patch is by me, but it owes a good deal to Fabien Coelho who did
a lot of preliminary work on the problem, and also reviewed the patch.
Discussion: https://postgr.es/m/alpine.DEB.2.20.1612200926310.29821@lancre
2017-01-14 22:02:35 +01:00
|
|
|
if ($1 != NIL)
|
|
|
|
|
{
|
|
|
|
|
/* update length of previous stmt */
|
Improve castNode notation by introducing list-extraction-specific variants.
This extends the castNode() notation introduced by commit 5bcab1114 to
provide, in one step, extraction of a list cell's pointer and coercion to
a concrete node type. For example, "lfirst_node(Foo, lc)" is the same
as "castNode(Foo, lfirst(lc))". Almost half of the uses of castNode
that have appeared so far include a list extraction call, so this is
pretty widely useful, and it saves a few more keystrokes compared to the
old way.
As with the previous patch, back-patch the addition of these macros to
pg_list.h, so that the notation will be available when back-patching.
Patch by me, after an idea of Andrew Gierth's.
Discussion: https://postgr.es/m/14197.1491841216@sss.pgh.pa.us
2017-04-10 19:51:29 +02:00
|
|
|
updateRawStmtEnd(llast_node(RawStmt, $1), @2);
|
Change representation of statement lists, and add statement location info.
This patch makes several changes that improve the consistency of
representation of lists of statements. It's always been the case
that the output of parse analysis is a list of Query nodes, whatever
the types of the individual statements in the list. This patch brings
similar consistency to the outputs of raw parsing and planning steps:
* The output of raw parsing is now always a list of RawStmt nodes;
the statement-type-dependent nodes are one level down from that.
* The output of pg_plan_queries() is now always a list of PlannedStmt
nodes, even for utility statements. In the case of a utility statement,
"planning" just consists of wrapping a CMD_UTILITY PlannedStmt around
the utility node. This list representation is now used in Portal and
CachedPlan plan lists, replacing the former convention of intermixing
PlannedStmts with bare utility-statement nodes.
Now, every list of statements has a consistent head-node type depending
on how far along it is in processing. This allows changing many places
that formerly used generic "Node *" pointers to use a more specific
pointer type, thus reducing the number of IsA() tests and casts needed,
as well as improving code clarity.
Also, the post-parse-analysis representation of DECLARE CURSOR is changed
so that it looks more like EXPLAIN, PREPARE, etc. That is, the contained
SELECT remains a child of the DeclareCursorStmt rather than getting flipped
around to be the other way. It's now true for both Query and PlannedStmt
that utilityStmt is non-null if and only if commandType is CMD_UTILITY.
That allows simplifying a lot of places that were testing both fields.
(I think some of those were just defensive programming, but in many places,
it was actually necessary to avoid confusing DECLARE CURSOR with SELECT.)
Because PlannedStmt carries a canSetTag field, we're also able to get rid
of some ad-hoc rules about how to reconstruct canSetTag for a bare utility
statement; specifically, the assumption that a utility is canSetTag if and
only if it's the only one in its list. While I see no near-term need for
relaxing that restriction, it's nice to get rid of the ad-hocery.
The API of ProcessUtility() is changed so that what it's passed is the
wrapper PlannedStmt not just the bare utility statement. This will affect
all users of ProcessUtility_hook, but the changes are pretty trivial; see
the affected contrib modules for examples of the minimum change needed.
(Most compilers should give pointer-type-mismatch warnings for uncorrected
code.)
There's also a change in the API of ExplainOneQuery_hook, to pass through
cursorOptions instead of expecting hook functions to know what to pick.
This is needed because of the DECLARE CURSOR changes, but really should
have been done in 9.6; it's unlikely that any extant hook functions
know about using CURSOR_OPT_PARALLEL_OK.
Finally, teach gram.y to save statement boundary locations in RawStmt
nodes, and pass those through to Query and PlannedStmt nodes. This allows
more intelligent handling of cases where a source query string contains
multiple statements. This patch doesn't actually do anything with the
information, but a follow-on patch will. (Passing this information through
cleanly is the true motivation for these changes; while I think this is all
good cleanup, it's unlikely we'd have bothered without this end goal.)
catversion bump because addition of location fields to struct Query
affects stored rules.
This patch is by me, but it owes a good deal to Fabien Coelho who did
a lot of preliminary work on the problem, and also reviewed the patch.
Discussion: https://postgr.es/m/alpine.DEB.2.20.1612200926310.29821@lancre
2017-01-14 22:02:35 +01:00
|
|
|
}
|
2009-07-13 04:02:20 +02:00
|
|
|
if ($3 != NULL)
|
Change representation of statement lists, and add statement location info.
This patch makes several changes that improve the consistency of
representation of lists of statements. It's always been the case
that the output of parse analysis is a list of Query nodes, whatever
the types of the individual statements in the list. This patch brings
similar consistency to the outputs of raw parsing and planning steps:
* The output of raw parsing is now always a list of RawStmt nodes;
the statement-type-dependent nodes are one level down from that.
* The output of pg_plan_queries() is now always a list of PlannedStmt
nodes, even for utility statements. In the case of a utility statement,
"planning" just consists of wrapping a CMD_UTILITY PlannedStmt around
the utility node. This list representation is now used in Portal and
CachedPlan plan lists, replacing the former convention of intermixing
PlannedStmts with bare utility-statement nodes.
Now, every list of statements has a consistent head-node type depending
on how far along it is in processing. This allows changing many places
that formerly used generic "Node *" pointers to use a more specific
pointer type, thus reducing the number of IsA() tests and casts needed,
as well as improving code clarity.
Also, the post-parse-analysis representation of DECLARE CURSOR is changed
so that it looks more like EXPLAIN, PREPARE, etc. That is, the contained
SELECT remains a child of the DeclareCursorStmt rather than getting flipped
around to be the other way. It's now true for both Query and PlannedStmt
that utilityStmt is non-null if and only if commandType is CMD_UTILITY.
That allows simplifying a lot of places that were testing both fields.
(I think some of those were just defensive programming, but in many places,
it was actually necessary to avoid confusing DECLARE CURSOR with SELECT.)
Because PlannedStmt carries a canSetTag field, we're also able to get rid
of some ad-hoc rules about how to reconstruct canSetTag for a bare utility
statement; specifically, the assumption that a utility is canSetTag if and
only if it's the only one in its list. While I see no near-term need for
relaxing that restriction, it's nice to get rid of the ad-hocery.
The API of ProcessUtility() is changed so that what it's passed is the
wrapper PlannedStmt not just the bare utility statement. This will affect
all users of ProcessUtility_hook, but the changes are pretty trivial; see
the affected contrib modules for examples of the minimum change needed.
(Most compilers should give pointer-type-mismatch warnings for uncorrected
code.)
There's also a change in the API of ExplainOneQuery_hook, to pass through
cursorOptions instead of expecting hook functions to know what to pick.
This is needed because of the DECLARE CURSOR changes, but really should
have been done in 9.6; it's unlikely that any extant hook functions
know about using CURSOR_OPT_PARALLEL_OK.
Finally, teach gram.y to save statement boundary locations in RawStmt
nodes, and pass those through to Query and PlannedStmt nodes. This allows
more intelligent handling of cases where a source query string contains
multiple statements. This patch doesn't actually do anything with the
information, but a follow-on patch will. (Passing this information through
cleanly is the true motivation for these changes; while I think this is all
good cleanup, it's unlikely we'd have bothered without this end goal.)
catversion bump because addition of location fields to struct Query
affects stored rules.
This patch is by me, but it owes a good deal to Fabien Coelho who did
a lot of preliminary work on the problem, and also reviewed the patch.
Discussion: https://postgr.es/m/alpine.DEB.2.20.1612200926310.29821@lancre
2017-01-14 22:02:35 +01:00
|
|
|
$$ = lappend($1, makeRawStmt($3, @2 + 1));
|
2009-07-13 04:02:20 +02:00
|
|
|
else
|
|
|
|
|
$$ = $1;
|
1999-10-05 20:14:31 +02:00
|
|
|
}
|
2021-04-07 21:30:08 +02:00
|
|
|
| toplevel_stmt
|
2009-07-13 04:02:20 +02:00
|
|
|
{
|
|
|
|
|
if ($1 != NULL)
|
Change representation of statement lists, and add statement location info.
This patch makes several changes that improve the consistency of
representation of lists of statements. It's always been the case
that the output of parse analysis is a list of Query nodes, whatever
the types of the individual statements in the list. This patch brings
similar consistency to the outputs of raw parsing and planning steps:
* The output of raw parsing is now always a list of RawStmt nodes;
the statement-type-dependent nodes are one level down from that.
* The output of pg_plan_queries() is now always a list of PlannedStmt
nodes, even for utility statements. In the case of a utility statement,
"planning" just consists of wrapping a CMD_UTILITY PlannedStmt around
the utility node. This list representation is now used in Portal and
CachedPlan plan lists, replacing the former convention of intermixing
PlannedStmts with bare utility-statement nodes.
Now, every list of statements has a consistent head-node type depending
on how far along it is in processing. This allows changing many places
that formerly used generic "Node *" pointers to use a more specific
pointer type, thus reducing the number of IsA() tests and casts needed,
as well as improving code clarity.
Also, the post-parse-analysis representation of DECLARE CURSOR is changed
so that it looks more like EXPLAIN, PREPARE, etc. That is, the contained
SELECT remains a child of the DeclareCursorStmt rather than getting flipped
around to be the other way. It's now true for both Query and PlannedStmt
that utilityStmt is non-null if and only if commandType is CMD_UTILITY.
That allows simplifying a lot of places that were testing both fields.
(I think some of those were just defensive programming, but in many places,
it was actually necessary to avoid confusing DECLARE CURSOR with SELECT.)
Because PlannedStmt carries a canSetTag field, we're also able to get rid
of some ad-hoc rules about how to reconstruct canSetTag for a bare utility
statement; specifically, the assumption that a utility is canSetTag if and
only if it's the only one in its list. While I see no near-term need for
relaxing that restriction, it's nice to get rid of the ad-hocery.
The API of ProcessUtility() is changed so that what it's passed is the
wrapper PlannedStmt not just the bare utility statement. This will affect
all users of ProcessUtility_hook, but the changes are pretty trivial; see
the affected contrib modules for examples of the minimum change needed.
(Most compilers should give pointer-type-mismatch warnings for uncorrected
code.)
There's also a change in the API of ExplainOneQuery_hook, to pass through
cursorOptions instead of expecting hook functions to know what to pick.
This is needed because of the DECLARE CURSOR changes, but really should
have been done in 9.6; it's unlikely that any extant hook functions
know about using CURSOR_OPT_PARALLEL_OK.
Finally, teach gram.y to save statement boundary locations in RawStmt
nodes, and pass those through to Query and PlannedStmt nodes. This allows
more intelligent handling of cases where a source query string contains
multiple statements. This patch doesn't actually do anything with the
information, but a follow-on patch will. (Passing this information through
cleanly is the true motivation for these changes; while I think this is all
good cleanup, it's unlikely we'd have bothered without this end goal.)
catversion bump because addition of location fields to struct Query
affects stored rules.
This patch is by me, but it owes a good deal to Fabien Coelho who did
a lot of preliminary work on the problem, and also reviewed the patch.
Discussion: https://postgr.es/m/alpine.DEB.2.20.1612200926310.29821@lancre
2017-01-14 22:02:35 +01:00
|
|
|
$$ = list_make1(makeRawStmt($1, 0));
|
2009-07-13 04:02:20 +02:00
|
|
|
else
|
2002-06-17 22:27:43 +02:00
|
|
|
$$ = NIL;
|
2009-07-13 04:02:20 +02:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2021-04-07 21:30:08 +02:00
|
|
|
/*
|
|
|
|
|
* toplevel_stmt includes BEGIN and END. stmt does not include them, because
|
2023-05-02 05:23:08 +02:00
|
|
|
* those words have different meanings in function bodies.
|
2021-04-07 21:30:08 +02:00
|
|
|
*/
|
|
|
|
|
toplevel_stmt:
|
|
|
|
|
stmt
|
|
|
|
|
| TransactionStmtLegacy
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
stmt:
|
2012-07-18 16:16:16 +02:00
|
|
|
AlterEventTrigStmt
|
2021-05-07 10:17:42 +02:00
|
|
|
| AlterCollationStmt
|
2012-07-18 16:16:16 +02:00
|
|
|
| AlterDatabaseStmt
|
2005-07-31 19:19:22 +02:00
|
|
|
| AlterDatabaseSetStmt
|
2009-10-05 21:24:49 +02:00
|
|
|
| AlterDefaultPrivilegesStmt
|
2002-12-06 06:00:34 +01:00
|
|
|
| AlterDomainStmt
|
2010-10-25 05:04:37 +02:00
|
|
|
| AlterEnumStmt
|
2011-02-12 03:25:20 +01:00
|
|
|
| AlterExtensionStmt
|
2011-02-10 23:36:44 +01:00
|
|
|
| AlterExtensionContentsStmt
|
2008-12-19 17:25:19 +01:00
|
|
|
| AlterFdwStmt
|
|
|
|
|
| AlterForeignServerStmt
|
2005-03-14 01:19:37 +01:00
|
|
|
| AlterFunctionStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| AlterGroupStmt
|
2016-04-05 23:38:54 +02:00
|
|
|
| AlterObjectDependsStmt
|
2005-08-01 06:03:59 +02:00
|
|
|
| AlterObjectSchemaStmt
|
2004-06-25 23:55:59 +02:00
|
|
|
| AlterOwnerStmt
|
2015-07-14 17:17:55 +02:00
|
|
|
| AlterOperatorStmt
|
2020-03-06 18:19:29 +01:00
|
|
|
| AlterTypeStmt
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
| AlterPolicyStmt
|
2003-03-20 08:02:11 +01:00
|
|
|
| AlterSeqStmt
|
2013-12-18 15:42:44 +01:00
|
|
|
| AlterSystemStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| AlterTableStmt
|
2014-04-13 07:02:44 +02:00
|
|
|
| AlterTblSpcStmt
|
2010-09-26 13:41:03 +02:00
|
|
|
| AlterCompositeTypeStmt
|
2017-01-19 18:00:00 +01:00
|
|
|
| AlterPublicationStmt
|
2005-06-28 07:09:14 +02:00
|
|
|
| AlterRoleSetStmt
|
|
|
|
|
| AlterRoleStmt
|
2017-01-19 18:00:00 +01:00
|
|
|
| AlterSubscriptionStmt
|
Allow setting statistics target for extended statistics
When building statistics, we need to decide how many rows to sample and
how accurate the resulting statistics should be. Until now, it was not
possible to explicitly define statistics target for extended statistics
objects, the value was always computed from the per-attribute targets
with a fallback to the system-wide default statistics target.
That's a bit inconvenient, as it ties together the statistics target set
for per-column and extended statistics. In some cases it may be useful
to require larger sample / higher accuracy for extended statics (or the
other way around), but with this approach that's not possible.
So this commit introduces a new command, allowing to specify statistics
target for individual extended statistics objects, overriding the value
derived from per-attribute targets (and the system default).
ALTER STATISTICS stat_name SET STATISTICS target_value;
When determining statistics target for an extended statistics object we
first look at this explicitly set value. When this value is -1, we fall
back to the old formula, looking at the per-attribute targets first and
then the system default. This means the behavior is backwards compatible
with older PostgreSQL releases.
Author: Tomas Vondra
Discussion: https://postgr.es/m/20190618213357.vli3i23vpkset2xd@development
Reviewed-by: Kirk Jamison, Dean Rasheed
2019-09-10 20:09:27 +02:00
|
|
|
| AlterStatsStmt
|
2007-08-21 03:11:32 +02:00
|
|
|
| AlterTSConfigurationStmt
|
|
|
|
|
| AlterTSDictionaryStmt
|
2008-12-19 17:25:19 +01:00
|
|
|
| AlterUserMappingStmt
|
2003-03-10 04:53:52 +01:00
|
|
|
| AnalyzeStmt
|
2017-11-30 14:46:13 +01:00
|
|
|
| CallStmt
|
2003-03-10 04:53:52 +01:00
|
|
|
| CheckPointStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| ClosePortalStmt
|
2003-03-10 04:53:52 +01:00
|
|
|
| ClusterStmt
|
|
|
|
|
| CommentStmt
|
|
|
|
|
| ConstraintsSetStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| CopyStmt
|
2016-03-24 03:01:35 +01:00
|
|
|
| CreateAmStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| CreateAsStmt
|
2018-09-26 13:26:24 +02:00
|
|
|
| CreateAssertionStmt
|
2002-07-19 01:11:32 +02:00
|
|
|
| CreateCastStmt
|
2003-03-10 04:53:52 +01:00
|
|
|
| CreateConversionStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| CreateDomainStmt
|
2011-02-08 22:08:41 +01:00
|
|
|
| CreateExtensionStmt
|
2008-12-19 17:25:19 +01:00
|
|
|
| CreateFdwStmt
|
|
|
|
|
| CreateForeignServerStmt
|
2011-01-02 05:48:11 +01:00
|
|
|
| CreateForeignTableStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| CreateFunctionStmt
|
|
|
|
|
| CreateGroupStmt
|
2013-03-04 01:23:31 +01:00
|
|
|
| CreateMatViewStmt
|
2002-07-30 00:14:11 +02:00
|
|
|
| CreateOpClassStmt
|
2007-01-23 06:07:18 +01:00
|
|
|
| CreateOpFamilyStmt
|
2017-01-19 18:00:00 +01:00
|
|
|
| CreatePublicationStmt
|
2007-01-23 06:07:18 +01:00
|
|
|
| AlterOpFamilyStmt
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
| CreatePolicyStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| CreatePLangStmt
|
2003-03-10 04:53:52 +01:00
|
|
|
| CreateSchemaStmt
|
|
|
|
|
| CreateSeqStmt
|
|
|
|
|
| CreateStmt
|
2017-01-19 18:00:00 +01:00
|
|
|
| CreateSubscriptionStmt
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
| CreateStatsStmt
|
2004-06-18 08:14:31 +02:00
|
|
|
| CreateTableSpaceStmt
|
2015-04-26 16:33:14 +02:00
|
|
|
| CreateTransformStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| CreateTrigStmt
|
2012-07-18 16:16:16 +02:00
|
|
|
| CreateEventTrigStmt
|
2005-06-28 07:09:14 +02:00
|
|
|
| CreateRoleStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| CreateUserStmt
|
2008-12-19 17:25:19 +01:00
|
|
|
| CreateUserMappingStmt
|
2003-03-10 04:53:52 +01:00
|
|
|
| CreatedbStmt
|
2002-08-27 06:55:12 +02:00
|
|
|
| DeallocateStmt
|
2003-03-10 04:53:52 +01:00
|
|
|
| DeclareCursorStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| DefineStmt
|
2003-03-10 04:53:52 +01:00
|
|
|
| DeleteStmt
|
2007-04-26 18:13:15 +02:00
|
|
|
| DiscardStmt
|
2009-09-23 01:43:43 +02:00
|
|
|
| DoStmt
|
2002-07-19 01:11:32 +02:00
|
|
|
| DropCastStmt
|
2002-07-30 00:14:11 +02:00
|
|
|
| DropOpClassStmt
|
2007-01-23 06:07:18 +01:00
|
|
|
| DropOpFamilyStmt
|
2005-11-21 13:49:33 +01:00
|
|
|
| DropOwnedStmt
|
2003-03-10 04:53:52 +01:00
|
|
|
| DropStmt
|
2017-01-19 18:00:00 +01:00
|
|
|
| DropSubscriptionStmt
|
2004-06-18 08:14:31 +02:00
|
|
|
| DropTableSpaceStmt
|
2015-04-26 16:33:14 +02:00
|
|
|
| DropTransformStmt
|
2005-06-28 07:09:14 +02:00
|
|
|
| DropRoleStmt
|
2008-12-19 17:25:19 +01:00
|
|
|
| DropUserMappingStmt
|
2003-03-10 04:53:52 +01:00
|
|
|
| DropdbStmt
|
2002-08-27 06:55:12 +02:00
|
|
|
| ExecuteStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| ExplainStmt
|
|
|
|
|
| FetchStmt
|
|
|
|
|
| GrantStmt
|
2005-06-28 21:51:26 +02:00
|
|
|
| GrantRoleStmt
|
2014-07-10 21:01:31 +02:00
|
|
|
| ImportForeignSchemaStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| IndexStmt
|
2003-03-10 04:53:52 +01:00
|
|
|
| InsertStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| ListenStmt
|
2013-03-04 01:23:31 +01:00
|
|
|
| RefreshMatViewStmt
|
2003-03-10 04:53:52 +01:00
|
|
|
| LoadStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| LockStmt
|
2022-03-28 16:45:58 +02:00
|
|
|
| MergeStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| NotifyStmt
|
2002-08-27 06:55:12 +02:00
|
|
|
| PrepareStmt
|
2005-11-21 13:49:33 +01:00
|
|
|
| ReassignOwnedStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| ReindexStmt
|
|
|
|
|
| RemoveAggrStmt
|
|
|
|
|
| RemoveFuncStmt
|
2003-03-10 04:53:52 +01:00
|
|
|
| RemoveOperStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| RenameStmt
|
|
|
|
|
| RevokeStmt
|
2005-06-28 21:51:26 +02:00
|
|
|
| RevokeRoleStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| RuleStmt
|
2010-09-28 02:55:27 +02:00
|
|
|
| SecLabelStmt
|
2003-03-10 04:53:52 +01:00
|
|
|
| SelectStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| TransactionStmt
|
2003-03-10 04:53:52 +01:00
|
|
|
| TruncateStmt
|
|
|
|
|
| UnlistenStmt
|
|
|
|
|
| UpdateStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| VacuumStmt
|
2003-03-10 04:53:52 +01:00
|
|
|
| VariableResetStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| VariableSetStmt
|
|
|
|
|
| VariableShowStmt
|
2003-03-10 04:53:52 +01:00
|
|
|
| ViewStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| /*EMPTY*/
|
2004-01-07 19:56:30 +01:00
|
|
|
{ $$ = NULL; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1997-04-02 20:24:52 +02:00
|
|
|
|
2022-07-22 12:57:01 +02:00
|
|
|
/*
|
|
|
|
|
* Generic supporting productions for DDL
|
|
|
|
|
*/
|
|
|
|
|
opt_single_name:
|
|
|
|
|
ColId { $$ = $1; }
|
|
|
|
|
| /* EMPTY */ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_qualified_name:
|
|
|
|
|
any_name { $$ = $1; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_concurrently:
|
|
|
|
|
CONCURRENTLY { $$ = true; }
|
|
|
|
|
| /*EMPTY*/ { $$ = false; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_drop_behavior:
|
|
|
|
|
CASCADE { $$ = DROP_CASCADE; }
|
|
|
|
|
| RESTRICT { $$ = DROP_RESTRICT; }
|
|
|
|
|
| /* EMPTY */ { $$ = DROP_RESTRICT; /* default */ }
|
|
|
|
|
;
|
|
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* CALL statement
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
CallStmt: CALL func_application
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
CallStmt *n = makeNode(CallStmt);
|
|
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->funccall = castNode(FuncCall, $2);
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-11-30 14:46:13 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
1997-12-04 01:28:15 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2005-06-28 07:09:14 +02:00
|
|
|
* Create a new Postgres DBMS role
|
1997-12-04 01:28:15 +01:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2005-06-28 07:09:14 +02:00
|
|
|
CreateRoleStmt:
|
|
|
|
|
CREATE ROLE RoleId opt_with OptRoleList
|
2002-04-21 21:21:49 +02:00
|
|
|
{
|
2005-06-28 07:09:14 +02:00
|
|
|
CreateRoleStmt *n = makeNode(CreateRoleStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-07-26 18:38:29 +02:00
|
|
|
n->stmt_type = ROLESTMT_ROLE;
|
2005-06-28 07:09:14 +02:00
|
|
|
n->role = $3;
|
2001-07-11 00:09:29 +02:00
|
|
|
n->options = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-06-17 07:40:32 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
2020-11-12 07:48:36 +01:00
|
|
|
opt_with: WITH
|
|
|
|
|
| WITH_LA
|
|
|
|
|
| /*EMPTY*/
|
1997-12-16 16:50:54 +01:00
|
|
|
;
|
1997-12-04 01:28:15 +01:00
|
|
|
|
2005-06-28 21:51:26 +02:00
|
|
|
/*
|
|
|
|
|
* Options for CREATE ROLE and ALTER ROLE (also used by CREATE/ALTER USER
|
|
|
|
|
* for backwards compatibility). Note: the only option required by SQL99
|
|
|
|
|
* is "WITH ADMIN name".
|
|
|
|
|
*/
|
|
|
|
|
OptRoleList:
|
2009-10-08 00:14:26 +02:00
|
|
|
OptRoleList CreateOptRoleElem { $$ = lappend($1, $2); }
|
2005-06-28 21:51:26 +02:00
|
|
|
| /* EMPTY */ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
2009-10-08 00:14:26 +02:00
|
|
|
AlterOptRoleList:
|
|
|
|
|
AlterOptRoleList AlterOptRoleElem { $$ = lappend($1, $2); }
|
|
|
|
|
| /* EMPTY */ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
AlterOptRoleElem:
|
2005-06-28 21:51:26 +02:00
|
|
|
PASSWORD Sconst
|
|
|
|
|
{
|
|
|
|
|
$$ = makeDefElem("password",
|
2022-05-13 07:17:29 +02:00
|
|
|
(Node *) makeString($2), @1);
|
2005-06-28 21:51:26 +02:00
|
|
|
}
|
2005-12-23 17:46:39 +01:00
|
|
|
| PASSWORD NULL_P
|
|
|
|
|
{
|
2016-09-06 18:00:00 +02:00
|
|
|
$$ = makeDefElem("password", NULL, @1);
|
2005-12-23 17:46:39 +01:00
|
|
|
}
|
2005-06-28 21:51:26 +02:00
|
|
|
| ENCRYPTED PASSWORD Sconst
|
|
|
|
|
{
|
Remove support for password_encryption='off' / 'plain'.
Storing passwords in plaintext hasn't been a good idea for a very long
time, if ever. Now seems like a good time to finally forbid it, since we're
messing with this in PostgreSQL 10 anyway.
Remove the CREATE/ALTER USER UNENCRYPTED PASSSWORD 'foo' syntax, since
storing passwords unencrypted is no longer supported. ENCRYPTED PASSWORD
'foo' is still accepted, but ENCRYPTED is now just a noise-word, it does
the same as just PASSWORD 'foo'.
Likewise, remove the --unencrypted option from createuser, but accept
--encrypted as a no-op for backward compatibility. AFAICS, --encrypted was
a no-op even before this patch, because createuser encrypted the password
before sending it to the server even if --encrypted was not specified. It
added the ENCRYPTED keyword to the SQL command, but since the password was
already in encrypted form, it didn't make any difference. The documentation
was not clear on whether that was intended or not, but it's moot now.
Also, while password_encryption='on' is still accepted as an alias for
'md5', it is now marked as hidden, so that it is not listed as an accepted
value in error hints, for example. That's not directly related to removing
'plain', but it seems better this way.
Reviewed by Michael Paquier
Discussion: https://www.postgresql.org/message-id/16e9b768-fd78-0b12-cfc1-7b6b7f238fde@iki.fi
2017-05-08 10:26:07 +02:00
|
|
|
/*
|
|
|
|
|
* These days, passwords are always stored in encrypted
|
|
|
|
|
* form, so there is no difference between PASSWORD and
|
|
|
|
|
* ENCRYPTED PASSWORD.
|
|
|
|
|
*/
|
|
|
|
|
$$ = makeDefElem("password",
|
2022-05-13 07:17:29 +02:00
|
|
|
(Node *) makeString($3), @1);
|
2005-06-28 21:51:26 +02:00
|
|
|
}
|
|
|
|
|
| UNENCRYPTED PASSWORD Sconst
|
|
|
|
|
{
|
Remove support for password_encryption='off' / 'plain'.
Storing passwords in plaintext hasn't been a good idea for a very long
time, if ever. Now seems like a good time to finally forbid it, since we're
messing with this in PostgreSQL 10 anyway.
Remove the CREATE/ALTER USER UNENCRYPTED PASSSWORD 'foo' syntax, since
storing passwords unencrypted is no longer supported. ENCRYPTED PASSWORD
'foo' is still accepted, but ENCRYPTED is now just a noise-word, it does
the same as just PASSWORD 'foo'.
Likewise, remove the --unencrypted option from createuser, but accept
--encrypted as a no-op for backward compatibility. AFAICS, --encrypted was
a no-op even before this patch, because createuser encrypted the password
before sending it to the server even if --encrypted was not specified. It
added the ENCRYPTED keyword to the SQL command, but since the password was
already in encrypted form, it didn't make any difference. The documentation
was not clear on whether that was intended or not, but it's moot now.
Also, while password_encryption='on' is still accepted as an alias for
'md5', it is now marked as hidden, so that it is not listed as an accepted
value in error hints, for example. That's not directly related to removing
'plain', but it seems better this way.
Reviewed by Michael Paquier
Discussion: https://www.postgresql.org/message-id/16e9b768-fd78-0b12-cfc1-7b6b7f238fde@iki.fi
2017-05-08 10:26:07 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
|
errmsg("UNENCRYPTED PASSWORD is no longer supported"),
|
|
|
|
|
errhint("Remove UNENCRYPTED to store the password in encrypted form instead."),
|
|
|
|
|
parser_errposition(@1)));
|
2005-06-28 21:51:26 +02:00
|
|
|
}
|
2005-07-26 18:38:29 +02:00
|
|
|
| INHERIT
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("inherit", (Node *) makeBoolean(true), @1);
|
2005-07-26 18:38:29 +02:00
|
|
|
}
|
2005-07-31 19:19:22 +02:00
|
|
|
| CONNECTION LIMIT SignedIconst
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("connectionlimit", (Node *) makeInteger($3), @1);
|
2005-07-31 19:19:22 +02:00
|
|
|
}
|
2005-09-24 00:25:25 +02:00
|
|
|
| VALID UNTIL Sconst
|
2005-06-28 21:51:26 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("validUntil", (Node *) makeString($3), @1);
|
2005-06-28 21:51:26 +02:00
|
|
|
}
|
2005-09-24 00:25:25 +02:00
|
|
|
/* Supported but not documented for roles, for use by ALTER GROUP. */
|
2014-01-22 04:49:22 +01:00
|
|
|
| USER role_list
|
2005-06-28 21:51:26 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("rolemembers", (Node *) $2, @1);
|
2005-06-28 21:51:26 +02:00
|
|
|
}
|
2011-03-15 15:22:58 +01:00
|
|
|
| IDENT
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* We handle identifiers that aren't parser keywords with
|
|
|
|
|
* the following special-case codes, to avoid bloating the
|
|
|
|
|
* size of the main parser.
|
|
|
|
|
*/
|
|
|
|
|
if (strcmp($1, "superuser") == 0)
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("superuser", (Node *) makeBoolean(true), @1);
|
2011-03-15 15:22:58 +01:00
|
|
|
else if (strcmp($1, "nosuperuser") == 0)
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("superuser", (Node *) makeBoolean(false), @1);
|
2011-03-15 15:22:58 +01:00
|
|
|
else if (strcmp($1, "createrole") == 0)
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("createrole", (Node *) makeBoolean(true), @1);
|
2011-03-15 15:22:58 +01:00
|
|
|
else if (strcmp($1, "nocreaterole") == 0)
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("createrole", (Node *) makeBoolean(false), @1);
|
2011-03-15 15:22:58 +01:00
|
|
|
else if (strcmp($1, "replication") == 0)
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("isreplication", (Node *) makeBoolean(true), @1);
|
2011-03-15 15:22:58 +01:00
|
|
|
else if (strcmp($1, "noreplication") == 0)
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("isreplication", (Node *) makeBoolean(false), @1);
|
2011-03-15 15:22:58 +01:00
|
|
|
else if (strcmp($1, "createdb") == 0)
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("createdb", (Node *) makeBoolean(true), @1);
|
2011-03-15 15:22:58 +01:00
|
|
|
else if (strcmp($1, "nocreatedb") == 0)
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("createdb", (Node *) makeBoolean(false), @1);
|
2011-03-15 15:22:58 +01:00
|
|
|
else if (strcmp($1, "login") == 0)
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("canlogin", (Node *) makeBoolean(true), @1);
|
2011-03-15 15:22:58 +01:00
|
|
|
else if (strcmp($1, "nologin") == 0)
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("canlogin", (Node *) makeBoolean(false), @1);
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
else if (strcmp($1, "bypassrls") == 0)
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("bypassrls", (Node *) makeBoolean(true), @1);
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
else if (strcmp($1, "nobypassrls") == 0)
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("bypassrls", (Node *) makeBoolean(false), @1);
|
2011-03-15 15:22:58 +01:00
|
|
|
else if (strcmp($1, "noinherit") == 0)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* Note that INHERIT is a keyword, so it's handled by main parser, but
|
|
|
|
|
* NOINHERIT is handled here.
|
|
|
|
|
*/
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("inherit", (Node *) makeBoolean(false), @1);
|
2011-03-15 15:22:58 +01:00
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("unrecognized role option \"%s\"", $1),
|
|
|
|
|
parser_errposition(@1)));
|
|
|
|
|
}
|
2009-10-08 00:14:26 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
CreateOptRoleElem:
|
|
|
|
|
AlterOptRoleElem { $$ = $1; }
|
|
|
|
|
/* The following are not supported by ALTER ROLE/USER/GROUP */
|
2005-09-24 00:25:25 +02:00
|
|
|
| SYSID Iconst
|
2005-06-28 21:51:26 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("sysid", (Node *) makeInteger($2), @1);
|
2005-06-28 21:51:26 +02:00
|
|
|
}
|
2014-01-22 04:49:22 +01:00
|
|
|
| ADMIN role_list
|
2005-06-28 21:51:26 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("adminmembers", (Node *) $2, @1);
|
2005-06-28 21:51:26 +02:00
|
|
|
}
|
2014-01-22 04:49:22 +01:00
|
|
|
| ROLE role_list
|
2005-06-28 21:51:26 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("rolemembers", (Node *) $2, @1);
|
2005-06-28 21:51:26 +02:00
|
|
|
}
|
2014-01-22 04:49:22 +01:00
|
|
|
| IN_P ROLE role_list
|
2005-06-28 21:51:26 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("addroleto", (Node *) $3, @1);
|
2005-09-24 00:25:25 +02:00
|
|
|
}
|
2014-01-22 04:49:22 +01:00
|
|
|
| IN_P GROUP_P role_list
|
2005-09-24 00:25:25 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("addroleto", (Node *) $3, @1);
|
2005-06-28 21:51:26 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
2005-06-28 07:09:14 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* Create a new Postgres DBMS user (role with implied login ability)
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
CreateUserStmt:
|
|
|
|
|
CREATE USER RoleId opt_with OptRoleList
|
|
|
|
|
{
|
|
|
|
|
CreateRoleStmt *n = makeNode(CreateRoleStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-07-26 18:38:29 +02:00
|
|
|
n->stmt_type = ROLESTMT_USER;
|
2005-06-28 07:09:14 +02:00
|
|
|
n->role = $3;
|
2005-07-26 18:38:29 +02:00
|
|
|
n->options = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-06-28 07:09:14 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* Alter a postgresql DBMS role
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
AlterRoleStmt:
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
ALTER ROLE RoleSpec opt_with AlterOptRoleList
|
2005-06-28 07:09:14 +02:00
|
|
|
{
|
|
|
|
|
AlterRoleStmt *n = makeNode(AlterRoleStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-06-28 07:09:14 +02:00
|
|
|
n->role = $3;
|
2005-07-27 00:37:50 +02:00
|
|
|
n->action = +1; /* add, if there are members */
|
2005-06-28 07:09:14 +02:00
|
|
|
n->options = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-06-28 07:09:14 +02:00
|
|
|
}
|
2017-08-01 02:36:32 +02:00
|
|
|
| ALTER USER RoleSpec opt_with AlterOptRoleList
|
|
|
|
|
{
|
|
|
|
|
AlterRoleStmt *n = makeNode(AlterRoleStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-08-01 02:36:32 +02:00
|
|
|
n->role = $3;
|
|
|
|
|
n->action = +1; /* add, if there are members */
|
|
|
|
|
n->options = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-08-01 02:36:32 +02:00
|
|
|
}
|
2005-06-28 07:09:14 +02:00
|
|
|
;
|
|
|
|
|
|
2009-10-08 00:14:26 +02:00
|
|
|
opt_in_database:
|
|
|
|
|
/* EMPTY */ { $$ = NULL; }
|
2020-06-10 22:58:46 +02:00
|
|
|
| IN_P DATABASE name { $$ = $3; }
|
2009-10-08 00:14:26 +02:00
|
|
|
;
|
|
|
|
|
|
2005-06-28 07:09:14 +02:00
|
|
|
AlterRoleSetStmt:
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
ALTER ROLE RoleSpec opt_in_database SetResetClause
|
2005-06-28 07:09:14 +02:00
|
|
|
{
|
|
|
|
|
AlterRoleSetStmt *n = makeNode(AlterRoleSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-06-28 07:09:14 +02:00
|
|
|
n->role = $3;
|
2009-10-08 00:14:26 +02:00
|
|
|
n->database = $4;
|
|
|
|
|
n->setstmt = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-06-28 07:09:14 +02:00
|
|
|
}
|
2013-02-18 05:45:36 +01:00
|
|
|
| ALTER ROLE ALL opt_in_database SetResetClause
|
|
|
|
|
{
|
|
|
|
|
AlterRoleSetStmt *n = makeNode(AlterRoleSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2013-02-18 05:45:36 +01:00
|
|
|
n->role = NULL;
|
|
|
|
|
n->database = $4;
|
|
|
|
|
n->setstmt = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2013-02-18 05:45:36 +01:00
|
|
|
}
|
2017-08-01 02:36:32 +02:00
|
|
|
| ALTER USER RoleSpec opt_in_database SetResetClause
|
|
|
|
|
{
|
|
|
|
|
AlterRoleSetStmt *n = makeNode(AlterRoleSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-06-28 07:09:14 +02:00
|
|
|
n->role = $3;
|
2017-08-01 02:36:32 +02:00
|
|
|
n->database = $4;
|
|
|
|
|
n->setstmt = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-08-01 02:36:32 +02:00
|
|
|
}
|
|
|
|
|
| ALTER USER ALL opt_in_database SetResetClause
|
2002-03-01 23:45:19 +01:00
|
|
|
{
|
2005-06-28 07:09:14 +02:00
|
|
|
AlterRoleSetStmt *n = makeNode(AlterRoleSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-08-01 02:36:32 +02:00
|
|
|
n->role = NULL;
|
|
|
|
|
n->database = $4;
|
|
|
|
|
n->setstmt = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-03-01 23:45:19 +01:00
|
|
|
}
|
2017-08-01 02:36:32 +02:00
|
|
|
;
|
2002-03-01 23:45:19 +01:00
|
|
|
|
|
|
|
|
|
2005-06-28 07:09:14 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* Drop a postgresql DBMS role
|
|
|
|
|
*
|
2016-08-13 00:45:18 +02:00
|
|
|
* XXX Ideally this would have CASCADE/RESTRICT options, but a role
|
|
|
|
|
* might own objects in multiple databases, and there is presently no way to
|
|
|
|
|
* implement cascading to other databases. So we always behave as RESTRICT.
|
2005-06-28 07:09:14 +02:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
DropRoleStmt:
|
2014-01-22 04:49:22 +01:00
|
|
|
DROP ROLE role_list
|
2005-06-28 07:09:14 +02:00
|
|
|
{
|
|
|
|
|
DropRoleStmt *n = makeNode(DropRoleStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = false;
|
2005-06-28 07:09:14 +02:00
|
|
|
n->roles = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-06-28 07:09:14 +02:00
|
|
|
}
|
2014-01-22 04:49:22 +01:00
|
|
|
| DROP ROLE IF_P EXISTS role_list
|
2006-02-04 20:06:47 +01:00
|
|
|
{
|
|
|
|
|
DropRoleStmt *n = makeNode(DropRoleStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = true;
|
2006-02-04 20:06:47 +01:00
|
|
|
n->roles = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2006-02-04 20:06:47 +01:00
|
|
|
}
|
2017-08-01 02:36:32 +02:00
|
|
|
| DROP USER role_list
|
1997-12-16 16:50:54 +01:00
|
|
|
{
|
2005-06-28 07:09:14 +02:00
|
|
|
DropRoleStmt *n = makeNode(DropRoleStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = false;
|
2005-06-28 07:09:14 +02:00
|
|
|
n->roles = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-12-16 16:50:54 +01:00
|
|
|
}
|
2014-01-22 04:49:22 +01:00
|
|
|
| DROP USER IF_P EXISTS role_list
|
2006-02-04 20:06:47 +01:00
|
|
|
{
|
|
|
|
|
DropRoleStmt *n = makeNode(DropRoleStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2006-02-04 20:06:47 +01:00
|
|
|
n->roles = $5;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2006-02-04 20:06:47 +01:00
|
|
|
}
|
2017-08-01 02:36:32 +02:00
|
|
|
| DROP GROUP_P role_list
|
|
|
|
|
{
|
|
|
|
|
DropRoleStmt *n = makeNode(DropRoleStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = false;
|
2017-08-01 02:36:32 +02:00
|
|
|
n->roles = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-08-01 02:36:32 +02:00
|
|
|
}
|
|
|
|
|
| DROP GROUP_P IF_P EXISTS role_list
|
|
|
|
|
{
|
|
|
|
|
DropRoleStmt *n = makeNode(DropRoleStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = true;
|
2017-08-01 02:36:32 +02:00
|
|
|
n->roles = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-08-01 02:36:32 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
;
|
1997-12-16 16:50:54 +01:00
|
|
|
|
1999-12-16 18:24:19 +01:00
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2005-06-28 07:09:14 +02:00
|
|
|
* Create a postgresql group (role without login ability)
|
1999-12-16 18:24:19 +01:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
CreateGroupStmt:
|
2005-06-28 07:09:14 +02:00
|
|
|
CREATE GROUP_P RoleId opt_with OptRoleList
|
2002-04-21 21:21:49 +02:00
|
|
|
{
|
2005-06-28 07:09:14 +02:00
|
|
|
CreateRoleStmt *n = makeNode(CreateRoleStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-07-26 18:38:29 +02:00
|
|
|
n->stmt_type = ROLESTMT_GROUP;
|
2005-06-28 07:09:14 +02:00
|
|
|
n->role = $3;
|
2001-07-12 20:03:00 +02:00
|
|
|
n->options = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-04-21 21:21:49 +02:00
|
|
|
}
|
2001-07-12 20:03:00 +02:00
|
|
|
;
|
|
|
|
|
|
1999-12-16 18:24:19 +01:00
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2000-02-15 04:26:38 +01:00
|
|
|
* Alter a postgresql group
|
1999-12-16 18:24:19 +01:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
AlterGroupStmt:
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
ALTER GROUP_P RoleSpec add_drop USER role_list
|
2000-02-15 04:26:38 +01:00
|
|
|
{
|
2005-06-28 07:09:14 +02:00
|
|
|
AlterRoleStmt *n = makeNode(AlterRoleStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-06-28 07:09:14 +02:00
|
|
|
n->role = $3;
|
2002-06-17 09:00:27 +02:00
|
|
|
n->action = $4;
|
2005-06-28 21:51:26 +02:00
|
|
|
n->options = list_make1(makeDefElem("rolemembers",
|
2022-05-13 07:17:29 +02:00
|
|
|
(Node *) $6, @6));
|
|
|
|
|
$$ = (Node *) n;
|
2000-02-15 04:26:38 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
;
|
1999-12-16 18:24:19 +01:00
|
|
|
|
2007-01-23 06:07:18 +01:00
|
|
|
add_drop: ADD_P { $$ = +1; }
|
2005-06-28 21:51:26 +02:00
|
|
|
| DROP { $$ = -1; }
|
|
|
|
|
;
|
|
|
|
|
|
2001-07-12 20:03:00 +02:00
|
|
|
|
2000-07-14 17:43:57 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* Manipulate a schema
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
CreateSchemaStmt:
|
2022-07-22 12:57:01 +02:00
|
|
|
CREATE SCHEMA opt_single_name AUTHORIZATION RoleSpec OptSchemaEltList
|
2000-07-14 17:43:57 +02:00
|
|
|
{
|
2002-03-21 17:02:16 +01:00
|
|
|
CreateSchemaStmt *n = makeNode(CreateSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-06-18 19:56:41 +02:00
|
|
|
/* One can omit the schema name or the authorization id. */
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
n->schemaname = $3;
|
|
|
|
|
n->authrole = $5;
|
2004-11-05 20:17:13 +01:00
|
|
|
n->schemaElts = $6;
|
2012-10-04 01:47:11 +02:00
|
|
|
n->if_not_exists = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-03-21 17:02:16 +01:00
|
|
|
}
|
2004-11-05 20:17:13 +01:00
|
|
|
| CREATE SCHEMA ColId OptSchemaEltList
|
2002-03-21 17:02:16 +01:00
|
|
|
{
|
|
|
|
|
CreateSchemaStmt *n = makeNode(CreateSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-03-21 17:02:16 +01:00
|
|
|
/* ...but not both */
|
|
|
|
|
n->schemaname = $3;
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
n->authrole = NULL;
|
2004-11-05 20:17:13 +01:00
|
|
|
n->schemaElts = $4;
|
2012-10-04 01:47:11 +02:00
|
|
|
n->if_not_exists = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-10-04 01:47:11 +02:00
|
|
|
}
|
2022-07-22 12:57:01 +02:00
|
|
|
| CREATE SCHEMA IF_P NOT EXISTS opt_single_name AUTHORIZATION RoleSpec OptSchemaEltList
|
2012-10-04 01:47:11 +02:00
|
|
|
{
|
|
|
|
|
CreateSchemaStmt *n = makeNode(CreateSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
/* schema name can be omitted here, too */
|
|
|
|
|
n->schemaname = $6;
|
|
|
|
|
n->authrole = $8;
|
2012-10-04 01:47:11 +02:00
|
|
|
if ($9 != NIL)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
|
errmsg("CREATE SCHEMA IF NOT EXISTS cannot include schema elements"),
|
|
|
|
|
parser_errposition(@9)));
|
|
|
|
|
n->schemaElts = $9;
|
|
|
|
|
n->if_not_exists = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-10-04 01:47:11 +02:00
|
|
|
}
|
|
|
|
|
| CREATE SCHEMA IF_P NOT EXISTS ColId OptSchemaEltList
|
|
|
|
|
{
|
|
|
|
|
CreateSchemaStmt *n = makeNode(CreateSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
/* ...but not here */
|
2012-10-04 01:47:11 +02:00
|
|
|
n->schemaname = $6;
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
n->authrole = NULL;
|
2012-10-04 01:47:11 +02:00
|
|
|
if ($7 != NIL)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
|
errmsg("CREATE SCHEMA IF NOT EXISTS cannot include schema elements"),
|
|
|
|
|
parser_errposition(@7)));
|
|
|
|
|
n->schemaElts = $7;
|
|
|
|
|
n->if_not_exists = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-07-14 17:43:57 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
OptSchemaEltList:
|
2012-10-04 23:14:59 +02:00
|
|
|
OptSchemaEltList schema_stmt
|
|
|
|
|
{
|
|
|
|
|
if (@$ < 0) /* see comments for YYLLOC_DEFAULT */
|
|
|
|
|
@$ = @2;
|
|
|
|
|
$$ = lappend($1, $2);
|
|
|
|
|
}
|
|
|
|
|
| /* EMPTY */
|
|
|
|
|
{ $$ = NIL; }
|
2002-03-21 17:02:16 +01:00
|
|
|
;
|
2000-07-14 17:43:57 +02:00
|
|
|
|
2002-03-21 17:02:16 +01:00
|
|
|
/*
|
|
|
|
|
* schema_stmt are the ones that can show up inside a CREATE SCHEMA
|
|
|
|
|
* statement (in addition to by themselves).
|
|
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
schema_stmt:
|
|
|
|
|
CreateStmt
|
2004-01-11 05:58:17 +01:00
|
|
|
| IndexStmt
|
|
|
|
|
| CreateSeqStmt
|
|
|
|
|
| CreateTrigStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
| GrantStmt
|
|
|
|
|
| ViewStmt
|
2002-03-21 17:02:16 +01:00
|
|
|
;
|
2002-03-19 03:18:25 +01:00
|
|
|
|
2002-04-21 21:21:49 +02:00
|
|
|
|
1997-04-02 20:24:52 +02:00
|
|
|
/*****************************************************************************
|
1997-09-01 08:00:35 +02:00
|
|
|
*
|
1997-04-02 20:24:52 +02:00
|
|
|
* Set PG internal variable
|
1997-09-18 05:46:18 +02:00
|
|
|
* SET name TO 'var_value'
|
2013-04-20 17:04:41 +02:00
|
|
|
* Include SQL syntax (thomas 1997-10-22):
|
2002-06-17 22:27:43 +02:00
|
|
|
* SET TIME ZONE 'var_value'
|
1997-09-01 08:00:35 +02:00
|
|
|
*
|
1997-04-02 20:24:52 +02:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
VariableSetStmt:
|
|
|
|
|
SET set_rest
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2002-05-17 03:19:19 +02:00
|
|
|
VariableSetStmt *n = $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
n->is_local = false;
|
1997-09-08 05:20:18 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| SET LOCAL set_rest
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2002-05-17 03:19:19 +02:00
|
|
|
VariableSetStmt *n = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
n->is_local = true;
|
1997-09-08 05:20:18 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| SET SESSION set_rest
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2002-05-17 03:19:19 +02:00
|
|
|
VariableSetStmt *n = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
n->is_local = false;
|
1997-09-08 05:20:18 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2002-05-17 03:19:19 +02:00
|
|
|
;
|
|
|
|
|
|
2012-02-15 16:45:08 +01:00
|
|
|
set_rest:
|
|
|
|
|
TRANSACTION transaction_mode_list
|
|
|
|
|
{
|
|
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-02-15 16:45:08 +01:00
|
|
|
n->kind = VAR_SET_MULTI;
|
|
|
|
|
n->name = "TRANSACTION";
|
|
|
|
|
n->args = $2;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| SESSION CHARACTERISTICS AS TRANSACTION transaction_mode_list
|
|
|
|
|
{
|
|
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-02-15 16:45:08 +01:00
|
|
|
n->kind = VAR_SET_MULTI;
|
|
|
|
|
n->name = "SESSION CHARACTERISTICS";
|
|
|
|
|
n->args = $5;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| set_rest_more
|
|
|
|
|
;
|
|
|
|
|
|
2013-12-18 15:42:44 +01:00
|
|
|
generic_set:
|
2007-09-03 20:46:30 +02:00
|
|
|
var_name TO var_list
|
1998-12-18 10:10:39 +01:00
|
|
|
{
|
|
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-09-03 20:46:30 +02:00
|
|
|
n->kind = VAR_SET_VALUE;
|
2002-05-17 03:19:19 +02:00
|
|
|
n->name = $1;
|
|
|
|
|
n->args = $3;
|
|
|
|
|
$$ = n;
|
1998-12-18 10:10:39 +01:00
|
|
|
}
|
2007-09-03 20:46:30 +02:00
|
|
|
| var_name '=' var_list
|
2000-11-24 21:16:40 +01:00
|
|
|
{
|
|
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-09-03 20:46:30 +02:00
|
|
|
n->kind = VAR_SET_VALUE;
|
2002-05-17 03:19:19 +02:00
|
|
|
n->name = $1;
|
|
|
|
|
n->args = $3;
|
|
|
|
|
$$ = n;
|
2000-11-24 21:16:40 +01:00
|
|
|
}
|
2022-12-09 11:12:20 +01:00
|
|
|
| var_name TO var_list USER SET
|
|
|
|
|
{
|
|
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
|
|
|
|
|
|
|
|
|
n->kind = VAR_SET_VALUE;
|
|
|
|
|
n->name = $1;
|
|
|
|
|
n->args = $3;
|
|
|
|
|
n->user_set = true;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| var_name '=' var_list USER SET
|
|
|
|
|
{
|
|
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
|
|
|
|
|
|
|
|
|
n->kind = VAR_SET_VALUE;
|
|
|
|
|
n->name = $1;
|
|
|
|
|
n->args = $3;
|
|
|
|
|
n->user_set = true;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2007-09-03 20:46:30 +02:00
|
|
|
| var_name TO DEFAULT
|
|
|
|
|
{
|
|
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-09-03 20:46:30 +02:00
|
|
|
n->kind = VAR_SET_DEFAULT;
|
|
|
|
|
n->name = $1;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| var_name '=' DEFAULT
|
|
|
|
|
{
|
|
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-09-03 20:46:30 +02:00
|
|
|
n->kind = VAR_SET_DEFAULT;
|
|
|
|
|
n->name = $1;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2019-02-24 18:51:50 +01:00
|
|
|
;
|
2013-12-18 15:42:44 +01:00
|
|
|
|
|
|
|
|
set_rest_more: /* Generic SET syntaxes: */
|
2020-11-11 17:37:18 +01:00
|
|
|
generic_set {$$ = $1;}
|
2007-09-03 20:46:30 +02:00
|
|
|
| var_name FROM CURRENT_P
|
|
|
|
|
{
|
|
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-09-03 20:46:30 +02:00
|
|
|
n->kind = VAR_SET_CURRENT;
|
|
|
|
|
n->name = $1;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
/* Special syntaxes mandated by SQL standard: */
|
2002-06-17 22:27:43 +02:00
|
|
|
| TIME ZONE zone_value
|
1998-07-24 05:32:46 +02:00
|
|
|
{
|
|
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-09-03 20:46:30 +02:00
|
|
|
n->kind = VAR_SET_VALUE;
|
2002-05-17 03:19:19 +02:00
|
|
|
n->name = "timezone";
|
2002-03-09 18:37:16 +01:00
|
|
|
if ($3 != NULL)
|
2004-05-31 01:40:41 +02:00
|
|
|
n->args = list_make1($3);
|
2007-09-03 20:46:30 +02:00
|
|
|
else
|
|
|
|
|
n->kind = VAR_SET_DEFAULT;
|
2002-05-17 03:19:19 +02:00
|
|
|
$$ = n;
|
1998-07-24 05:32:46 +02:00
|
|
|
}
|
2008-10-27 10:37:47 +01:00
|
|
|
| CATALOG_P Sconst
|
|
|
|
|
{
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
|
errmsg("current database cannot be changed"),
|
2009-07-13 04:02:20 +02:00
|
|
|
parser_errposition(@2)));
|
2008-10-27 10:37:47 +01:00
|
|
|
$$ = NULL; /*not reached*/
|
|
|
|
|
}
|
|
|
|
|
| SCHEMA Sconst
|
|
|
|
|
{
|
|
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-10-27 10:37:47 +01:00
|
|
|
n->kind = VAR_SET_VALUE;
|
|
|
|
|
n->name = "search_path";
|
|
|
|
|
n->args = list_make1(makeStringConst($2, @2));
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| NAMES opt_encoding
|
2002-05-17 03:19:19 +02:00
|
|
|
{
|
|
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-09-03 20:46:30 +02:00
|
|
|
n->kind = VAR_SET_VALUE;
|
2002-05-17 03:19:19 +02:00
|
|
|
n->name = "client_encoding";
|
|
|
|
|
if ($2 != NULL)
|
2008-08-29 01:09:48 +02:00
|
|
|
n->args = list_make1(makeStringConst($2, @2));
|
2007-09-03 20:46:30 +02:00
|
|
|
else
|
|
|
|
|
n->kind = VAR_SET_DEFAULT;
|
2002-05-17 03:19:19 +02:00
|
|
|
$$ = n;
|
2001-05-08 23:06:43 +02:00
|
|
|
}
|
2013-06-03 02:09:20 +02:00
|
|
|
| ROLE NonReservedWord_or_Sconst
|
2005-07-26 00:12:34 +02:00
|
|
|
{
|
|
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-09-03 20:46:30 +02:00
|
|
|
n->kind = VAR_SET_VALUE;
|
2005-07-26 00:12:34 +02:00
|
|
|
n->name = "role";
|
2008-08-29 01:09:48 +02:00
|
|
|
n->args = list_make1(makeStringConst($2, @2));
|
2005-07-26 00:12:34 +02:00
|
|
|
$$ = n;
|
|
|
|
|
}
|
2013-06-03 02:09:20 +02:00
|
|
|
| SESSION AUTHORIZATION NonReservedWord_or_Sconst
|
2002-05-17 03:19:19 +02:00
|
|
|
{
|
|
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-09-03 20:46:30 +02:00
|
|
|
n->kind = VAR_SET_VALUE;
|
2002-05-17 03:19:19 +02:00
|
|
|
n->name = "session_authorization";
|
2008-08-29 01:09:48 +02:00
|
|
|
n->args = list_make1(makeStringConst($3, @3));
|
2002-05-17 03:19:19 +02:00
|
|
|
$$ = n;
|
|
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| SESSION AUTHORIZATION DEFAULT
|
2002-05-06 21:47:30 +02:00
|
|
|
{
|
|
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-09-03 20:46:30 +02:00
|
|
|
n->kind = VAR_SET_DEFAULT;
|
2002-05-06 21:47:30 +02:00
|
|
|
n->name = "session_authorization";
|
2002-05-17 03:19:19 +02:00
|
|
|
$$ = n;
|
2002-05-06 21:47:30 +02:00
|
|
|
}
|
2007-01-25 12:53:52 +01:00
|
|
|
| XML_P OPTION document_or_content
|
|
|
|
|
{
|
|
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-09-03 20:46:30 +02:00
|
|
|
n->kind = VAR_SET_VALUE;
|
2007-01-25 12:53:52 +01:00
|
|
|
n->name = "xmloption";
|
2008-08-29 01:09:48 +02:00
|
|
|
n->args = list_make1(makeStringConst($3 == XMLOPTION_DOCUMENT ? "DOCUMENT" : "CONTENT", @3));
|
2007-01-25 12:53:52 +01:00
|
|
|
$$ = n;
|
|
|
|
|
}
|
2011-10-23 00:22:45 +02:00
|
|
|
/* Special syntaxes invented by PostgreSQL: */
|
|
|
|
|
| TRANSACTION SNAPSHOT Sconst
|
|
|
|
|
{
|
|
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-10-23 00:22:45 +02:00
|
|
|
n->kind = VAR_SET_MULTI;
|
|
|
|
|
n->name = "TRANSACTION SNAPSHOT";
|
|
|
|
|
n->args = list_make1(makeStringConst($3, @3));
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2002-05-06 21:47:30 +02:00
|
|
|
;
|
|
|
|
|
|
2007-09-03 20:46:30 +02:00
|
|
|
var_name: ColId { $$ = $1; }
|
The patch adresses the TODO list item "Allow external interfaces to
extend the GUC variable set".
Plugin modules like the pl<lang> modules needs a way to declare
configuration parameters. The postmaster has no knowledge of such
modules when it reads the postgresql.conf file. Rather than allowing
totally unknown configuration parameters, the concept of a variable
"class" is introduced. Variables that belongs to a declared classes will
create a placeholder value of string type and will not generate an
error. When a module is loaded, it will declare variables for such a
class and make those variables "consume" any placeholders that has been
defined. Finally, the module will generate warnings for unrecognized
placeholders defined for its class.
More detail:
The design is outlined after the suggestions made by Tom Lane and Joe
Conway in this thread:
http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php
A new string variable 'custom_variable_classes' is introduced. This
variable is a comma separated string of identifiers. Each identifier
denots a 'class' that will allow its members to be added without error.
This variable must be defined in postmaster.conf.
The lexer (guc_file.l) is changed so that it can accept a qualified name
in the form <ID>.<ID> as the name of a variable. I also changed so that
the 'custom_variable_classes', if found, is added first of all variables
in order to remove the order of declaration issue.
The guc_variables table is made more dynamic. It is originally created
with 20% slack and can grow dynamically. A capacity is introduced to
avoid resizing every time a new variable is added. guc_variables and
num_guc_variables becomes static (hidden).
The GucInfoMain now uses the new function get_guc_variables() and
GetNumConfigOptions instead or using the guc_variables directly.
The find_option() function, when passed a missing name, will check if
the name is qualified. If the name is qualified and if the qualifier
denotes a class included in the 'custom_variable_classes', a placeholder
variable will be created. Such a placeholder will not participate in a
list operation but will otherwise function as a normal string variable.
Define<type>GucVariable() functions will be added, one for each variable
type. They are inteded to be used by add-on modules like the pl<lang>
mappings. Example:
extern void DefineCustomBoolVariable(
const char* name,
const char* short_desc,
const char* long_desc,
bool* valueAddr,
GucContext context,
GucBoolAssignHook assign_hook,
GucShowHook show_hook);
(I created typedefs for the assign-hook and show-hook functions). A call
to these functions will define a new GUC-variable. If a placeholder
exists it will be replaced but it's value will be used in place of the
default value. The valueAddr is assumed ot point at a default value when
the define function is called. The only constraint that is imposed on a
Custom variable is that its name is qualified.
Finally, a function:
void EmittWarningsOnPlacholders(const char* className)
was added. This function should be called when a module has completed
its variable definitions. At that time, no placeholders should remain
for the class that the module uses. If they do, elog(INFO, ...) messages
will be issued to inform the user that unrecognized variables are
present.
Thomas Hallgren
2004-05-26 17:07:41 +02:00
|
|
|
| var_name '.' ColId
|
2013-10-13 06:09:18 +02:00
|
|
|
{ $$ = psprintf("%s.%s", $1, $3); }
|
The patch adresses the TODO list item "Allow external interfaces to
extend the GUC variable set".
Plugin modules like the pl<lang> modules needs a way to declare
configuration parameters. The postmaster has no knowledge of such
modules when it reads the postgresql.conf file. Rather than allowing
totally unknown configuration parameters, the concept of a variable
"class" is introduced. Variables that belongs to a declared classes will
create a placeholder value of string type and will not generate an
error. When a module is loaded, it will declare variables for such a
class and make those variables "consume" any placeholders that has been
defined. Finally, the module will generate warnings for unrecognized
placeholders defined for its class.
More detail:
The design is outlined after the suggestions made by Tom Lane and Joe
Conway in this thread:
http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php
A new string variable 'custom_variable_classes' is introduced. This
variable is a comma separated string of identifiers. Each identifier
denots a 'class' that will allow its members to be added without error.
This variable must be defined in postmaster.conf.
The lexer (guc_file.l) is changed so that it can accept a qualified name
in the form <ID>.<ID> as the name of a variable. I also changed so that
the 'custom_variable_classes', if found, is added first of all variables
in order to remove the order of declaration issue.
The guc_variables table is made more dynamic. It is originally created
with 20% slack and can grow dynamically. A capacity is introduced to
avoid resizing every time a new variable is added. guc_variables and
num_guc_variables becomes static (hidden).
The GucInfoMain now uses the new function get_guc_variables() and
GetNumConfigOptions instead or using the guc_variables directly.
The find_option() function, when passed a missing name, will check if
the name is qualified. If the name is qualified and if the qualifier
denotes a class included in the 'custom_variable_classes', a placeholder
variable will be created. Such a placeholder will not participate in a
list operation but will otherwise function as a normal string variable.
Define<type>GucVariable() functions will be added, one for each variable
type. They are inteded to be used by add-on modules like the pl<lang>
mappings. Example:
extern void DefineCustomBoolVariable(
const char* name,
const char* short_desc,
const char* long_desc,
bool* valueAddr,
GucContext context,
GucBoolAssignHook assign_hook,
GucShowHook show_hook);
(I created typedefs for the assign-hook and show-hook functions). A call
to these functions will define a new GUC-variable. If a placeholder
exists it will be replaced but it's value will be used in place of the
default value. The valueAddr is assumed ot point at a default value when
the define function is called. The only constraint that is imposed on a
Custom variable is that its name is qualified.
Finally, a function:
void EmittWarningsOnPlacholders(const char* className)
was added. This function should be called when a module has completed
its variable definitions. At that time, no placeholders should remain
for the class that the module uses. If they do, elog(INFO, ...) messages
will be issued to inform the user that unrecognized variables are
present.
Thomas Hallgren
2004-05-26 17:07:41 +02:00
|
|
|
;
|
|
|
|
|
|
2004-05-31 01:40:41 +02:00
|
|
|
var_list: var_value { $$ = list_make1($1); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| var_list ',' var_value { $$ = lappend($1, $3); }
|
1999-05-12 09:22:52 +02:00
|
|
|
;
|
|
|
|
|
|
2010-10-22 16:37:38 +02:00
|
|
|
var_value: opt_boolean_or_string
|
2008-08-29 01:09:48 +02:00
|
|
|
{ $$ = makeStringConst($1, @1); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| NumericOnly
|
2008-08-29 01:09:48 +02:00
|
|
|
{ $$ = makeAConst($1, @1); }
|
2002-04-21 21:21:49 +02:00
|
|
|
;
|
2000-05-31 02:28:42 +02:00
|
|
|
|
2003-11-06 23:08:15 +01:00
|
|
|
iso_level: READ UNCOMMITTED { $$ = "read uncommitted"; }
|
|
|
|
|
| READ COMMITTED { $$ = "read committed"; }
|
|
|
|
|
| REPEATABLE READ { $$ = "repeatable read"; }
|
2002-06-17 22:27:43 +02:00
|
|
|
| SERIALIZABLE { $$ = "serializable"; }
|
2000-07-14 17:43:57 +02:00
|
|
|
;
|
2000-03-30 08:02:36 +02:00
|
|
|
|
2010-10-22 16:37:38 +02:00
|
|
|
opt_boolean_or_string:
|
2002-06-17 22:27:43 +02:00
|
|
|
TRUE_P { $$ = "true"; }
|
|
|
|
|
| FALSE_P { $$ = "false"; }
|
|
|
|
|
| ON { $$ = "on"; }
|
2010-10-22 16:37:38 +02:00
|
|
|
/*
|
2013-06-03 02:09:20 +02:00
|
|
|
* OFF is also accepted as a boolean value, but is handled by
|
|
|
|
|
* the NonReservedWord rule. The action for booleans and strings
|
2010-10-22 16:37:38 +02:00
|
|
|
* is the same, so we don't need to distinguish them here.
|
|
|
|
|
*/
|
2013-06-03 02:09:20 +02:00
|
|
|
| NonReservedWord_or_Sconst { $$ = $1; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
2001-10-18 19:30:21 +02:00
|
|
|
/* Timezone values can be:
|
|
|
|
|
* - a string such as 'pst8pdt'
|
2002-05-17 03:19:19 +02:00
|
|
|
* - an identifier such as "pst8pdt"
|
2001-10-18 19:30:21 +02:00
|
|
|
* - an integer or floating point number
|
|
|
|
|
* - a time interval per SQL99
|
2002-05-17 03:19:19 +02:00
|
|
|
* ColId gives reduce/reduce errors against ConstInterval and LOCAL,
|
2008-12-28 19:54:01 +01:00
|
|
|
* so use IDENT (meaning we reject anything that is a key word).
|
2001-10-18 19:30:21 +02:00
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
zone_value:
|
|
|
|
|
Sconst
|
2001-12-09 05:39:39 +01:00
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeStringConst($1, @1);
|
2001-12-09 05:39:39 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| IDENT
|
|
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeStringConst($1, @1);
|
2001-12-09 05:39:39 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| ConstInterval Sconst opt_interval
|
2001-12-09 05:39:39 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
TypeName *t = $1;
|
|
|
|
|
|
2008-09-11 17:27:30 +02:00
|
|
|
if ($3 != NIL)
|
2002-06-17 22:27:43 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
A_Const *n = (A_Const *) linitial($3);
|
|
|
|
|
|
2022-01-14 10:46:49 +01:00
|
|
|
if ((n->val.ival.ival & ~(INTERVAL_MASK(HOUR) | INTERVAL_MASK(MINUTE))) != 0)
|
2003-07-19 22:20:53 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
2008-09-01 22:42:46 +02:00
|
|
|
errmsg("time zone interval must be HOUR or HOUR TO MINUTE"),
|
2009-07-13 04:02:20 +02:00
|
|
|
parser_errposition(@3)));
|
2002-06-17 22:27:43 +02:00
|
|
|
}
|
2008-09-11 17:27:30 +02:00
|
|
|
t->typmods = $3;
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeStringConstCast($2, @2, t);
|
2001-12-09 05:39:39 +01:00
|
|
|
}
|
2014-10-18 16:31:00 +02:00
|
|
|
| ConstInterval '(' Iconst ')' Sconst
|
2002-06-17 22:27:43 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
TypeName *t = $1;
|
|
|
|
|
|
2014-10-18 16:31:00 +02:00
|
|
|
t->typmods = list_make2(makeIntConst(INTERVAL_FULL_RANGE, -1),
|
|
|
|
|
makeIntConst($3, @3));
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeStringConstCast($5, @5, t);
|
2002-06-17 22:27:43 +02:00
|
|
|
}
|
2008-08-29 01:09:48 +02:00
|
|
|
| NumericOnly { $$ = makeAConst($1, @1); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| DEFAULT { $$ = NULL; }
|
|
|
|
|
| LOCAL { $$ = NULL; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1997-09-01 08:00:35 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
opt_encoding:
|
|
|
|
|
Sconst { $$ = $1; }
|
|
|
|
|
| DEFAULT { $$ = NULL; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
|
|
|
|
;
|
2000-01-13 19:26:18 +01:00
|
|
|
|
2013-06-03 02:09:20 +02:00
|
|
|
NonReservedWord_or_Sconst:
|
|
|
|
|
NonReservedWord { $$ = $1; }
|
2008-11-12 16:50:20 +01:00
|
|
|
| Sconst { $$ = $1; }
|
2002-03-21 17:02:16 +01:00
|
|
|
;
|
2001-05-08 23:06:43 +02:00
|
|
|
|
2007-09-03 20:46:30 +02:00
|
|
|
VariableResetStmt:
|
2014-09-02 09:06:58 +02:00
|
|
|
RESET reset_rest { $$ = (Node *) $2; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
reset_rest:
|
|
|
|
|
generic_reset { $$ = $1; }
|
|
|
|
|
| TIME ZONE
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2007-09-03 20:46:30 +02:00
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-09-03 20:46:30 +02:00
|
|
|
n->kind = VAR_RESET;
|
2014-09-02 09:06:58 +02:00
|
|
|
n->name = "timezone";
|
|
|
|
|
$$ = n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2014-09-02 09:06:58 +02:00
|
|
|
| TRANSACTION ISOLATION LEVEL
|
1997-10-30 17:39:27 +01:00
|
|
|
{
|
2007-09-03 20:46:30 +02:00
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-09-03 20:46:30 +02:00
|
|
|
n->kind = VAR_RESET;
|
2014-09-02 09:06:58 +02:00
|
|
|
n->name = "transaction_isolation";
|
|
|
|
|
$$ = n;
|
1997-10-30 17:39:27 +01:00
|
|
|
}
|
2014-09-02 09:06:58 +02:00
|
|
|
| SESSION AUTHORIZATION
|
2001-06-07 06:50:57 +02:00
|
|
|
{
|
2007-09-03 20:46:30 +02:00
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-09-03 20:46:30 +02:00
|
|
|
n->kind = VAR_RESET;
|
2014-09-02 09:06:58 +02:00
|
|
|
n->name = "session_authorization";
|
|
|
|
|
$$ = n;
|
2001-06-07 06:50:57 +02:00
|
|
|
}
|
2014-09-02 09:06:58 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
generic_reset:
|
|
|
|
|
var_name
|
2002-05-17 03:19:19 +02:00
|
|
|
{
|
2007-09-03 20:46:30 +02:00
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-09-03 20:46:30 +02:00
|
|
|
n->kind = VAR_RESET;
|
2014-09-02 09:06:58 +02:00
|
|
|
n->name = $1;
|
|
|
|
|
$$ = n;
|
2002-05-17 03:19:19 +02:00
|
|
|
}
|
2014-09-02 09:06:58 +02:00
|
|
|
| ALL
|
1998-12-18 10:10:39 +01:00
|
|
|
{
|
2007-09-03 20:46:30 +02:00
|
|
|
VariableSetStmt *n = makeNode(VariableSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-09-03 20:46:30 +02:00
|
|
|
n->kind = VAR_RESET_ALL;
|
2014-09-02 09:06:58 +02:00
|
|
|
$$ = n;
|
1998-12-18 10:10:39 +01:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
2007-09-03 20:46:30 +02:00
|
|
|
/* SetResetClause allows SET or RESET without LOCAL */
|
|
|
|
|
SetResetClause:
|
|
|
|
|
SET set_rest { $$ = $2; }
|
|
|
|
|
| VariableResetStmt { $$ = (VariableSetStmt *) $1; }
|
|
|
|
|
;
|
|
|
|
|
|
2012-02-15 16:45:08 +01:00
|
|
|
/* SetResetClause allows SET or RESET without LOCAL */
|
|
|
|
|
FunctionSetResetClause:
|
|
|
|
|
SET set_rest_more { $$ = $2; }
|
|
|
|
|
| VariableResetStmt { $$ = (VariableSetStmt *) $1; }
|
|
|
|
|
;
|
|
|
|
|
|
2007-09-03 20:46:30 +02:00
|
|
|
|
|
|
|
|
VariableShowStmt:
|
|
|
|
|
SHOW var_name
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2007-09-03 20:46:30 +02:00
|
|
|
VariableShowStmt *n = makeNode(VariableShowStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
n->name = $2;
|
1997-09-08 05:20:18 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2007-09-03 20:46:30 +02:00
|
|
|
| SHOW TIME ZONE
|
1997-10-30 17:39:27 +01:00
|
|
|
{
|
2007-09-03 20:46:30 +02:00
|
|
|
VariableShowStmt *n = makeNode(VariableShowStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
n->name = "timezone";
|
1997-10-30 17:39:27 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2007-09-03 20:46:30 +02:00
|
|
|
| SHOW TRANSACTION ISOLATION LEVEL
|
1998-12-18 10:10:39 +01:00
|
|
|
{
|
2007-09-03 20:46:30 +02:00
|
|
|
VariableShowStmt *n = makeNode(VariableShowStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-01-10 23:03:30 +01:00
|
|
|
n->name = "transaction_isolation";
|
1998-12-18 10:10:39 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2007-09-03 20:46:30 +02:00
|
|
|
| SHOW SESSION AUTHORIZATION
|
2002-05-06 21:47:30 +02:00
|
|
|
{
|
2007-09-03 20:46:30 +02:00
|
|
|
VariableShowStmt *n = makeNode(VariableShowStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-05-06 21:47:30 +02:00
|
|
|
n->name = "session_authorization";
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2007-09-03 20:46:30 +02:00
|
|
|
| SHOW ALL
|
2001-06-07 06:50:57 +02:00
|
|
|
{
|
2007-09-03 20:46:30 +02:00
|
|
|
VariableShowStmt *n = makeNode(VariableShowStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
n->name = "all";
|
2001-06-07 06:50:57 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
To: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
Subject: Re: [PATCHES] SET DateStyle patches
On Tue, 22 Apr 1997, Thomas Lockhart wrote:
> Some more patches! These (try to) finish implementing SET variable TO value
> for "DateStyle" (changed the name from simply "date" to be more descriptive).
> This is based on code from Martin and Bruce (?), which was easy to modify.
> The syntax is
>
> SET DateStyle TO 'iso'
> SET DateStyle TO 'postgres'
> SET DateStyle TO 'sql'
> SET DateStyle TO 'european'
> SET DateStyle TO 'noneuropean'
> SET DateStyle TO 'us' (same as "noneuropean")
> SET DateStyle TO 'default' (current same as "postgres,us")
>
> ("european" is just compared for the first 4 characters, and "noneuropean"
> is compared for the first 7 to allow less typing).
>
> Multiple arguments are allowed, so SET datestyle TO 'sql,euro' is valid.
>
> My mods also try to implement "SHOW variable" and "RESET variable", but
> that part just core dumps at the moment. I would guess that my errors
> are obvious to someone who knows what they are doing with the parser stuff,
> so if someone (Bruce and/or Martin??) could have it do the right thing
> we will have a more complete set of what we need.
>
> Also, I would like to have a floating point precision global variable to
> implement "SET precision TO 10" and perhaps "SET precision TO 10,2" for
> float8 and float4, but I don't know how to do that for integer types rather
> than strings. If someone is fixing the SHOW and RESET code, perhaps they can
> add some hooks for me to do the floats while they are at it.
>
> I've left some remnants of variable structures in the source code which
> I did not use in the interests of getting something working for v6.1.
> We'll have time to clean things up for the next release...
1997-04-23 05:18:27 +02:00
|
|
|
|
1997-10-25 07:56:41 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
ConstraintsSetStmt:
|
|
|
|
|
SET CONSTRAINTS constraints_set_list constraints_set_mode
|
1999-09-29 18:06:40 +02:00
|
|
|
{
|
|
|
|
|
ConstraintsSetStmt *n = makeNode(ConstraintsSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
1999-09-29 18:06:40 +02:00
|
|
|
n->constraints = $3;
|
2011-11-01 20:50:00 +01:00
|
|
|
n->deferred = $4;
|
1999-09-29 18:06:40 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
constraints_set_list:
|
|
|
|
|
ALL { $$ = NIL; }
|
2006-04-27 02:33:46 +02:00
|
|
|
| qualified_name_list { $$ = $1; }
|
1999-09-29 18:06:40 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
constraints_set_mode:
|
2017-08-16 06:22:32 +02:00
|
|
|
DEFERRED { $$ = true; }
|
|
|
|
|
| IMMEDIATE { $$ = false; }
|
1999-09-29 18:06:40 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
2000-11-05 23:50:21 +01:00
|
|
|
/*
|
|
|
|
|
* Checkpoint statement
|
|
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
CheckPointStmt:
|
|
|
|
|
CHECKPOINT
|
2000-11-05 23:50:21 +01:00
|
|
|
{
|
|
|
|
|
CheckPointStmt *n = makeNode(CheckPointStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
|
|
|
|
$$ = (Node *) n;
|
2000-11-05 23:50:21 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
;
|
|
|
|
|
|
2000-11-05 23:50:21 +01:00
|
|
|
|
2007-04-26 18:13:15 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2013-10-03 22:17:18 +02:00
|
|
|
* DISCARD { ALL | TEMP | PLANS | SEQUENCES }
|
2007-04-26 18:13:15 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
DiscardStmt:
|
|
|
|
|
DISCARD ALL
|
|
|
|
|
{
|
|
|
|
|
DiscardStmt *n = makeNode(DiscardStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-04-26 18:13:15 +02:00
|
|
|
n->target = DISCARD_ALL;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| DISCARD TEMP
|
|
|
|
|
{
|
|
|
|
|
DiscardStmt *n = makeNode(DiscardStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-04-26 18:13:15 +02:00
|
|
|
n->target = DISCARD_TEMP;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| DISCARD TEMPORARY
|
|
|
|
|
{
|
|
|
|
|
DiscardStmt *n = makeNode(DiscardStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-04-26 18:13:15 +02:00
|
|
|
n->target = DISCARD_TEMP;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| DISCARD PLANS
|
|
|
|
|
{
|
|
|
|
|
DiscardStmt *n = makeNode(DiscardStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-04-26 18:13:15 +02:00
|
|
|
n->target = DISCARD_PLANS;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2013-10-03 22:17:18 +02:00
|
|
|
| DISCARD SEQUENCES
|
|
|
|
|
{
|
|
|
|
|
DiscardStmt *n = makeNode(DiscardStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2013-10-03 22:17:18 +02:00
|
|
|
n->target = DISCARD_SEQUENCES;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
|
2007-04-26 18:13:15 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2020-06-11 08:21:24 +02:00
|
|
|
* ALTER [ TABLE | INDEX | SEQUENCE | VIEW | MATERIALIZED VIEW | FOREIGN TABLE ] variations
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2020-06-11 08:21:24 +02:00
|
|
|
* Note: we accept all subcommands for each of the variants, and sort
|
2008-06-15 03:25:54 +02:00
|
|
|
* out what's really legal at execution time.
|
1996-07-09 08:22:35 +02:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2000-01-16 21:05:00 +01:00
|
|
|
AlterTableStmt:
|
2004-05-05 06:48:48 +02:00
|
|
|
ALTER TABLE relation_expr alter_table_cmds
|
2000-02-15 04:26:38 +01:00
|
|
|
{
|
|
|
|
|
AlterTableStmt *n = makeNode(AlterTableStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-03-21 17:02:16 +01:00
|
|
|
n->relation = $3;
|
2004-05-05 06:48:48 +02:00
|
|
|
n->cmds = $4;
|
2020-07-11 06:32:28 +02:00
|
|
|
n->objtype = OBJECT_TABLE;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-01-24 00:25:04 +01:00
|
|
|
}
|
|
|
|
|
| ALTER TABLE IF_P EXISTS relation_expr alter_table_cmds
|
|
|
|
|
{
|
|
|
|
|
AlterTableStmt *n = makeNode(AlterTableStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-01-24 00:25:04 +01:00
|
|
|
n->relation = $5;
|
|
|
|
|
n->cmds = $6;
|
2020-07-11 06:32:28 +02:00
|
|
|
n->objtype = OBJECT_TABLE;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-08-20 06:29:33 +02:00
|
|
|
}
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
| ALTER TABLE relation_expr partition_cmd
|
|
|
|
|
{
|
|
|
|
|
AlterTableStmt *n = makeNode(AlterTableStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
n->relation = $3;
|
|
|
|
|
n->cmds = list_make1($4);
|
2020-07-11 06:32:28 +02:00
|
|
|
n->objtype = OBJECT_TABLE;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
}
|
|
|
|
|
| ALTER TABLE IF_P EXISTS relation_expr partition_cmd
|
|
|
|
|
{
|
|
|
|
|
AlterTableStmt *n = makeNode(AlterTableStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
n->relation = $5;
|
|
|
|
|
n->cmds = list_make1($6);
|
2020-07-11 06:32:28 +02:00
|
|
|
n->objtype = OBJECT_TABLE;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
}
|
2014-08-22 01:06:17 +02:00
|
|
|
| ALTER TABLE ALL IN_P TABLESPACE name SET TABLESPACE name opt_nowait
|
|
|
|
|
{
|
|
|
|
|
AlterTableMoveAllStmt *n =
|
|
|
|
|
makeNode(AlterTableMoveAllStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-08-22 01:06:17 +02:00
|
|
|
n->orig_tablespacename = $6;
|
|
|
|
|
n->objtype = OBJECT_TABLE;
|
|
|
|
|
n->roles = NIL;
|
|
|
|
|
n->new_tablespacename = $9;
|
|
|
|
|
n->nowait = $10;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2014-08-22 01:06:17 +02:00
|
|
|
}
|
|
|
|
|
| ALTER TABLE ALL IN_P TABLESPACE name OWNED BY role_list SET TABLESPACE name opt_nowait
|
|
|
|
|
{
|
|
|
|
|
AlterTableMoveAllStmt *n =
|
|
|
|
|
makeNode(AlterTableMoveAllStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-08-22 01:06:17 +02:00
|
|
|
n->orig_tablespacename = $6;
|
|
|
|
|
n->objtype = OBJECT_TABLE;
|
|
|
|
|
n->roles = $9;
|
|
|
|
|
n->new_tablespacename = $12;
|
|
|
|
|
n->nowait = $13;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2014-08-22 01:06:17 +02:00
|
|
|
}
|
2009-01-12 10:38:30 +01:00
|
|
|
| ALTER INDEX qualified_name alter_table_cmds
|
2004-08-20 06:29:33 +02:00
|
|
|
{
|
|
|
|
|
AlterTableStmt *n = makeNode(AlterTableStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-08-20 06:29:33 +02:00
|
|
|
n->relation = $3;
|
|
|
|
|
n->cmds = $4;
|
2020-07-11 06:32:28 +02:00
|
|
|
n->objtype = OBJECT_INDEX;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-01-24 00:25:04 +01:00
|
|
|
}
|
|
|
|
|
| ALTER INDEX IF_P EXISTS qualified_name alter_table_cmds
|
|
|
|
|
{
|
|
|
|
|
AlterTableStmt *n = makeNode(AlterTableStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-01-24 00:25:04 +01:00
|
|
|
n->relation = $5;
|
|
|
|
|
n->cmds = $6;
|
2020-07-11 06:32:28 +02:00
|
|
|
n->objtype = OBJECT_INDEX;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-05-05 06:48:48 +02:00
|
|
|
}
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
| ALTER INDEX qualified_name index_partition_cmd
|
|
|
|
|
{
|
|
|
|
|
AlterTableStmt *n = makeNode(AlterTableStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
n->relation = $3;
|
|
|
|
|
n->cmds = list_make1($4);
|
2020-07-11 06:32:28 +02:00
|
|
|
n->objtype = OBJECT_INDEX;
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
}
|
2014-08-22 01:06:17 +02:00
|
|
|
| ALTER INDEX ALL IN_P TABLESPACE name SET TABLESPACE name opt_nowait
|
|
|
|
|
{
|
|
|
|
|
AlterTableMoveAllStmt *n =
|
|
|
|
|
makeNode(AlterTableMoveAllStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-08-22 01:06:17 +02:00
|
|
|
n->orig_tablespacename = $6;
|
|
|
|
|
n->objtype = OBJECT_INDEX;
|
|
|
|
|
n->roles = NIL;
|
|
|
|
|
n->new_tablespacename = $9;
|
|
|
|
|
n->nowait = $10;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2014-08-22 01:06:17 +02:00
|
|
|
}
|
|
|
|
|
| ALTER INDEX ALL IN_P TABLESPACE name OWNED BY role_list SET TABLESPACE name opt_nowait
|
|
|
|
|
{
|
|
|
|
|
AlterTableMoveAllStmt *n =
|
|
|
|
|
makeNode(AlterTableMoveAllStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-08-22 01:06:17 +02:00
|
|
|
n->orig_tablespacename = $6;
|
|
|
|
|
n->objtype = OBJECT_INDEX;
|
|
|
|
|
n->roles = $9;
|
|
|
|
|
n->new_tablespacename = $12;
|
|
|
|
|
n->nowait = $13;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2014-08-22 01:06:17 +02:00
|
|
|
}
|
2009-01-12 10:38:30 +01:00
|
|
|
| ALTER SEQUENCE qualified_name alter_table_cmds
|
2008-06-15 03:25:54 +02:00
|
|
|
{
|
|
|
|
|
AlterTableStmt *n = makeNode(AlterTableStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-06-15 03:25:54 +02:00
|
|
|
n->relation = $3;
|
|
|
|
|
n->cmds = $4;
|
2020-07-11 06:32:28 +02:00
|
|
|
n->objtype = OBJECT_SEQUENCE;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-01-24 00:25:04 +01:00
|
|
|
}
|
|
|
|
|
| ALTER SEQUENCE IF_P EXISTS qualified_name alter_table_cmds
|
|
|
|
|
{
|
|
|
|
|
AlterTableStmt *n = makeNode(AlterTableStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-01-24 00:25:04 +01:00
|
|
|
n->relation = $5;
|
|
|
|
|
n->cmds = $6;
|
2020-07-11 06:32:28 +02:00
|
|
|
n->objtype = OBJECT_SEQUENCE;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2008-06-15 03:25:54 +02:00
|
|
|
}
|
2009-01-12 10:38:30 +01:00
|
|
|
| ALTER VIEW qualified_name alter_table_cmds
|
2008-06-15 03:25:54 +02:00
|
|
|
{
|
|
|
|
|
AlterTableStmt *n = makeNode(AlterTableStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-06-15 03:25:54 +02:00
|
|
|
n->relation = $3;
|
|
|
|
|
n->cmds = $4;
|
2020-07-11 06:32:28 +02:00
|
|
|
n->objtype = OBJECT_VIEW;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-01-24 00:25:04 +01:00
|
|
|
}
|
|
|
|
|
| ALTER VIEW IF_P EXISTS qualified_name alter_table_cmds
|
|
|
|
|
{
|
|
|
|
|
AlterTableStmt *n = makeNode(AlterTableStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-01-24 00:25:04 +01:00
|
|
|
n->relation = $5;
|
|
|
|
|
n->cmds = $6;
|
2020-07-11 06:32:28 +02:00
|
|
|
n->objtype = OBJECT_VIEW;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2008-06-15 03:25:54 +02:00
|
|
|
}
|
2013-03-04 01:23:31 +01:00
|
|
|
| ALTER MATERIALIZED VIEW qualified_name alter_table_cmds
|
|
|
|
|
{
|
|
|
|
|
AlterTableStmt *n = makeNode(AlterTableStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2013-03-04 01:23:31 +01:00
|
|
|
n->relation = $4;
|
|
|
|
|
n->cmds = $5;
|
2020-07-11 06:32:28 +02:00
|
|
|
n->objtype = OBJECT_MATVIEW;
|
2013-03-04 01:23:31 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2013-03-04 01:23:31 +01:00
|
|
|
}
|
|
|
|
|
| ALTER MATERIALIZED VIEW IF_P EXISTS qualified_name alter_table_cmds
|
|
|
|
|
{
|
|
|
|
|
AlterTableStmt *n = makeNode(AlterTableStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2013-03-04 01:23:31 +01:00
|
|
|
n->relation = $6;
|
|
|
|
|
n->cmds = $7;
|
2020-07-11 06:32:28 +02:00
|
|
|
n->objtype = OBJECT_MATVIEW;
|
2013-03-04 01:23:31 +01:00
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2013-03-04 01:23:31 +01:00
|
|
|
}
|
2014-08-22 01:06:17 +02:00
|
|
|
| ALTER MATERIALIZED VIEW ALL IN_P TABLESPACE name SET TABLESPACE name opt_nowait
|
|
|
|
|
{
|
|
|
|
|
AlterTableMoveAllStmt *n =
|
|
|
|
|
makeNode(AlterTableMoveAllStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-08-22 01:06:17 +02:00
|
|
|
n->orig_tablespacename = $7;
|
|
|
|
|
n->objtype = OBJECT_MATVIEW;
|
|
|
|
|
n->roles = NIL;
|
|
|
|
|
n->new_tablespacename = $10;
|
|
|
|
|
n->nowait = $11;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2014-08-22 01:06:17 +02:00
|
|
|
}
|
|
|
|
|
| ALTER MATERIALIZED VIEW ALL IN_P TABLESPACE name OWNED BY role_list SET TABLESPACE name opt_nowait
|
|
|
|
|
{
|
|
|
|
|
AlterTableMoveAllStmt *n =
|
|
|
|
|
makeNode(AlterTableMoveAllStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-08-22 01:06:17 +02:00
|
|
|
n->orig_tablespacename = $7;
|
|
|
|
|
n->objtype = OBJECT_MATVIEW;
|
|
|
|
|
n->roles = $10;
|
|
|
|
|
n->new_tablespacename = $13;
|
|
|
|
|
n->nowait = $14;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2014-08-22 01:06:17 +02:00
|
|
|
}
|
2020-06-11 08:21:24 +02:00
|
|
|
| ALTER FOREIGN TABLE relation_expr alter_table_cmds
|
|
|
|
|
{
|
|
|
|
|
AlterTableStmt *n = makeNode(AlterTableStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2020-06-11 08:21:24 +02:00
|
|
|
n->relation = $4;
|
|
|
|
|
n->cmds = $5;
|
2020-07-11 06:32:28 +02:00
|
|
|
n->objtype = OBJECT_FOREIGN_TABLE;
|
2020-06-11 08:21:24 +02:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2020-06-11 08:21:24 +02:00
|
|
|
}
|
|
|
|
|
| ALTER FOREIGN TABLE IF_P EXISTS relation_expr alter_table_cmds
|
|
|
|
|
{
|
|
|
|
|
AlterTableStmt *n = makeNode(AlterTableStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2020-06-11 08:21:24 +02:00
|
|
|
n->relation = $6;
|
|
|
|
|
n->cmds = $7;
|
2020-07-11 06:32:28 +02:00
|
|
|
n->objtype = OBJECT_FOREIGN_TABLE;
|
2020-06-11 08:21:24 +02:00
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2020-06-11 08:21:24 +02:00
|
|
|
}
|
2004-05-05 06:48:48 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
alter_table_cmds:
|
2004-05-31 01:40:41 +02:00
|
|
|
alter_table_cmd { $$ = list_make1($1); }
|
2004-05-05 06:48:48 +02:00
|
|
|
| alter_table_cmds ',' alter_table_cmd { $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
partition_cmd:
|
|
|
|
|
/* ALTER TABLE <name> ATTACH PARTITION <table_name> FOR VALUES */
|
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
|
|
|
ATTACH PARTITION qualified_name PartitionBoundSpec
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
|
|
|
|
PartitionCmd *cmd = makeNode(PartitionCmd);
|
|
|
|
|
|
|
|
|
|
n->subtype = AT_AttachPartition;
|
|
|
|
|
cmd->name = $3;
|
Code review focused on new node types added by partitioning support.
Fix failure to check that we got a plain Const from const-simplification of
a coercion request. This is the cause of bug #14666 from Tian Bing: there
is an int4 to money cast, but it's only stable not immutable (because of
dependence on lc_monetary), resulting in a FuncExpr that the code was
miserably unequipped to deal with, or indeed even to notice that it was
failing to deal with. Add test cases around this coercion behavior.
In view of the above, sprinkle the code liberally with castNode() macros,
in hope of catching the next such bug a bit sooner. Also, change some
functions that were randomly declared to take Node* to take more specific
pointer types. And change some struct fields that were declared Node*
but could be given more specific types, allowing removal of assorted
explicit casts.
Place PARTITION_MAX_KEYS check a bit closer to the code it's protecting.
Likewise check only-one-key-for-list-partitioning restriction in a less
random place.
Avoid not-per-project-style usages like !strcmp(...).
Fix assorted failures to avoid scribbling on the input of parse
transformation. I'm not sure how necessary this is, but it's entirely
silly for these functions to be expending cycles to avoid that and not
getting it right.
Add guards against partitioning on system columns.
Put backend/nodes/ support code into an order that matches handling
of these node types elsewhere.
Annotate the fact that somebody added location fields to PartitionBoundSpec
and PartitionRangeDatum but forgot to handle them in
outfuncs.c/readfuncs.c. This is fairly harmless for production purposes
(since readfuncs.c would just substitute -1 anyway) but it's still bogus.
It's not worth forcing a post-beta1 initdb just to fix this, but if we
have another reason to force initdb before 10.0, we should go back and
clean this up.
Contrariwise, somebody added location fields to PartitionElem and
PartitionSpec but forgot to teach exprLocation() about them.
Consolidate duplicative code in transformPartitionBound().
Improve a couple of error messages.
Improve assorted commentary.
Re-pgindent the files touched by this patch; this affects a few comment
blocks that must have been added quite recently.
Report: https://postgr.es/m/20170524024550.29935.14396@wrigleys.postgresql.org
2017-05-29 05:20:28 +02:00
|
|
|
cmd->bound = $4;
|
ALTER TABLE ... DETACH PARTITION ... CONCURRENTLY
Allow a partition be detached from its partitioned table without
blocking concurrent queries, by running in two transactions and only
requiring ShareUpdateExclusive in the partitioned table.
Because it runs in two transactions, it cannot be used in a transaction
block. This is the main reason to use dedicated syntax: so that users
can choose to use the original mode if they need it. But also, it
doesn't work when a default partition exists (because an exclusive lock
would still need to be obtained on it, in order to change its partition
constraint.)
In case the second transaction is cancelled or a crash occurs, there's
ALTER TABLE .. DETACH PARTITION .. FINALIZE, which executes the final
steps.
The main trick to make this work is the addition of column
pg_inherits.inhdetachpending, initially false; can only be set true in
the first part of this command. Once that is committed, concurrent
transactions that use a PartitionDirectory will include or ignore
partitions so marked: in optimizer they are ignored if the row is marked
committed for the snapshot; in executor they are always included. As a
result, and because of the way PartitionDirectory caches partition
descriptors, queries that were planned before the detach will see the
rows in the detached partition and queries that are planned after the
detach, won't.
A CHECK constraint is created that duplicates the partition constraint.
This is probably not strictly necessary, and some users will prefer to
remove it afterwards, but if the partition is re-attached to a
partitioned table, the constraint needn't be rechecked.
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Reviewed-by: Amit Langote <amitlangote09@gmail.com>
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>
Discussion: https://postgr.es/m/20200803234854.GA24158@alvherre.pgsql
2021-03-25 22:00:28 +01:00
|
|
|
cmd->concurrent = false;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
n->def = (Node *) cmd;
|
|
|
|
|
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
ALTER TABLE ... DETACH PARTITION ... CONCURRENTLY
Allow a partition be detached from its partitioned table without
blocking concurrent queries, by running in two transactions and only
requiring ShareUpdateExclusive in the partitioned table.
Because it runs in two transactions, it cannot be used in a transaction
block. This is the main reason to use dedicated syntax: so that users
can choose to use the original mode if they need it. But also, it
doesn't work when a default partition exists (because an exclusive lock
would still need to be obtained on it, in order to change its partition
constraint.)
In case the second transaction is cancelled or a crash occurs, there's
ALTER TABLE .. DETACH PARTITION .. FINALIZE, which executes the final
steps.
The main trick to make this work is the addition of column
pg_inherits.inhdetachpending, initially false; can only be set true in
the first part of this command. Once that is committed, concurrent
transactions that use a PartitionDirectory will include or ignore
partitions so marked: in optimizer they are ignored if the row is marked
committed for the snapshot; in executor they are always included. As a
result, and because of the way PartitionDirectory caches partition
descriptors, queries that were planned before the detach will see the
rows in the detached partition and queries that are planned after the
detach, won't.
A CHECK constraint is created that duplicates the partition constraint.
This is probably not strictly necessary, and some users will prefer to
remove it afterwards, but if the partition is re-attached to a
partitioned table, the constraint needn't be rechecked.
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Reviewed-by: Amit Langote <amitlangote09@gmail.com>
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>
Discussion: https://postgr.es/m/20200803234854.GA24158@alvherre.pgsql
2021-03-25 22:00:28 +01:00
|
|
|
/* ALTER TABLE <name> DETACH PARTITION <partition_name> [CONCURRENTLY] */
|
|
|
|
|
| DETACH PARTITION qualified_name opt_concurrently
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
|
|
|
|
PartitionCmd *cmd = makeNode(PartitionCmd);
|
|
|
|
|
|
|
|
|
|
n->subtype = AT_DetachPartition;
|
|
|
|
|
cmd->name = $3;
|
Code review focused on new node types added by partitioning support.
Fix failure to check that we got a plain Const from const-simplification of
a coercion request. This is the cause of bug #14666 from Tian Bing: there
is an int4 to money cast, but it's only stable not immutable (because of
dependence on lc_monetary), resulting in a FuncExpr that the code was
miserably unequipped to deal with, or indeed even to notice that it was
failing to deal with. Add test cases around this coercion behavior.
In view of the above, sprinkle the code liberally with castNode() macros,
in hope of catching the next such bug a bit sooner. Also, change some
functions that were randomly declared to take Node* to take more specific
pointer types. And change some struct fields that were declared Node*
but could be given more specific types, allowing removal of assorted
explicit casts.
Place PARTITION_MAX_KEYS check a bit closer to the code it's protecting.
Likewise check only-one-key-for-list-partitioning restriction in a less
random place.
Avoid not-per-project-style usages like !strcmp(...).
Fix assorted failures to avoid scribbling on the input of parse
transformation. I'm not sure how necessary this is, but it's entirely
silly for these functions to be expending cycles to avoid that and not
getting it right.
Add guards against partitioning on system columns.
Put backend/nodes/ support code into an order that matches handling
of these node types elsewhere.
Annotate the fact that somebody added location fields to PartitionBoundSpec
and PartitionRangeDatum but forgot to handle them in
outfuncs.c/readfuncs.c. This is fairly harmless for production purposes
(since readfuncs.c would just substitute -1 anyway) but it's still bogus.
It's not worth forcing a post-beta1 initdb just to fix this, but if we
have another reason to force initdb before 10.0, we should go back and
clean this up.
Contrariwise, somebody added location fields to PartitionElem and
PartitionSpec but forgot to teach exprLocation() about them.
Consolidate duplicative code in transformPartitionBound().
Improve a couple of error messages.
Improve assorted commentary.
Re-pgindent the files touched by this patch; this affects a few comment
blocks that must have been added quite recently.
Report: https://postgr.es/m/20170524024550.29935.14396@wrigleys.postgresql.org
2017-05-29 05:20:28 +02:00
|
|
|
cmd->bound = NULL;
|
ALTER TABLE ... DETACH PARTITION ... CONCURRENTLY
Allow a partition be detached from its partitioned table without
blocking concurrent queries, by running in two transactions and only
requiring ShareUpdateExclusive in the partitioned table.
Because it runs in two transactions, it cannot be used in a transaction
block. This is the main reason to use dedicated syntax: so that users
can choose to use the original mode if they need it. But also, it
doesn't work when a default partition exists (because an exclusive lock
would still need to be obtained on it, in order to change its partition
constraint.)
In case the second transaction is cancelled or a crash occurs, there's
ALTER TABLE .. DETACH PARTITION .. FINALIZE, which executes the final
steps.
The main trick to make this work is the addition of column
pg_inherits.inhdetachpending, initially false; can only be set true in
the first part of this command. Once that is committed, concurrent
transactions that use a PartitionDirectory will include or ignore
partitions so marked: in optimizer they are ignored if the row is marked
committed for the snapshot; in executor they are always included. As a
result, and because of the way PartitionDirectory caches partition
descriptors, queries that were planned before the detach will see the
rows in the detached partition and queries that are planned after the
detach, won't.
A CHECK constraint is created that duplicates the partition constraint.
This is probably not strictly necessary, and some users will prefer to
remove it afterwards, but if the partition is re-attached to a
partitioned table, the constraint needn't be rechecked.
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Reviewed-by: Amit Langote <amitlangote09@gmail.com>
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>
Discussion: https://postgr.es/m/20200803234854.GA24158@alvherre.pgsql
2021-03-25 22:00:28 +01:00
|
|
|
cmd->concurrent = $4;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
n->def = (Node *) cmd;
|
|
|
|
|
|
ALTER TABLE ... DETACH PARTITION ... CONCURRENTLY
Allow a partition be detached from its partitioned table without
blocking concurrent queries, by running in two transactions and only
requiring ShareUpdateExclusive in the partitioned table.
Because it runs in two transactions, it cannot be used in a transaction
block. This is the main reason to use dedicated syntax: so that users
can choose to use the original mode if they need it. But also, it
doesn't work when a default partition exists (because an exclusive lock
would still need to be obtained on it, in order to change its partition
constraint.)
In case the second transaction is cancelled or a crash occurs, there's
ALTER TABLE .. DETACH PARTITION .. FINALIZE, which executes the final
steps.
The main trick to make this work is the addition of column
pg_inherits.inhdetachpending, initially false; can only be set true in
the first part of this command. Once that is committed, concurrent
transactions that use a PartitionDirectory will include or ignore
partitions so marked: in optimizer they are ignored if the row is marked
committed for the snapshot; in executor they are always included. As a
result, and because of the way PartitionDirectory caches partition
descriptors, queries that were planned before the detach will see the
rows in the detached partition and queries that are planned after the
detach, won't.
A CHECK constraint is created that duplicates the partition constraint.
This is probably not strictly necessary, and some users will prefer to
remove it afterwards, but if the partition is re-attached to a
partitioned table, the constraint needn't be rechecked.
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Reviewed-by: Amit Langote <amitlangote09@gmail.com>
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>
Discussion: https://postgr.es/m/20200803234854.GA24158@alvherre.pgsql
2021-03-25 22:00:28 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| DETACH PARTITION qualified_name FINALIZE
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
|
|
|
|
PartitionCmd *cmd = makeNode(PartitionCmd);
|
|
|
|
|
|
|
|
|
|
n->subtype = AT_DetachPartitionFinalize;
|
|
|
|
|
cmd->name = $3;
|
|
|
|
|
cmd->bound = NULL;
|
|
|
|
|
cmd->concurrent = false;
|
|
|
|
|
n->def = (Node *) cmd;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
index_partition_cmd:
|
|
|
|
|
/* ALTER INDEX <name> ATTACH PARTITION <index_name> */
|
|
|
|
|
ATTACH PARTITION qualified_name
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
|
|
|
|
PartitionCmd *cmd = makeNode(PartitionCmd);
|
|
|
|
|
|
|
|
|
|
n->subtype = AT_AttachPartition;
|
|
|
|
|
cmd->name = $3;
|
|
|
|
|
cmd->bound = NULL;
|
ALTER TABLE ... DETACH PARTITION ... CONCURRENTLY
Allow a partition be detached from its partitioned table without
blocking concurrent queries, by running in two transactions and only
requiring ShareUpdateExclusive in the partitioned table.
Because it runs in two transactions, it cannot be used in a transaction
block. This is the main reason to use dedicated syntax: so that users
can choose to use the original mode if they need it. But also, it
doesn't work when a default partition exists (because an exclusive lock
would still need to be obtained on it, in order to change its partition
constraint.)
In case the second transaction is cancelled or a crash occurs, there's
ALTER TABLE .. DETACH PARTITION .. FINALIZE, which executes the final
steps.
The main trick to make this work is the addition of column
pg_inherits.inhdetachpending, initially false; can only be set true in
the first part of this command. Once that is committed, concurrent
transactions that use a PartitionDirectory will include or ignore
partitions so marked: in optimizer they are ignored if the row is marked
committed for the snapshot; in executor they are always included. As a
result, and because of the way PartitionDirectory caches partition
descriptors, queries that were planned before the detach will see the
rows in the detached partition and queries that are planned after the
detach, won't.
A CHECK constraint is created that duplicates the partition constraint.
This is probably not strictly necessary, and some users will prefer to
remove it afterwards, but if the partition is re-attached to a
partitioned table, the constraint needn't be rechecked.
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Reviewed-by: Amit Langote <amitlangote09@gmail.com>
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>
Discussion: https://postgr.es/m/20200803234854.GA24158@alvherre.pgsql
2021-03-25 22:00:28 +01:00
|
|
|
cmd->concurrent = false;
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
n->def = (Node *) cmd;
|
|
|
|
|
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2004-05-05 06:48:48 +02:00
|
|
|
alter_table_cmd:
|
2009-12-07 06:22:23 +01:00
|
|
|
/* ALTER TABLE <name> ADD <coldef> */
|
|
|
|
|
ADD_P columnDef
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-12-07 06:22:23 +01:00
|
|
|
n->subtype = AT_AddColumn;
|
|
|
|
|
n->def = $2;
|
2015-07-30 03:30:00 +02:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2015-07-30 03:30:00 +02:00
|
|
|
}
|
|
|
|
|
/* ALTER TABLE <name> ADD IF NOT EXISTS <coldef> */
|
|
|
|
|
| ADD_P IF_P NOT EXISTS columnDef
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2015-07-30 03:30:00 +02:00
|
|
|
n->subtype = AT_AddColumn;
|
|
|
|
|
n->def = $5;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2009-12-07 06:22:23 +01:00
|
|
|
}
|
|
|
|
|
/* ALTER TABLE <name> ADD COLUMN <coldef> */
|
|
|
|
|
| ADD_P COLUMN columnDef
|
2004-05-05 06:48:48 +02:00
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-05-05 06:48:48 +02:00
|
|
|
n->subtype = AT_AddColumn;
|
|
|
|
|
n->def = $3;
|
2015-07-30 03:30:00 +02:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2015-07-30 03:30:00 +02:00
|
|
|
}
|
|
|
|
|
/* ALTER TABLE <name> ADD COLUMN IF NOT EXISTS <coldef> */
|
|
|
|
|
| ADD_P COLUMN IF_P NOT EXISTS columnDef
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2015-07-30 03:30:00 +02:00
|
|
|
n->subtype = AT_AddColumn;
|
|
|
|
|
n->def = $6;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-02-15 04:26:38 +01:00
|
|
|
}
|
2008-06-15 03:25:54 +02:00
|
|
|
/* ALTER TABLE <name> ALTER [COLUMN] <colname> {SET DEFAULT <expr>|DROP DEFAULT} */
|
2004-05-05 06:48:48 +02:00
|
|
|
| ALTER opt_column ColId alter_column_default
|
2000-02-15 04:26:38 +01:00
|
|
|
{
|
2004-05-05 06:48:48 +02:00
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-05-05 06:48:48 +02:00
|
|
|
n->subtype = AT_ColumnDefault;
|
|
|
|
|
n->name = $3;
|
|
|
|
|
n->def = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-02-15 04:26:38 +01:00
|
|
|
}
|
2008-06-15 03:25:54 +02:00
|
|
|
/* ALTER TABLE <name> ALTER [COLUMN] <colname> DROP NOT NULL */
|
2004-05-05 06:48:48 +02:00
|
|
|
| ALTER opt_column ColId DROP NOT NULL_P
|
2002-06-17 22:27:43 +02:00
|
|
|
{
|
2004-05-05 06:48:48 +02:00
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-05-05 06:48:48 +02:00
|
|
|
n->subtype = AT_DropNotNull;
|
|
|
|
|
n->name = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-06-17 22:27:43 +02:00
|
|
|
}
|
2008-06-15 03:25:54 +02:00
|
|
|
/* ALTER TABLE <name> ALTER [COLUMN] <colname> SET NOT NULL */
|
2004-05-05 06:48:48 +02:00
|
|
|
| ALTER opt_column ColId SET NOT NULL_P
|
2002-06-17 22:27:43 +02:00
|
|
|
{
|
2004-05-05 06:48:48 +02:00
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-05-05 06:48:48 +02:00
|
|
|
n->subtype = AT_SetNotNull;
|
|
|
|
|
n->name = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-06-17 22:27:43 +02:00
|
|
|
}
|
2020-01-14 13:09:31 +01:00
|
|
|
/* ALTER TABLE <name> ALTER [COLUMN] <colname> DROP EXPRESSION */
|
|
|
|
|
| ALTER opt_column ColId DROP EXPRESSION
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2020-01-14 13:09:31 +01:00
|
|
|
n->subtype = AT_DropExpression;
|
|
|
|
|
n->name = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2020-01-14 13:09:31 +01:00
|
|
|
}
|
|
|
|
|
/* ALTER TABLE <name> ALTER [COLUMN] <colname> DROP EXPRESSION IF EXISTS */
|
|
|
|
|
| ALTER opt_column ColId DROP EXPRESSION IF_P EXISTS
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2020-01-14 13:09:31 +01:00
|
|
|
n->subtype = AT_DropExpression;
|
|
|
|
|
n->name = $3;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2020-01-14 13:09:31 +01:00
|
|
|
}
|
2008-11-13 12:10:06 +01:00
|
|
|
/* ALTER TABLE <name> ALTER [COLUMN] <colname> SET STATISTICS <SignedIconst> */
|
|
|
|
|
| ALTER opt_column ColId SET STATISTICS SignedIconst
|
2001-05-07 02:43:27 +02:00
|
|
|
{
|
2004-05-05 06:48:48 +02:00
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-05-05 06:48:48 +02:00
|
|
|
n->subtype = AT_SetStatistics;
|
|
|
|
|
n->name = $3;
|
2008-11-13 12:10:06 +01:00
|
|
|
n->def = (Node *) makeInteger($6);
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2001-05-07 02:43:27 +02:00
|
|
|
}
|
2017-09-06 22:46:01 +02:00
|
|
|
/* ALTER TABLE <name> ALTER [COLUMN] <colnum> SET STATISTICS <SignedIconst> */
|
|
|
|
|
| ALTER opt_column Iconst SET STATISTICS SignedIconst
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
|
|
|
|
|
|
|
|
|
if ($3 <= 0 || $3 > PG_INT16_MAX)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
|
|
|
|
errmsg("column number must be in range from 1 to %d", PG_INT16_MAX),
|
|
|
|
|
parser_errposition(@3)));
|
|
|
|
|
|
|
|
|
|
n->subtype = AT_SetStatistics;
|
|
|
|
|
n->num = (int16) $3;
|
|
|
|
|
n->def = (Node *) makeInteger($6);
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-09-06 22:46:01 +02:00
|
|
|
}
|
2010-01-22 17:40:19 +01:00
|
|
|
/* ALTER TABLE <name> ALTER [COLUMN] <colname> SET ( column_parameter = value [, ... ] ) */
|
|
|
|
|
| ALTER opt_column ColId SET reloptions
|
2009-08-03 00:14:53 +02:00
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-01-22 17:40:19 +01:00
|
|
|
n->subtype = AT_SetOptions;
|
2009-08-03 00:14:53 +02:00
|
|
|
n->name = $3;
|
2010-01-22 17:40:19 +01:00
|
|
|
n->def = (Node *) $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2010-01-22 17:40:19 +01:00
|
|
|
}
|
2021-09-06 10:03:40 +02:00
|
|
|
/* ALTER TABLE <name> ALTER [COLUMN] <colname> RESET ( column_parameter [, ... ] ) */
|
2010-01-22 17:40:19 +01:00
|
|
|
| ALTER opt_column ColId RESET reloptions
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-01-22 17:40:19 +01:00
|
|
|
n->subtype = AT_ResetOptions;
|
|
|
|
|
n->name = $3;
|
|
|
|
|
n->def = (Node *) $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2009-08-03 00:14:53 +02:00
|
|
|
}
|
2008-06-15 03:25:54 +02:00
|
|
|
/* ALTER TABLE <name> ALTER [COLUMN] <colname> SET STORAGE <storagemode> */
|
2022-07-13 12:21:45 +02:00
|
|
|
| ALTER opt_column ColId SET column_storage
|
2002-06-17 22:27:43 +02:00
|
|
|
{
|
2004-05-05 06:48:48 +02:00
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-05-05 06:48:48 +02:00
|
|
|
n->subtype = AT_SetStorage;
|
|
|
|
|
n->name = $3;
|
2022-07-13 12:21:45 +02:00
|
|
|
n->def = (Node *) makeString($5);
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-03-05 06:33:31 +01:00
|
|
|
}
|
2021-05-27 19:24:24 +02:00
|
|
|
/* ALTER TABLE <name> ALTER [COLUMN] <colname> SET COMPRESSION <cm> */
|
|
|
|
|
| ALTER opt_column ColId SET column_compression
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-05-27 19:24:24 +02:00
|
|
|
n->subtype = AT_SetCompression;
|
|
|
|
|
n->name = $3;
|
|
|
|
|
n->def = (Node *) makeString($5);
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2021-05-27 19:24:24 +02:00
|
|
|
}
|
2017-04-06 14:33:16 +02:00
|
|
|
/* ALTER TABLE <name> ALTER [COLUMN] <colname> ADD GENERATED ... AS IDENTITY ... */
|
|
|
|
|
| ALTER opt_column ColId ADD_P GENERATED generated_when AS IDENTITY_P OptParenthesizedSeqOptList
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
|
|
|
|
Constraint *c = makeNode(Constraint);
|
|
|
|
|
|
|
|
|
|
c->contype = CONSTR_IDENTITY;
|
|
|
|
|
c->generated_when = $6;
|
|
|
|
|
c->options = $9;
|
|
|
|
|
c->location = @5;
|
|
|
|
|
|
|
|
|
|
n->subtype = AT_AddIdentity;
|
|
|
|
|
n->name = $3;
|
|
|
|
|
n->def = (Node *) c;
|
|
|
|
|
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-04-06 14:33:16 +02:00
|
|
|
}
|
|
|
|
|
/* ALTER TABLE <name> ALTER [COLUMN] <colname> SET <sequence options>/RESET */
|
|
|
|
|
| ALTER opt_column ColId alter_identity_column_option_list
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-04-06 14:33:16 +02:00
|
|
|
n->subtype = AT_SetIdentity;
|
|
|
|
|
n->name = $3;
|
|
|
|
|
n->def = (Node *) $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-04-06 14:33:16 +02:00
|
|
|
}
|
|
|
|
|
/* ALTER TABLE <name> ALTER [COLUMN] <colname> DROP IDENTITY */
|
|
|
|
|
| ALTER opt_column ColId DROP IDENTITY_P
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-04-06 14:33:16 +02:00
|
|
|
n->subtype = AT_DropIdentity;
|
|
|
|
|
n->name = $3;
|
|
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-04-06 14:33:16 +02:00
|
|
|
}
|
|
|
|
|
/* ALTER TABLE <name> ALTER [COLUMN] <colname> DROP IDENTITY IF EXISTS */
|
|
|
|
|
| ALTER opt_column ColId DROP IDENTITY_P IF_P EXISTS
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-04-06 14:33:16 +02:00
|
|
|
n->subtype = AT_DropIdentity;
|
|
|
|
|
n->name = $3;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-04-06 14:33:16 +02:00
|
|
|
}
|
2009-07-20 04:42:28 +02:00
|
|
|
/* ALTER TABLE <name> DROP [COLUMN] IF EXISTS <colname> [RESTRICT|CASCADE] */
|
|
|
|
|
| DROP opt_column IF_P EXISTS ColId opt_drop_behavior
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-07-20 04:42:28 +02:00
|
|
|
n->subtype = AT_DropColumn;
|
|
|
|
|
n->name = $5;
|
|
|
|
|
n->behavior = $6;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2009-07-20 04:42:28 +02:00
|
|
|
}
|
2008-06-15 03:25:54 +02:00
|
|
|
/* ALTER TABLE <name> DROP [COLUMN] <colname> [RESTRICT|CASCADE] */
|
2004-05-05 06:48:48 +02:00
|
|
|
| DROP opt_column ColId opt_drop_behavior
|
2000-02-15 04:26:38 +01:00
|
|
|
{
|
2004-05-05 06:48:48 +02:00
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-05-05 06:48:48 +02:00
|
|
|
n->subtype = AT_DropColumn;
|
|
|
|
|
n->name = $3;
|
|
|
|
|
n->behavior = $4;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-05-05 06:48:48 +02:00
|
|
|
}
|
|
|
|
|
/*
|
2008-10-21 10:38:16 +02:00
|
|
|
* ALTER TABLE <name> ALTER [COLUMN] <colname> [SET DATA] TYPE <typename>
|
2004-05-05 06:48:48 +02:00
|
|
|
* [ USING <expression> ]
|
|
|
|
|
*/
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
| ALTER opt_column ColId opt_set_data TYPE_P Typename opt_collate_clause alter_using
|
2004-05-05 06:48:48 +02:00
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
ColumnDef *def = makeNode(ColumnDef);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-05-05 06:48:48 +02:00
|
|
|
n->subtype = AT_AlterColumnType;
|
|
|
|
|
n->name = $3;
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
n->def = (Node *) def;
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
/* We only use these fields of the ColumnDef node */
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
def->typeName = $6;
|
|
|
|
|
def->collClause = (CollateClause *) $7;
|
|
|
|
|
def->raw_default = $8;
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
def->location = @3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-02-15 04:26:38 +01:00
|
|
|
}
|
2011-08-05 19:24:03 +02:00
|
|
|
/* ALTER FOREIGN TABLE <name> ALTER [COLUMN] <colname> OPTIONS */
|
|
|
|
|
| ALTER opt_column ColId alter_generic_options
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-08-05 19:24:03 +02:00
|
|
|
n->subtype = AT_AlterColumnGenericOptions;
|
|
|
|
|
n->name = $3;
|
|
|
|
|
n->def = (Node *) $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-08-05 19:24:03 +02:00
|
|
|
}
|
2008-06-15 03:25:54 +02:00
|
|
|
/* ALTER TABLE <name> ADD CONSTRAINT ... */
|
2005-12-27 05:00:08 +01:00
|
|
|
| ADD_P TableConstraint
|
2000-02-15 04:26:38 +01:00
|
|
|
{
|
2004-05-05 06:48:48 +02:00
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-05-05 06:48:48 +02:00
|
|
|
n->subtype = AT_AddConstraint;
|
|
|
|
|
n->def = $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-02-15 04:26:38 +01:00
|
|
|
}
|
2013-06-29 01:27:30 +02:00
|
|
|
/* ALTER TABLE <name> ALTER CONSTRAINT ... */
|
|
|
|
|
| ALTER CONSTRAINT name ConstraintAttributeSpec
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
|
|
|
|
Constraint *c = makeNode(Constraint);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2013-06-29 01:27:30 +02:00
|
|
|
n->subtype = AT_AlterConstraint;
|
|
|
|
|
n->def = (Node *) c;
|
|
|
|
|
c->contype = CONSTR_FOREIGN; /* others not supported, yet */
|
|
|
|
|
c->conname = $3;
|
|
|
|
|
processCASbits($4, @4, "ALTER CONSTRAINT statement",
|
|
|
|
|
&c->deferrable,
|
|
|
|
|
&c->initdeferred,
|
|
|
|
|
NULL, NULL, yyscanner);
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2013-06-29 01:27:30 +02:00
|
|
|
}
|
2011-02-08 13:23:20 +01:00
|
|
|
/* ALTER TABLE <name> VALIDATE CONSTRAINT ... */
|
|
|
|
|
| VALIDATE CONSTRAINT name
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-02-08 13:23:20 +01:00
|
|
|
n->subtype = AT_ValidateConstraint;
|
|
|
|
|
n->name = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-02-08 13:23:20 +01:00
|
|
|
}
|
2009-07-20 04:42:28 +02:00
|
|
|
/* ALTER TABLE <name> DROP CONSTRAINT IF EXISTS <name> [RESTRICT|CASCADE] */
|
|
|
|
|
| DROP CONSTRAINT IF_P EXISTS name opt_drop_behavior
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-07-20 04:42:28 +02:00
|
|
|
n->subtype = AT_DropConstraint;
|
|
|
|
|
n->name = $5;
|
|
|
|
|
n->behavior = $6;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2009-07-20 04:42:28 +02:00
|
|
|
}
|
2008-06-15 03:25:54 +02:00
|
|
|
/* ALTER TABLE <name> DROP CONSTRAINT <name> [RESTRICT|CASCADE] */
|
2004-05-05 06:48:48 +02:00
|
|
|
| DROP CONSTRAINT name opt_drop_behavior
|
2000-02-15 04:26:38 +01:00
|
|
|
{
|
2004-05-05 06:48:48 +02:00
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-05-05 06:48:48 +02:00
|
|
|
n->subtype = AT_DropConstraint;
|
|
|
|
|
n->name = $3;
|
|
|
|
|
n->behavior = $4;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-02-15 04:26:38 +01:00
|
|
|
}
|
2021-03-25 10:17:52 +01:00
|
|
|
/* ALTER TABLE <name> SET WITHOUT OIDS, for backward compat */
|
2004-05-05 06:48:48 +02:00
|
|
|
| SET WITHOUT OIDS
|
2003-02-13 06:20:05 +01:00
|
|
|
{
|
2004-05-05 06:48:48 +02:00
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-05-05 06:48:48 +02:00
|
|
|
n->subtype = AT_DropOids;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2003-02-13 06:20:05 +01:00
|
|
|
}
|
2003-03-20 19:52:48 +01:00
|
|
|
/* ALTER TABLE <name> CLUSTER ON <indexname> */
|
2004-05-05 06:48:48 +02:00
|
|
|
| CLUSTER ON name
|
2003-03-20 19:52:48 +01:00
|
|
|
{
|
2004-05-05 06:48:48 +02:00
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-05-05 06:48:48 +02:00
|
|
|
n->subtype = AT_ClusterOn;
|
|
|
|
|
n->name = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2003-03-20 19:52:48 +01:00
|
|
|
}
|
2004-06-18 08:14:31 +02:00
|
|
|
/* ALTER TABLE <name> SET WITHOUT CLUSTER */
|
2004-06-02 23:01:10 +02:00
|
|
|
| SET WITHOUT CLUSTER
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-06-02 23:01:10 +02:00
|
|
|
n->subtype = AT_DropCluster;
|
|
|
|
|
n->name = NULL;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-06-02 23:01:10 +02:00
|
|
|
}
|
2021-03-25 10:17:52 +01:00
|
|
|
/* ALTER TABLE <name> SET LOGGED */
|
2014-08-22 20:27:00 +02:00
|
|
|
| SET LOGGED
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-08-22 20:27:00 +02:00
|
|
|
n->subtype = AT_SetLogged;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2014-08-22 20:27:00 +02:00
|
|
|
}
|
2021-03-25 10:17:52 +01:00
|
|
|
/* ALTER TABLE <name> SET UNLOGGED */
|
2014-08-22 20:27:00 +02:00
|
|
|
| SET UNLOGGED
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-08-22 20:27:00 +02:00
|
|
|
n->subtype = AT_SetUnLogged;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2014-08-22 20:27:00 +02:00
|
|
|
}
|
2005-08-24 00:40:47 +02:00
|
|
|
/* ALTER TABLE <name> ENABLE TRIGGER <trig> */
|
|
|
|
|
| ENABLE_P TRIGGER name
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-08-24 00:40:47 +02:00
|
|
|
n->subtype = AT_EnableTrig;
|
|
|
|
|
n->name = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-08-24 00:40:47 +02:00
|
|
|
}
|
2007-03-20 00:38:32 +01:00
|
|
|
/* ALTER TABLE <name> ENABLE ALWAYS TRIGGER <trig> */
|
|
|
|
|
| ENABLE_P ALWAYS TRIGGER name
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-03-20 00:38:32 +01:00
|
|
|
n->subtype = AT_EnableAlwaysTrig;
|
|
|
|
|
n->name = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-03-20 00:38:32 +01:00
|
|
|
}
|
|
|
|
|
/* ALTER TABLE <name> ENABLE REPLICA TRIGGER <trig> */
|
|
|
|
|
| ENABLE_P REPLICA TRIGGER name
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-03-20 00:38:32 +01:00
|
|
|
n->subtype = AT_EnableReplicaTrig;
|
|
|
|
|
n->name = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-03-20 00:38:32 +01:00
|
|
|
}
|
2005-08-24 00:40:47 +02:00
|
|
|
/* ALTER TABLE <name> ENABLE TRIGGER ALL */
|
|
|
|
|
| ENABLE_P TRIGGER ALL
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-08-24 00:40:47 +02:00
|
|
|
n->subtype = AT_EnableTrigAll;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-08-24 00:40:47 +02:00
|
|
|
}
|
|
|
|
|
/* ALTER TABLE <name> ENABLE TRIGGER USER */
|
|
|
|
|
| ENABLE_P TRIGGER USER
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-08-24 00:40:47 +02:00
|
|
|
n->subtype = AT_EnableTrigUser;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-08-24 00:40:47 +02:00
|
|
|
}
|
|
|
|
|
/* ALTER TABLE <name> DISABLE TRIGGER <trig> */
|
|
|
|
|
| DISABLE_P TRIGGER name
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-08-24 00:40:47 +02:00
|
|
|
n->subtype = AT_DisableTrig;
|
|
|
|
|
n->name = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-08-24 00:40:47 +02:00
|
|
|
}
|
|
|
|
|
/* ALTER TABLE <name> DISABLE TRIGGER ALL */
|
|
|
|
|
| DISABLE_P TRIGGER ALL
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-08-24 00:40:47 +02:00
|
|
|
n->subtype = AT_DisableTrigAll;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-08-24 00:40:47 +02:00
|
|
|
}
|
|
|
|
|
/* ALTER TABLE <name> DISABLE TRIGGER USER */
|
|
|
|
|
| DISABLE_P TRIGGER USER
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-08-24 00:40:47 +02:00
|
|
|
n->subtype = AT_DisableTrigUser;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-08-24 00:40:47 +02:00
|
|
|
}
|
2007-03-20 00:38:32 +01:00
|
|
|
/* ALTER TABLE <name> ENABLE RULE <rule> */
|
|
|
|
|
| ENABLE_P RULE name
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-03-20 00:38:32 +01:00
|
|
|
n->subtype = AT_EnableRule;
|
|
|
|
|
n->name = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-03-20 00:38:32 +01:00
|
|
|
}
|
|
|
|
|
/* ALTER TABLE <name> ENABLE ALWAYS RULE <rule> */
|
|
|
|
|
| ENABLE_P ALWAYS RULE name
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-03-20 00:38:32 +01:00
|
|
|
n->subtype = AT_EnableAlwaysRule;
|
|
|
|
|
n->name = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-03-20 00:38:32 +01:00
|
|
|
}
|
|
|
|
|
/* ALTER TABLE <name> ENABLE REPLICA RULE <rule> */
|
|
|
|
|
| ENABLE_P REPLICA RULE name
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-03-20 00:38:32 +01:00
|
|
|
n->subtype = AT_EnableReplicaRule;
|
|
|
|
|
n->name = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-03-20 00:38:32 +01:00
|
|
|
}
|
|
|
|
|
/* ALTER TABLE <name> DISABLE RULE <rule> */
|
|
|
|
|
| DISABLE_P RULE name
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-03-20 00:38:32 +01:00
|
|
|
n->subtype = AT_DisableRule;
|
|
|
|
|
n->name = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-03-20 00:38:32 +01:00
|
|
|
}
|
2006-10-13 23:43:19 +02:00
|
|
|
/* ALTER TABLE <name> INHERIT <parent> */
|
2006-07-02 03:58:36 +02:00
|
|
|
| INHERIT qualified_name
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2006-10-13 23:43:19 +02:00
|
|
|
n->subtype = AT_AddInherit;
|
|
|
|
|
n->def = (Node *) $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2006-07-02 03:58:36 +02:00
|
|
|
}
|
2006-10-13 23:43:19 +02:00
|
|
|
/* ALTER TABLE <name> NO INHERIT <parent> */
|
2006-07-02 03:58:36 +02:00
|
|
|
| NO INHERIT qualified_name
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2006-10-13 23:43:19 +02:00
|
|
|
n->subtype = AT_DropInherit;
|
|
|
|
|
n->def = (Node *) $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2006-07-02 03:58:36 +02:00
|
|
|
}
|
2011-04-21 03:35:15 +02:00
|
|
|
/* ALTER TABLE <name> OF <type_name> */
|
|
|
|
|
| OF any_name
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
TypeName *def = makeTypeNameFromNameList($2);
|
|
|
|
|
|
2011-04-21 03:35:15 +02:00
|
|
|
def->location = @2;
|
|
|
|
|
n->subtype = AT_AddOf;
|
|
|
|
|
n->def = (Node *) def;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-04-21 03:35:15 +02:00
|
|
|
}
|
|
|
|
|
/* ALTER TABLE <name> NOT OF */
|
|
|
|
|
| NOT OF
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-04-21 03:35:15 +02:00
|
|
|
n->subtype = AT_DropOf;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-04-21 03:35:15 +02:00
|
|
|
}
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
/* ALTER TABLE <name> OWNER TO RoleSpec */
|
|
|
|
|
| OWNER TO RoleSpec
|
2004-08-20 06:29:33 +02:00
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-08-20 06:29:33 +02:00
|
|
|
n->subtype = AT_ChangeOwner;
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
n->newowner = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-08-20 06:29:33 +02:00
|
|
|
}
|
2021-07-28 03:10:44 +02:00
|
|
|
/* ALTER TABLE <name> SET ACCESS METHOD <amname> */
|
|
|
|
|
| SET ACCESS METHOD name
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-07-28 03:10:44 +02:00
|
|
|
n->subtype = AT_SetAccessMethod;
|
|
|
|
|
n->name = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2021-07-28 03:10:44 +02:00
|
|
|
}
|
2008-06-15 03:25:54 +02:00
|
|
|
/* ALTER TABLE <name> SET TABLESPACE <tablespacename> */
|
2004-07-12 01:13:58 +02:00
|
|
|
| SET TABLESPACE name
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-07-12 01:13:58 +02:00
|
|
|
n->subtype = AT_SetTableSpace;
|
|
|
|
|
n->name = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-07-12 01:13:58 +02:00
|
|
|
}
|
2008-06-15 03:25:54 +02:00
|
|
|
/* ALTER TABLE <name> SET (...) */
|
2009-02-02 20:31:40 +01:00
|
|
|
| SET reloptions
|
2006-07-02 04:23:23 +02:00
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2006-07-04 00:45:41 +02:00
|
|
|
n->subtype = AT_SetRelOptions;
|
2022-05-13 07:17:29 +02:00
|
|
|
n->def = (Node *) $2;
|
|
|
|
|
$$ = (Node *) n;
|
2006-07-02 04:23:23 +02:00
|
|
|
}
|
2008-06-15 03:25:54 +02:00
|
|
|
/* ALTER TABLE <name> RESET (...) */
|
2009-02-02 20:31:40 +01:00
|
|
|
| RESET reloptions
|
2006-07-02 04:23:23 +02:00
|
|
|
{
|
2006-07-04 00:45:41 +02:00
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2006-07-04 00:45:41 +02:00
|
|
|
n->subtype = AT_ResetRelOptions;
|
2022-05-13 07:17:29 +02:00
|
|
|
n->def = (Node *) $2;
|
|
|
|
|
$$ = (Node *) n;
|
2006-07-02 04:23:23 +02:00
|
|
|
}
|
2021-03-25 10:17:52 +01:00
|
|
|
/* ALTER TABLE <name> REPLICA IDENTITY */
|
2013-11-08 18:30:43 +01:00
|
|
|
| REPLICA IDENTITY_P replica_identity
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2013-11-08 18:30:43 +01:00
|
|
|
n->subtype = AT_ReplicaIdentity;
|
|
|
|
|
n->def = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2013-11-08 18:30:43 +01:00
|
|
|
}
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
/* ALTER TABLE <name> ENABLE ROW LEVEL SECURITY */
|
|
|
|
|
| ENABLE_P ROW LEVEL SECURITY
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
n->subtype = AT_EnableRowSecurity;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
}
|
|
|
|
|
/* ALTER TABLE <name> DISABLE ROW LEVEL SECURITY */
|
|
|
|
|
| DISABLE_P ROW LEVEL SECURITY
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
n->subtype = AT_DisableRowSecurity;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
}
|
2015-10-05 03:05:08 +02:00
|
|
|
/* ALTER TABLE <name> FORCE ROW LEVEL SECURITY */
|
|
|
|
|
| FORCE ROW LEVEL SECURITY
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2015-10-05 03:05:08 +02:00
|
|
|
n->subtype = AT_ForceRowSecurity;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2015-10-05 03:05:08 +02:00
|
|
|
}
|
|
|
|
|
/* ALTER TABLE <name> NO FORCE ROW LEVEL SECURITY */
|
|
|
|
|
| NO FORCE ROW LEVEL SECURITY
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2015-10-05 03:05:08 +02:00
|
|
|
n->subtype = AT_NoForceRowSecurity;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2015-10-05 03:05:08 +02:00
|
|
|
}
|
2011-01-02 05:48:11 +01:00
|
|
|
| alter_generic_options
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-01-02 05:48:11 +01:00
|
|
|
n->subtype = AT_GenericOptions;
|
2022-05-13 07:17:29 +02:00
|
|
|
n->def = (Node *) $1;
|
2011-01-02 05:48:11 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2000-02-15 04:26:38 +01:00
|
|
|
;
|
2000-01-16 21:05:00 +01:00
|
|
|
|
2001-05-07 02:43:27 +02:00
|
|
|
alter_column_default:
|
2007-10-29 20:40:40 +01:00
|
|
|
SET DEFAULT a_expr { $$ = $3; }
|
2004-05-05 06:48:48 +02:00
|
|
|
| DROP DEFAULT { $$ = NULL; }
|
2002-06-17 22:27:43 +02:00
|
|
|
;
|
2000-01-16 21:05:00 +01:00
|
|
|
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
opt_collate_clause:
|
|
|
|
|
COLLATE any_name
|
|
|
|
|
{
|
|
|
|
|
CollateClause *n = makeNode(CollateClause);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
n->arg = NULL;
|
2011-03-11 22:27:51 +01:00
|
|
|
n->collname = $2;
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
n->location = @1;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| /* EMPTY */ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
2004-05-05 06:48:48 +02:00
|
|
|
alter_using:
|
|
|
|
|
USING a_expr { $$ = $2; }
|
|
|
|
|
| /* EMPTY */ { $$ = NULL; }
|
|
|
|
|
;
|
1997-09-18 05:46:18 +02:00
|
|
|
|
2013-11-08 18:30:43 +01:00
|
|
|
replica_identity:
|
|
|
|
|
NOTHING
|
|
|
|
|
{
|
|
|
|
|
ReplicaIdentityStmt *n = makeNode(ReplicaIdentityStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2013-11-08 18:30:43 +01:00
|
|
|
n->identity_type = REPLICA_IDENTITY_NOTHING;
|
|
|
|
|
n->name = NULL;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| FULL
|
|
|
|
|
{
|
|
|
|
|
ReplicaIdentityStmt *n = makeNode(ReplicaIdentityStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2013-11-08 18:30:43 +01:00
|
|
|
n->identity_type = REPLICA_IDENTITY_FULL;
|
|
|
|
|
n->name = NULL;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| DEFAULT
|
|
|
|
|
{
|
|
|
|
|
ReplicaIdentityStmt *n = makeNode(ReplicaIdentityStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2013-11-08 18:30:43 +01:00
|
|
|
n->identity_type = REPLICA_IDENTITY_DEFAULT;
|
|
|
|
|
n->name = NULL;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| USING INDEX name
|
|
|
|
|
{
|
|
|
|
|
ReplicaIdentityStmt *n = makeNode(ReplicaIdentityStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2013-11-08 18:30:43 +01:00
|
|
|
n->identity_type = REPLICA_IDENTITY_INDEX;
|
|
|
|
|
n->name = $3;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2009-02-02 20:31:40 +01:00
|
|
|
reloptions:
|
2011-11-01 20:50:00 +01:00
|
|
|
'(' reloption_list ')' { $$ = $2; }
|
2009-02-02 20:31:40 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_reloptions: WITH reloptions { $$ = $2; }
|
|
|
|
|
| /* EMPTY */ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
reloption_list:
|
|
|
|
|
reloption_elem { $$ = list_make1($1); }
|
|
|
|
|
| reloption_list ',' reloption_elem { $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
2009-04-04 23:12:31 +02:00
|
|
|
/* This should match def_elem and also allow qualified names */
|
2009-10-05 21:24:49 +02:00
|
|
|
reloption_elem:
|
2009-02-02 20:31:40 +01:00
|
|
|
ColLabel '=' def_arg
|
|
|
|
|
{
|
2016-09-06 18:00:00 +02:00
|
|
|
$$ = makeDefElem($1, (Node *) $3, @1);
|
2009-02-02 20:31:40 +01:00
|
|
|
}
|
|
|
|
|
| ColLabel
|
|
|
|
|
{
|
2016-09-06 18:00:00 +02:00
|
|
|
$$ = makeDefElem($1, NULL, @1);
|
2009-02-02 20:31:40 +01:00
|
|
|
}
|
|
|
|
|
| ColLabel '.' ColLabel '=' def_arg
|
|
|
|
|
{
|
2009-04-04 23:12:31 +02:00
|
|
|
$$ = makeDefElemExtended($1, $3, (Node *) $5,
|
2016-09-06 18:00:00 +02:00
|
|
|
DEFELEM_UNSPEC, @1);
|
2009-02-02 20:31:40 +01:00
|
|
|
}
|
|
|
|
|
| ColLabel '.' ColLabel
|
|
|
|
|
{
|
2016-09-06 18:00:00 +02:00
|
|
|
$$ = makeDefElemExtended($1, $3, NULL, DEFELEM_UNSPEC, @1);
|
2009-02-02 20:31:40 +01:00
|
|
|
}
|
|
|
|
|
;
|
2004-08-20 06:29:33 +02:00
|
|
|
|
2017-04-06 14:33:16 +02:00
|
|
|
alter_identity_column_option_list:
|
|
|
|
|
alter_identity_column_option
|
|
|
|
|
{ $$ = list_make1($1); }
|
|
|
|
|
| alter_identity_column_option_list alter_identity_column_option
|
|
|
|
|
{ $$ = lappend($1, $2); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
alter_identity_column_option:
|
|
|
|
|
RESTART
|
|
|
|
|
{
|
|
|
|
|
$$ = makeDefElem("restart", NULL, @1);
|
|
|
|
|
}
|
|
|
|
|
| RESTART opt_with NumericOnly
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("restart", (Node *) $3, @1);
|
2017-04-06 14:33:16 +02:00
|
|
|
}
|
|
|
|
|
| SET SeqOptElem
|
|
|
|
|
{
|
|
|
|
|
if (strcmp($2->defname, "as") == 0 ||
|
|
|
|
|
strcmp($2->defname, "restart") == 0 ||
|
|
|
|
|
strcmp($2->defname, "owned_by") == 0)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("sequence option \"%s\" not supported here", $2->defname),
|
|
|
|
|
parser_errposition(@2)));
|
|
|
|
|
$$ = $2;
|
|
|
|
|
}
|
|
|
|
|
| SET GENERATED generated_when
|
|
|
|
|
{
|
|
|
|
|
$$ = makeDefElem("generated", (Node *) makeInteger($3), @1);
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
|
|
|
PartitionBoundSpec:
|
2019-01-23 12:39:00 +01:00
|
|
|
/* a HASH partition */
|
Add hash partitioning.
Hash partitioning is useful when you want to partition a growing data
set evenly. This can be useful to keep table sizes reasonable, which
makes maintenance operations such as VACUUM faster, or to enable
partition-wise join.
At present, we still depend on constraint exclusion for partitioning
pruning, and the shape of the partition constraints for hash
partitioning is such that that doesn't work. Work is underway to fix
that, which should both improve performance and make partitioning
pruning work with hash partitioning.
Amul Sul, reviewed and tested by Dilip Kumar, Ashutosh Bapat, Yugo
Nagata, Rajkumar Raghuwanshi, Jesper Pedersen, and by me. A few
final tweaks also by me.
Discussion: http://postgr.es/m/CAAJ_b96fhpJAP=ALbETmeLk1Uni_GFZD938zgenhF49qgDTjaQ@mail.gmail.com
2017-11-10 00:07:25 +01:00
|
|
|
FOR VALUES WITH '(' hash_partbound ')'
|
|
|
|
|
{
|
|
|
|
|
ListCell *lc;
|
|
|
|
|
PartitionBoundSpec *n = makeNode(PartitionBoundSpec);
|
|
|
|
|
|
|
|
|
|
n->strategy = PARTITION_STRATEGY_HASH;
|
|
|
|
|
n->modulus = n->remainder = -1;
|
|
|
|
|
|
|
|
|
|
foreach (lc, $5)
|
|
|
|
|
{
|
|
|
|
|
DefElem *opt = lfirst_node(DefElem, lc);
|
|
|
|
|
|
|
|
|
|
if (strcmp(opt->defname, "modulus") == 0)
|
|
|
|
|
{
|
|
|
|
|
if (n->modulus != -1)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_DUPLICATE_OBJECT),
|
|
|
|
|
errmsg("modulus for hash partition provided more than once"),
|
|
|
|
|
parser_errposition(opt->location)));
|
|
|
|
|
n->modulus = defGetInt32(opt);
|
|
|
|
|
}
|
|
|
|
|
else if (strcmp(opt->defname, "remainder") == 0)
|
|
|
|
|
{
|
|
|
|
|
if (n->remainder != -1)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_DUPLICATE_OBJECT),
|
|
|
|
|
errmsg("remainder for hash partition provided more than once"),
|
|
|
|
|
parser_errposition(opt->location)));
|
|
|
|
|
n->remainder = defGetInt32(opt);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("unrecognized hash partition bound specification \"%s\"",
|
|
|
|
|
opt->defname),
|
|
|
|
|
parser_errposition(opt->location)));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (n->modulus == -1)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("modulus for hash partition must be specified")));
|
|
|
|
|
if (n->remainder == -1)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("remainder for hash partition must be specified")));
|
|
|
|
|
|
|
|
|
|
n->location = @3;
|
|
|
|
|
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
/* a LIST partition */
|
2019-01-25 11:27:59 +01:00
|
|
|
| FOR VALUES IN_P '(' expr_list ')'
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
{
|
|
|
|
|
PartitionBoundSpec *n = makeNode(PartitionBoundSpec);
|
|
|
|
|
|
|
|
|
|
n->strategy = PARTITION_STRATEGY_LIST;
|
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
|
|
|
n->is_default = false;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
n->listdatums = $5;
|
|
|
|
|
n->location = @3;
|
|
|
|
|
|
Code review focused on new node types added by partitioning support.
Fix failure to check that we got a plain Const from const-simplification of
a coercion request. This is the cause of bug #14666 from Tian Bing: there
is an int4 to money cast, but it's only stable not immutable (because of
dependence on lc_monetary), resulting in a FuncExpr that the code was
miserably unequipped to deal with, or indeed even to notice that it was
failing to deal with. Add test cases around this coercion behavior.
In view of the above, sprinkle the code liberally with castNode() macros,
in hope of catching the next such bug a bit sooner. Also, change some
functions that were randomly declared to take Node* to take more specific
pointer types. And change some struct fields that were declared Node*
but could be given more specific types, allowing removal of assorted
explicit casts.
Place PARTITION_MAX_KEYS check a bit closer to the code it's protecting.
Likewise check only-one-key-for-list-partitioning restriction in a less
random place.
Avoid not-per-project-style usages like !strcmp(...).
Fix assorted failures to avoid scribbling on the input of parse
transformation. I'm not sure how necessary this is, but it's entirely
silly for these functions to be expending cycles to avoid that and not
getting it right.
Add guards against partitioning on system columns.
Put backend/nodes/ support code into an order that matches handling
of these node types elsewhere.
Annotate the fact that somebody added location fields to PartitionBoundSpec
and PartitionRangeDatum but forgot to handle them in
outfuncs.c/readfuncs.c. This is fairly harmless for production purposes
(since readfuncs.c would just substitute -1 anyway) but it's still bogus.
It's not worth forcing a post-beta1 initdb just to fix this, but if we
have another reason to force initdb before 10.0, we should go back and
clean this up.
Contrariwise, somebody added location fields to PartitionElem and
PartitionSpec but forgot to teach exprLocation() about them.
Consolidate duplicative code in transformPartitionBound().
Improve a couple of error messages.
Improve assorted commentary.
Re-pgindent the files touched by this patch; this affects a few comment
blocks that must have been added quite recently.
Report: https://postgr.es/m/20170524024550.29935.14396@wrigleys.postgresql.org
2017-05-29 05:20:28 +02:00
|
|
|
$$ = n;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* a RANGE partition */
|
2019-01-25 11:27:59 +01:00
|
|
|
| FOR VALUES FROM '(' expr_list ')' TO '(' expr_list ')'
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
{
|
|
|
|
|
PartitionBoundSpec *n = makeNode(PartitionBoundSpec);
|
|
|
|
|
|
|
|
|
|
n->strategy = PARTITION_STRATEGY_RANGE;
|
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
|
|
|
n->is_default = false;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
n->lowerdatums = $5;
|
|
|
|
|
n->upperdatums = $9;
|
|
|
|
|
n->location = @3;
|
|
|
|
|
|
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* a DEFAULT partition */
|
|
|
|
|
| DEFAULT
|
|
|
|
|
{
|
|
|
|
|
PartitionBoundSpec *n = makeNode(PartitionBoundSpec);
|
|
|
|
|
|
|
|
|
|
n->is_default = true;
|
|
|
|
|
n->location = @1;
|
|
|
|
|
|
Code review focused on new node types added by partitioning support.
Fix failure to check that we got a plain Const from const-simplification of
a coercion request. This is the cause of bug #14666 from Tian Bing: there
is an int4 to money cast, but it's only stable not immutable (because of
dependence on lc_monetary), resulting in a FuncExpr that the code was
miserably unequipped to deal with, or indeed even to notice that it was
failing to deal with. Add test cases around this coercion behavior.
In view of the above, sprinkle the code liberally with castNode() macros,
in hope of catching the next such bug a bit sooner. Also, change some
functions that were randomly declared to take Node* to take more specific
pointer types. And change some struct fields that were declared Node*
but could be given more specific types, allowing removal of assorted
explicit casts.
Place PARTITION_MAX_KEYS check a bit closer to the code it's protecting.
Likewise check only-one-key-for-list-partitioning restriction in a less
random place.
Avoid not-per-project-style usages like !strcmp(...).
Fix assorted failures to avoid scribbling on the input of parse
transformation. I'm not sure how necessary this is, but it's entirely
silly for these functions to be expending cycles to avoid that and not
getting it right.
Add guards against partitioning on system columns.
Put backend/nodes/ support code into an order that matches handling
of these node types elsewhere.
Annotate the fact that somebody added location fields to PartitionBoundSpec
and PartitionRangeDatum but forgot to handle them in
outfuncs.c/readfuncs.c. This is fairly harmless for production purposes
(since readfuncs.c would just substitute -1 anyway) but it's still bogus.
It's not worth forcing a post-beta1 initdb just to fix this, but if we
have another reason to force initdb before 10.0, we should go back and
clean this up.
Contrariwise, somebody added location fields to PartitionElem and
PartitionSpec but forgot to teach exprLocation() about them.
Consolidate duplicative code in transformPartitionBound().
Improve a couple of error messages.
Improve assorted commentary.
Re-pgindent the files touched by this patch; this affects a few comment
blocks that must have been added quite recently.
Report: https://postgr.es/m/20170524024550.29935.14396@wrigleys.postgresql.org
2017-05-29 05:20:28 +02:00
|
|
|
$$ = n;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
Add hash partitioning.
Hash partitioning is useful when you want to partition a growing data
set evenly. This can be useful to keep table sizes reasonable, which
makes maintenance operations such as VACUUM faster, or to enable
partition-wise join.
At present, we still depend on constraint exclusion for partitioning
pruning, and the shape of the partition constraints for hash
partitioning is such that that doesn't work. Work is underway to fix
that, which should both improve performance and make partitioning
pruning work with hash partitioning.
Amul Sul, reviewed and tested by Dilip Kumar, Ashutosh Bapat, Yugo
Nagata, Rajkumar Raghuwanshi, Jesper Pedersen, and by me. A few
final tweaks also by me.
Discussion: http://postgr.es/m/CAAJ_b96fhpJAP=ALbETmeLk1Uni_GFZD938zgenhF49qgDTjaQ@mail.gmail.com
2017-11-10 00:07:25 +01:00
|
|
|
hash_partbound_elem:
|
|
|
|
|
NonReservedWord Iconst
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem($1, (Node *) makeInteger($2), @1);
|
Add hash partitioning.
Hash partitioning is useful when you want to partition a growing data
set evenly. This can be useful to keep table sizes reasonable, which
makes maintenance operations such as VACUUM faster, or to enable
partition-wise join.
At present, we still depend on constraint exclusion for partitioning
pruning, and the shape of the partition constraints for hash
partitioning is such that that doesn't work. Work is underway to fix
that, which should both improve performance and make partitioning
pruning work with hash partitioning.
Amul Sul, reviewed and tested by Dilip Kumar, Ashutosh Bapat, Yugo
Nagata, Rajkumar Raghuwanshi, Jesper Pedersen, and by me. A few
final tweaks also by me.
Discussion: http://postgr.es/m/CAAJ_b96fhpJAP=ALbETmeLk1Uni_GFZD938zgenhF49qgDTjaQ@mail.gmail.com
2017-11-10 00:07:25 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
hash_partbound:
|
|
|
|
|
hash_partbound_elem
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make1($1);
|
|
|
|
|
}
|
|
|
|
|
| hash_partbound ',' hash_partbound_elem
|
|
|
|
|
{
|
|
|
|
|
$$ = lappend($1, $3);
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2010-09-26 13:41:03 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* ALTER TYPE
|
|
|
|
|
*
|
|
|
|
|
* really variants of the ALTER TABLE subcommands with different spellings
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
AlterCompositeTypeStmt:
|
|
|
|
|
ALTER TYPE_P any_name alter_type_cmds
|
|
|
|
|
{
|
|
|
|
|
AlterTableStmt *n = makeNode(AlterTableStmt);
|
|
|
|
|
|
|
|
|
|
/* can't use qualified_name, sigh */
|
|
|
|
|
n->relation = makeRangeVarFromAnyName($3, @3, yyscanner);
|
|
|
|
|
n->cmds = $4;
|
2020-07-11 06:32:28 +02:00
|
|
|
n->objtype = OBJECT_TYPE;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2010-09-26 13:41:03 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
alter_type_cmds:
|
|
|
|
|
alter_type_cmd { $$ = list_make1($1); }
|
|
|
|
|
| alter_type_cmds ',' alter_type_cmd { $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
alter_type_cmd:
|
2010-11-23 21:50:17 +01:00
|
|
|
/* ALTER TYPE <name> ADD ATTRIBUTE <coldef> [RESTRICT|CASCADE] */
|
|
|
|
|
ADD_P ATTRIBUTE TableFuncElement opt_drop_behavior
|
2010-09-26 13:41:03 +02:00
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-09-26 13:41:03 +02:00
|
|
|
n->subtype = AT_AddColumn;
|
|
|
|
|
n->def = $3;
|
2010-11-23 21:50:17 +01:00
|
|
|
n->behavior = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2010-09-26 13:41:03 +02:00
|
|
|
}
|
2010-11-23 21:50:17 +01:00
|
|
|
/* ALTER TYPE <name> DROP ATTRIBUTE IF EXISTS <attname> [RESTRICT|CASCADE] */
|
|
|
|
|
| DROP ATTRIBUTE IF_P EXISTS ColId opt_drop_behavior
|
2010-09-26 13:41:03 +02:00
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-09-26 13:41:03 +02:00
|
|
|
n->subtype = AT_DropColumn;
|
|
|
|
|
n->name = $5;
|
2010-11-23 21:50:17 +01:00
|
|
|
n->behavior = $6;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2010-09-26 13:41:03 +02:00
|
|
|
}
|
2010-11-23 21:50:17 +01:00
|
|
|
/* ALTER TYPE <name> DROP ATTRIBUTE <attname> [RESTRICT|CASCADE] */
|
2010-09-26 13:41:03 +02:00
|
|
|
| DROP ATTRIBUTE ColId opt_drop_behavior
|
|
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-09-26 13:41:03 +02:00
|
|
|
n->subtype = AT_DropColumn;
|
|
|
|
|
n->name = $3;
|
2010-11-23 21:50:17 +01:00
|
|
|
n->behavior = $4;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2010-09-26 13:41:03 +02:00
|
|
|
}
|
2010-11-23 21:50:17 +01:00
|
|
|
/* ALTER TYPE <name> ALTER ATTRIBUTE <attname> [SET DATA] TYPE <typename> [RESTRICT|CASCADE] */
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
| ALTER ATTRIBUTE ColId opt_set_data TYPE_P Typename opt_collate_clause opt_drop_behavior
|
2010-09-26 13:41:03 +02:00
|
|
|
{
|
|
|
|
|
AlterTableCmd *n = makeNode(AlterTableCmd);
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
ColumnDef *def = makeNode(ColumnDef);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-09-26 13:41:03 +02:00
|
|
|
n->subtype = AT_AlterColumnType;
|
|
|
|
|
n->name = $3;
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
n->def = (Node *) def;
|
|
|
|
|
n->behavior = $8;
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
/* We only use these fields of the ColumnDef node */
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
def->typeName = $6;
|
|
|
|
|
def->collClause = (CollateClause *) $7;
|
|
|
|
|
def->raw_default = NULL;
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
def->location = @3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2010-09-26 13:41:03 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
1997-09-01 08:00:35 +02:00
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* QUERY :
|
2003-03-11 20:40:24 +01:00
|
|
|
* close <portalname>
|
1997-09-01 08:00:35 +02:00
|
|
|
*
|
1996-07-09 08:22:35 +02:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
ClosePortalStmt:
|
2009-11-11 21:31:26 +01:00
|
|
|
CLOSE cursor_name
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
|
|
|
|
ClosePortalStmt *n = makeNode(ClosePortalStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
1997-09-08 05:20:18 +02:00
|
|
|
n->portalname = $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2007-04-12 08:53:49 +02:00
|
|
|
| CLOSE ALL
|
|
|
|
|
{
|
|
|
|
|
ClosePortalStmt *n = makeNode(ClosePortalStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-04-12 08:53:49 +02:00
|
|
|
n->portalname = NULL;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-04-12 08:53:49 +02:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* QUERY :
|
2009-09-21 22:10:21 +02:00
|
|
|
* COPY relname [(columnList)] FROM/TO file [WITH] [(options)]
|
2015-11-27 17:11:22 +01:00
|
|
|
* COPY ( query ) TO file [WITH] [(options)]
|
Add support for piping COPY to/from an external program.
This includes backend "COPY TO/FROM PROGRAM '...'" syntax, and corresponding
psql \copy syntax. Like with reading/writing files, the backend version is
superuser-only, and in the psql version, the program is run in the client.
In the passing, the psql \copy STDIN/STDOUT syntax is subtly changed: if you
the stdin/stdout is quoted, it's now interpreted as a filename. For example,
"\copy foo from 'stdin'" now reads from a file called 'stdin', not from
standard input. Before this, there was no way to specify a filename called
stdin, stdout, pstdin or pstdout.
This creates a new function in pgport, wait_result_to_str(), which can
be used to convert the exit status of a process, as returned by wait(3),
to a human-readable string.
Etsuro Fujita, reviewed by Amit Kapila.
2013-02-27 17:17:21 +01:00
|
|
|
*
|
2015-11-27 17:11:22 +01:00
|
|
|
* where 'query' can be one of:
|
|
|
|
|
* { SELECT | UPDATE | INSERT | DELETE }
|
|
|
|
|
*
|
|
|
|
|
* and 'file' can be one of:
|
Add support for piping COPY to/from an external program.
This includes backend "COPY TO/FROM PROGRAM '...'" syntax, and corresponding
psql \copy syntax. Like with reading/writing files, the backend version is
superuser-only, and in the psql version, the program is run in the client.
In the passing, the psql \copy STDIN/STDOUT syntax is subtly changed: if you
the stdin/stdout is quoted, it's now interpreted as a filename. For example,
"\copy foo from 'stdin'" now reads from a file called 'stdin', not from
standard input. Before this, there was no way to specify a filename called
stdin, stdout, pstdin or pstdout.
This creates a new function in pgport, wait_result_to_str(), which can
be used to convert the exit status of a process, as returned by wait(3),
to a human-readable string.
Etsuro Fujita, reviewed by Amit Kapila.
2013-02-27 17:17:21 +01:00
|
|
|
* { PROGRAM 'command' | STDIN | STDOUT | 'filename' }
|
2002-06-20 18:00:44 +02:00
|
|
|
*
|
2009-09-21 22:10:21 +02:00
|
|
|
* In the preferred syntax the options are comma-separated
|
2010-02-17 05:19:41 +01:00
|
|
|
* and use generic identifiers instead of keywords. The pre-9.0
|
2009-09-21 22:10:21 +02:00
|
|
|
* syntax had a hard-wired, space-separated set of options.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2009-09-21 22:10:21 +02:00
|
|
|
* Really old syntax, from versions 7.2 and prior:
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
* COPY [ BINARY ] table FROM/TO file
|
2009-09-21 22:10:21 +02:00
|
|
|
* [ [ USING ] DELIMITERS 'delimiter' ] ]
|
|
|
|
|
* [ WITH NULL AS 'null string' ]
|
2015-11-27 17:11:22 +01:00
|
|
|
* This option placement is not supported with COPY (query...).
|
2006-08-31 01:34:22 +02:00
|
|
|
*
|
1996-07-09 08:22:35 +02:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
CopyStmt: COPY opt_binary qualified_name opt_column_list
|
2019-01-19 23:48:16 +01:00
|
|
|
copy_from opt_program copy_file_name copy_delimiter opt_with
|
|
|
|
|
copy_options where_clause
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
|
|
|
|
CopyStmt *n = makeNode(CopyStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-03-21 17:02:16 +01:00
|
|
|
n->relation = $3;
|
2006-08-31 01:34:22 +02:00
|
|
|
n->query = NULL;
|
2002-07-18 06:43:51 +02:00
|
|
|
n->attlist = $4;
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
n->is_from = $5;
|
|
|
|
|
n->is_program = $6;
|
|
|
|
|
n->filename = $7;
|
2019-01-19 23:48:16 +01:00
|
|
|
n->whereClause = $11;
|
Add support for piping COPY to/from an external program.
This includes backend "COPY TO/FROM PROGRAM '...'" syntax, and corresponding
psql \copy syntax. Like with reading/writing files, the backend version is
superuser-only, and in the psql version, the program is run in the client.
In the passing, the psql \copy STDIN/STDOUT syntax is subtly changed: if you
the stdin/stdout is quoted, it's now interpreted as a filename. For example,
"\copy foo from 'stdin'" now reads from a file called 'stdin', not from
standard input. Before this, there was no way to specify a filename called
stdin, stdout, pstdin or pstdout.
This creates a new function in pgport, wait_result_to_str(), which can
be used to convert the exit status of a process, as returned by wait(3),
to a human-readable string.
Etsuro Fujita, reviewed by Amit Kapila.
2013-02-27 17:17:21 +01:00
|
|
|
|
|
|
|
|
if (n->is_program && n->filename == NULL)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("STDIN/STDOUT not allowed with PROGRAM"),
|
|
|
|
|
parser_errposition(@8)));
|
2002-06-20 18:00:44 +02:00
|
|
|
|
2019-01-19 23:48:16 +01:00
|
|
|
if (!n->is_from && n->whereClause != NULL)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("WHERE clause not allowed with COPY TO"),
|
|
|
|
|
parser_errposition(@11)));
|
|
|
|
|
|
2002-06-20 18:00:44 +02:00
|
|
|
n->options = NIL;
|
|
|
|
|
/* Concatenate user-supplied flags */
|
|
|
|
|
if ($2)
|
|
|
|
|
n->options = lappend(n->options, $2);
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
if ($8)
|
|
|
|
|
n->options = lappend(n->options, $8);
|
|
|
|
|
if ($10)
|
|
|
|
|
n->options = list_concat(n->options, $10);
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2015-11-27 17:11:22 +01:00
|
|
|
| COPY '(' PreparableStmt ')' TO opt_program copy_file_name opt_with copy_options
|
2006-08-31 01:34:22 +02:00
|
|
|
{
|
|
|
|
|
CopyStmt *n = makeNode(CopyStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2006-08-31 01:34:22 +02:00
|
|
|
n->relation = NULL;
|
2015-11-27 17:11:22 +01:00
|
|
|
n->query = $3;
|
2006-08-31 01:34:22 +02:00
|
|
|
n->attlist = NIL;
|
|
|
|
|
n->is_from = false;
|
2015-11-27 17:11:22 +01:00
|
|
|
n->is_program = $6;
|
|
|
|
|
n->filename = $7;
|
|
|
|
|
n->options = $9;
|
Add support for piping COPY to/from an external program.
This includes backend "COPY TO/FROM PROGRAM '...'" syntax, and corresponding
psql \copy syntax. Like with reading/writing files, the backend version is
superuser-only, and in the psql version, the program is run in the client.
In the passing, the psql \copy STDIN/STDOUT syntax is subtly changed: if you
the stdin/stdout is quoted, it's now interpreted as a filename. For example,
"\copy foo from 'stdin'" now reads from a file called 'stdin', not from
standard input. Before this, there was no way to specify a filename called
stdin, stdout, pstdin or pstdout.
This creates a new function in pgport, wait_result_to_str(), which can
be used to convert the exit status of a process, as returned by wait(3),
to a human-readable string.
Etsuro Fujita, reviewed by Amit Kapila.
2013-02-27 17:17:21 +01:00
|
|
|
|
|
|
|
|
if (n->is_program && n->filename == NULL)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("STDIN/STDOUT not allowed with PROGRAM"),
|
|
|
|
|
parser_errposition(@5)));
|
|
|
|
|
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2006-08-31 01:34:22 +02:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-20 18:00:44 +02:00
|
|
|
copy_from:
|
2017-08-16 06:22:32 +02:00
|
|
|
FROM { $$ = true; }
|
|
|
|
|
| TO { $$ = false; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
Add support for piping COPY to/from an external program.
This includes backend "COPY TO/FROM PROGRAM '...'" syntax, and corresponding
psql \copy syntax. Like with reading/writing files, the backend version is
superuser-only, and in the psql version, the program is run in the client.
In the passing, the psql \copy STDIN/STDOUT syntax is subtly changed: if you
the stdin/stdout is quoted, it's now interpreted as a filename. For example,
"\copy foo from 'stdin'" now reads from a file called 'stdin', not from
standard input. Before this, there was no way to specify a filename called
stdin, stdout, pstdin or pstdout.
This creates a new function in pgport, wait_result_to_str(), which can
be used to convert the exit status of a process, as returned by wait(3),
to a human-readable string.
Etsuro Fujita, reviewed by Amit Kapila.
2013-02-27 17:17:21 +01:00
|
|
|
opt_program:
|
2017-08-16 06:22:32 +02:00
|
|
|
PROGRAM { $$ = true; }
|
|
|
|
|
| /* EMPTY */ { $$ = false; }
|
Add support for piping COPY to/from an external program.
This includes backend "COPY TO/FROM PROGRAM '...'" syntax, and corresponding
psql \copy syntax. Like with reading/writing files, the backend version is
superuser-only, and in the psql version, the program is run in the client.
In the passing, the psql \copy STDIN/STDOUT syntax is subtly changed: if you
the stdin/stdout is quoted, it's now interpreted as a filename. For example,
"\copy foo from 'stdin'" now reads from a file called 'stdin', not from
standard input. Before this, there was no way to specify a filename called
stdin, stdout, pstdin or pstdout.
This creates a new function in pgport, wait_result_to_str(), which can
be used to convert the exit status of a process, as returned by wait(3),
to a human-readable string.
Etsuro Fujita, reviewed by Amit Kapila.
2013-02-27 17:17:21 +01:00
|
|
|
;
|
|
|
|
|
|
1997-09-01 08:00:35 +02:00
|
|
|
/*
|
1996-07-09 08:22:35 +02:00
|
|
|
* copy_file_name NULL indicates stdio is used. Whether stdin or stdout is
|
|
|
|
|
* used depends on the direction. (It really doesn't make sense to copy from
|
2006-08-31 01:34:22 +02:00
|
|
|
* stdout. We silently correct the "typo".) - AY 9/94
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
copy_file_name:
|
|
|
|
|
Sconst { $$ = $1; }
|
|
|
|
|
| STDIN { $$ = NULL; }
|
|
|
|
|
| STDOUT { $$ = NULL; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2009-09-21 22:10:21 +02:00
|
|
|
copy_options: copy_opt_list { $$ = $1; }
|
|
|
|
|
| '(' copy_generic_opt_list ')' { $$ = $2; }
|
|
|
|
|
;
|
2002-06-20 18:00:44 +02:00
|
|
|
|
2009-09-21 22:10:21 +02:00
|
|
|
/* old COPY option syntax */
|
2002-06-20 18:00:44 +02:00
|
|
|
copy_opt_list:
|
|
|
|
|
copy_opt_list copy_opt_item { $$ = lappend($1, $2); }
|
|
|
|
|
| /* EMPTY */ { $$ = NIL; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-06-20 18:00:44 +02:00
|
|
|
copy_opt_item:
|
|
|
|
|
BINARY
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("format", (Node *) makeString("binary"), @1);
|
2002-06-20 18:00:44 +02:00
|
|
|
}
|
2012-12-01 13:54:20 +01:00
|
|
|
| FREEZE
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("freeze", (Node *) makeBoolean(true), @1);
|
2012-12-01 13:54:20 +01:00
|
|
|
}
|
2002-06-20 18:00:44 +02:00
|
|
|
| DELIMITER opt_as Sconst
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("delimiter", (Node *) makeString($3), @1);
|
2002-06-20 18:00:44 +02:00
|
|
|
}
|
|
|
|
|
| NULL_P opt_as Sconst
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("null", (Node *) makeString($3), @1);
|
2002-06-20 18:00:44 +02:00
|
|
|
}
|
2004-04-19 19:22:31 +02:00
|
|
|
| CSV
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("format", (Node *) makeString("csv"), @1);
|
2004-04-19 19:22:31 +02:00
|
|
|
}
|
2005-12-27 05:00:08 +01:00
|
|
|
| HEADER_P
|
2005-05-07 04:22:49 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("header", (Node *) makeBoolean(true), @1);
|
2005-05-07 04:22:49 +02:00
|
|
|
}
|
2004-04-19 19:22:31 +02:00
|
|
|
| QUOTE opt_as Sconst
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("quote", (Node *) makeString($3), @1);
|
2004-04-19 19:22:31 +02:00
|
|
|
}
|
|
|
|
|
| ESCAPE opt_as Sconst
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("escape", (Node *) makeString($3), @1);
|
2004-04-19 19:22:31 +02:00
|
|
|
}
|
2004-04-21 02:34:18 +02:00
|
|
|
| FORCE QUOTE columnList
|
2004-04-19 19:22:31 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("force_quote", (Node *) $3, @1);
|
2004-04-19 19:22:31 +02:00
|
|
|
}
|
2009-07-25 02:07:14 +02:00
|
|
|
| FORCE QUOTE '*'
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("force_quote", (Node *) makeNode(A_Star), @1);
|
2009-07-25 02:07:14 +02:00
|
|
|
}
|
2004-04-21 02:34:18 +02:00
|
|
|
| FORCE NOT NULL_P columnList
|
2004-04-19 19:22:31 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("force_not_null", (Node *) $4, @1);
|
2004-04-19 19:22:31 +02:00
|
|
|
}
|
2014-03-04 23:31:59 +01:00
|
|
|
| FORCE NULL_P columnList
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("force_null", (Node *) $3, @1);
|
2014-03-04 23:31:59 +01:00
|
|
|
}
|
2011-02-21 06:08:04 +01:00
|
|
|
| ENCODING Sconst
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("encoding", (Node *) makeString($2), @1);
|
2011-02-21 06:08:04 +01:00
|
|
|
}
|
2002-06-20 18:00:44 +02:00
|
|
|
;
|
|
|
|
|
|
2009-09-21 22:10:21 +02:00
|
|
|
/* The following exist for backward compatibility with very old versions */
|
2002-06-20 18:00:44 +02:00
|
|
|
|
|
|
|
|
opt_binary:
|
|
|
|
|
BINARY
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("format", (Node *) makeString("binary"), @1);
|
2002-06-20 18:00:44 +02:00
|
|
|
}
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
copy_delimiter:
|
2002-06-20 18:00:44 +02:00
|
|
|
opt_using DELIMITERS Sconst
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("delimiter", (Node *) makeString($3), @2);
|
2002-06-20 18:00:44 +02:00
|
|
|
}
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-06-20 18:00:44 +02:00
|
|
|
opt_using:
|
2020-11-12 07:48:36 +01:00
|
|
|
USING
|
|
|
|
|
| /*EMPTY*/
|
1999-10-30 01:52:22 +02:00
|
|
|
;
|
|
|
|
|
|
2009-09-21 22:10:21 +02:00
|
|
|
/* new COPY option syntax */
|
|
|
|
|
copy_generic_opt_list:
|
|
|
|
|
copy_generic_opt_elem
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make1($1);
|
|
|
|
|
}
|
|
|
|
|
| copy_generic_opt_list ',' copy_generic_opt_elem
|
|
|
|
|
{
|
|
|
|
|
$$ = lappend($1, $3);
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
copy_generic_opt_elem:
|
|
|
|
|
ColLabel copy_generic_opt_arg
|
|
|
|
|
{
|
2016-09-06 18:00:00 +02:00
|
|
|
$$ = makeDefElem($1, $2, @1);
|
2009-09-21 22:10:21 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
copy_generic_opt_arg:
|
2010-10-22 16:37:38 +02:00
|
|
|
opt_boolean_or_string { $$ = (Node *) makeString($1); }
|
2009-09-21 22:10:21 +02:00
|
|
|
| NumericOnly { $$ = (Node *) $1; }
|
|
|
|
|
| '*' { $$ = (Node *) makeNode(A_Star); }
|
|
|
|
|
| '(' copy_generic_opt_arg_list ')' { $$ = (Node *) $2; }
|
|
|
|
|
| /* EMPTY */ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
copy_generic_opt_arg_list:
|
|
|
|
|
copy_generic_opt_arg_list_item
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make1($1);
|
|
|
|
|
}
|
|
|
|
|
| copy_generic_opt_arg_list ',' copy_generic_opt_arg_list_item
|
|
|
|
|
{
|
|
|
|
|
$$ = lappend($1, $3);
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/* beware of emitting non-string list elements here; see commands/define.c */
|
|
|
|
|
copy_generic_opt_arg_list_item:
|
2010-10-22 16:37:38 +02:00
|
|
|
opt_boolean_or_string { $$ = (Node *) makeString($1); }
|
2009-09-21 22:10:21 +02:00
|
|
|
;
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* QUERY :
|
2002-11-23 04:59:09 +01:00
|
|
|
* CREATE TABLE relname
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-18 19:56:41 +02:00
|
|
|
CreateStmt: CREATE OptTemp TABLE qualified_name '(' OptTableElementList ')'
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
OptInherit OptPartitionSpec table_access_method_clause OptWith
|
|
|
|
|
OnCommitOption OptTableSpace
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
|
|
|
|
CreateStmt *n = makeNode(CreateStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-12-13 18:34:26 +01:00
|
|
|
$4->relpersistence = $2;
|
2002-03-21 17:02:16 +01:00
|
|
|
n->relation = $4;
|
2001-01-05 07:34:23 +01:00
|
|
|
n->tableElts = $6;
|
2002-03-21 17:02:16 +01:00
|
|
|
n->inhRelations = $8;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
n->partspec = $9;
|
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
|
|
|
n->ofTypename = NULL;
|
1997-12-05 00:07:23 +01:00
|
|
|
n->constraints = NIL;
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
n->accessMethod = $10;
|
|
|
|
|
n->options = $11;
|
|
|
|
|
n->oncommit = $12;
|
|
|
|
|
n->tablespacename = $13;
|
2010-07-26 01:21:22 +02:00
|
|
|
n->if_not_exists = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2010-07-26 01:21:22 +02:00
|
|
|
}
|
|
|
|
|
| CREATE OptTemp TABLE IF_P NOT EXISTS qualified_name '('
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
OptTableElementList ')' OptInherit OptPartitionSpec table_access_method_clause
|
|
|
|
|
OptWith OnCommitOption OptTableSpace
|
2010-07-26 01:21:22 +02:00
|
|
|
{
|
|
|
|
|
CreateStmt *n = makeNode(CreateStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-12-13 18:34:26 +01:00
|
|
|
$7->relpersistence = $2;
|
2010-07-26 01:21:22 +02:00
|
|
|
n->relation = $7;
|
|
|
|
|
n->tableElts = $9;
|
|
|
|
|
n->inhRelations = $11;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
n->partspec = $12;
|
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
|
|
|
n->ofTypename = NULL;
|
2010-07-26 01:21:22 +02:00
|
|
|
n->constraints = NIL;
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
n->accessMethod = $13;
|
|
|
|
|
n->options = $14;
|
|
|
|
|
n->oncommit = $15;
|
|
|
|
|
n->tablespacename = $16;
|
2010-07-26 01:21:22 +02:00
|
|
|
n->if_not_exists = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2010-01-29 00:21:13 +01:00
|
|
|
| CREATE OptTemp TABLE qualified_name OF any_name
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
OptTypedTableElementList OptPartitionSpec table_access_method_clause
|
|
|
|
|
OptWith OnCommitOption OptTableSpace
|
2002-08-04 08:51:23 +02:00
|
|
|
{
|
|
|
|
|
CreateStmt *n = makeNode(CreateStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-12-13 18:34:26 +01:00
|
|
|
$4->relpersistence = $2;
|
2002-08-04 08:51:23 +02:00
|
|
|
n->relation = $4;
|
2010-01-29 00:21:13 +01:00
|
|
|
n->tableElts = $7;
|
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
|
|
|
n->inhRelations = NIL;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
n->partspec = $8;
|
2010-01-29 00:21:13 +01:00
|
|
|
n->ofTypename = makeTypeNameFromNameList($6);
|
|
|
|
|
n->ofTypename->location = @6;
|
2002-08-04 08:51:23 +02:00
|
|
|
n->constraints = NIL;
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
n->accessMethod = $9;
|
|
|
|
|
n->options = $10;
|
|
|
|
|
n->oncommit = $11;
|
|
|
|
|
n->tablespacename = $12;
|
2010-07-26 01:21:22 +02:00
|
|
|
n->if_not_exists = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2010-07-26 01:21:22 +02:00
|
|
|
}
|
|
|
|
|
| CREATE OptTemp TABLE IF_P NOT EXISTS qualified_name OF any_name
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
OptTypedTableElementList OptPartitionSpec table_access_method_clause
|
|
|
|
|
OptWith OnCommitOption OptTableSpace
|
2010-07-26 01:21:22 +02:00
|
|
|
{
|
|
|
|
|
CreateStmt *n = makeNode(CreateStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-12-13 18:34:26 +01:00
|
|
|
$7->relpersistence = $2;
|
2010-07-26 01:21:22 +02:00
|
|
|
n->relation = $7;
|
|
|
|
|
n->tableElts = $10;
|
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
|
|
|
n->inhRelations = NIL;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
n->partspec = $11;
|
2010-07-26 01:21:22 +02:00
|
|
|
n->ofTypename = makeTypeNameFromNameList($9);
|
|
|
|
|
n->ofTypename->location = @9;
|
|
|
|
|
n->constraints = NIL;
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
n->accessMethod = $12;
|
|
|
|
|
n->options = $13;
|
|
|
|
|
n->oncommit = $14;
|
|
|
|
|
n->tablespacename = $15;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
n->if_not_exists = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
}
|
|
|
|
|
| CREATE OptTemp TABLE qualified_name PARTITION OF qualified_name
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
OptTypedTableElementList PartitionBoundSpec OptPartitionSpec
|
|
|
|
|
table_access_method_clause OptWith OnCommitOption OptTableSpace
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
{
|
|
|
|
|
CreateStmt *n = makeNode(CreateStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
$4->relpersistence = $2;
|
|
|
|
|
n->relation = $4;
|
|
|
|
|
n->tableElts = $8;
|
|
|
|
|
n->inhRelations = list_make1($7);
|
Code review focused on new node types added by partitioning support.
Fix failure to check that we got a plain Const from const-simplification of
a coercion request. This is the cause of bug #14666 from Tian Bing: there
is an int4 to money cast, but it's only stable not immutable (because of
dependence on lc_monetary), resulting in a FuncExpr that the code was
miserably unequipped to deal with, or indeed even to notice that it was
failing to deal with. Add test cases around this coercion behavior.
In view of the above, sprinkle the code liberally with castNode() macros,
in hope of catching the next such bug a bit sooner. Also, change some
functions that were randomly declared to take Node* to take more specific
pointer types. And change some struct fields that were declared Node*
but could be given more specific types, allowing removal of assorted
explicit casts.
Place PARTITION_MAX_KEYS check a bit closer to the code it's protecting.
Likewise check only-one-key-for-list-partitioning restriction in a less
random place.
Avoid not-per-project-style usages like !strcmp(...).
Fix assorted failures to avoid scribbling on the input of parse
transformation. I'm not sure how necessary this is, but it's entirely
silly for these functions to be expending cycles to avoid that and not
getting it right.
Add guards against partitioning on system columns.
Put backend/nodes/ support code into an order that matches handling
of these node types elsewhere.
Annotate the fact that somebody added location fields to PartitionBoundSpec
and PartitionRangeDatum but forgot to handle them in
outfuncs.c/readfuncs.c. This is fairly harmless for production purposes
(since readfuncs.c would just substitute -1 anyway) but it's still bogus.
It's not worth forcing a post-beta1 initdb just to fix this, but if we
have another reason to force initdb before 10.0, we should go back and
clean this up.
Contrariwise, somebody added location fields to PartitionElem and
PartitionSpec but forgot to teach exprLocation() about them.
Consolidate duplicative code in transformPartitionBound().
Improve a couple of error messages.
Improve assorted commentary.
Re-pgindent the files touched by this patch; this affects a few comment
blocks that must have been added quite recently.
Report: https://postgr.es/m/20170524024550.29935.14396@wrigleys.postgresql.org
2017-05-29 05:20:28 +02:00
|
|
|
n->partbound = $9;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
n->partspec = $10;
|
|
|
|
|
n->ofTypename = NULL;
|
|
|
|
|
n->constraints = NIL;
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
n->accessMethod = $11;
|
|
|
|
|
n->options = $12;
|
|
|
|
|
n->oncommit = $13;
|
|
|
|
|
n->tablespacename = $14;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
n->if_not_exists = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
}
|
|
|
|
|
| CREATE OptTemp TABLE IF_P NOT EXISTS qualified_name PARTITION OF
|
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
|
|
|
qualified_name OptTypedTableElementList PartitionBoundSpec OptPartitionSpec
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
table_access_method_clause OptWith OnCommitOption OptTableSpace
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
{
|
|
|
|
|
CreateStmt *n = makeNode(CreateStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
$7->relpersistence = $2;
|
|
|
|
|
n->relation = $7;
|
|
|
|
|
n->tableElts = $11;
|
|
|
|
|
n->inhRelations = list_make1($10);
|
Code review focused on new node types added by partitioning support.
Fix failure to check that we got a plain Const from const-simplification of
a coercion request. This is the cause of bug #14666 from Tian Bing: there
is an int4 to money cast, but it's only stable not immutable (because of
dependence on lc_monetary), resulting in a FuncExpr that the code was
miserably unequipped to deal with, or indeed even to notice that it was
failing to deal with. Add test cases around this coercion behavior.
In view of the above, sprinkle the code liberally with castNode() macros,
in hope of catching the next such bug a bit sooner. Also, change some
functions that were randomly declared to take Node* to take more specific
pointer types. And change some struct fields that were declared Node*
but could be given more specific types, allowing removal of assorted
explicit casts.
Place PARTITION_MAX_KEYS check a bit closer to the code it's protecting.
Likewise check only-one-key-for-list-partitioning restriction in a less
random place.
Avoid not-per-project-style usages like !strcmp(...).
Fix assorted failures to avoid scribbling on the input of parse
transformation. I'm not sure how necessary this is, but it's entirely
silly for these functions to be expending cycles to avoid that and not
getting it right.
Add guards against partitioning on system columns.
Put backend/nodes/ support code into an order that matches handling
of these node types elsewhere.
Annotate the fact that somebody added location fields to PartitionBoundSpec
and PartitionRangeDatum but forgot to handle them in
outfuncs.c/readfuncs.c. This is fairly harmless for production purposes
(since readfuncs.c would just substitute -1 anyway) but it's still bogus.
It's not worth forcing a post-beta1 initdb just to fix this, but if we
have another reason to force initdb before 10.0, we should go back and
clean this up.
Contrariwise, somebody added location fields to PartitionElem and
PartitionSpec but forgot to teach exprLocation() about them.
Consolidate duplicative code in transformPartitionBound().
Improve a couple of error messages.
Improve assorted commentary.
Re-pgindent the files touched by this patch; this affects a few comment
blocks that must have been added quite recently.
Report: https://postgr.es/m/20170524024550.29935.14396@wrigleys.postgresql.org
2017-05-29 05:20:28 +02:00
|
|
|
n->partbound = $12;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
n->partspec = $13;
|
|
|
|
|
n->ofTypename = NULL;
|
|
|
|
|
n->constraints = NIL;
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
n->accessMethod = $14;
|
|
|
|
|
n->options = $15;
|
|
|
|
|
n->oncommit = $16;
|
|
|
|
|
n->tablespacename = $17;
|
2010-07-26 01:21:22 +02:00
|
|
|
n->if_not_exists = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-08-04 08:51:23 +02:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
2000-03-01 06:18:20 +01:00
|
|
|
/*
|
|
|
|
|
* Redundancy here is needed to avoid shift/reduce conflicts,
|
|
|
|
|
* since TEMP is not a reserved word. See also OptTempTableName.
|
2003-05-04 02:03:55 +02:00
|
|
|
*
|
2012-06-13 23:48:42 +02:00
|
|
|
* NOTE: we accept both GLOBAL and LOCAL options. They currently do nothing,
|
|
|
|
|
* but future versions might consider GLOBAL to request SQL-spec-compliant
|
|
|
|
|
* temp table behavior, so warn about that. Since we have no modules the
|
|
|
|
|
* LOCAL keyword is really meaningless; furthermore, some other products
|
|
|
|
|
* implement LOCAL as meaning the same as our default temp table behavior,
|
|
|
|
|
* so we'll probably continue to treat LOCAL as a noise word.
|
2000-03-01 06:18:20 +01:00
|
|
|
*/
|
2010-12-13 18:34:26 +01:00
|
|
|
OptTemp: TEMPORARY { $$ = RELPERSISTENCE_TEMP; }
|
|
|
|
|
| TEMP { $$ = RELPERSISTENCE_TEMP; }
|
2012-06-10 09:41:01 +02:00
|
|
|
| LOCAL TEMPORARY { $$ = RELPERSISTENCE_TEMP; }
|
|
|
|
|
| LOCAL TEMP { $$ = RELPERSISTENCE_TEMP; }
|
2012-06-13 23:48:42 +02:00
|
|
|
| GLOBAL TEMPORARY
|
|
|
|
|
{
|
|
|
|
|
ereport(WARNING,
|
|
|
|
|
(errmsg("GLOBAL is deprecated in temporary table creation"),
|
|
|
|
|
parser_errposition(@1)));
|
|
|
|
|
$$ = RELPERSISTENCE_TEMP;
|
|
|
|
|
}
|
|
|
|
|
| GLOBAL TEMP
|
|
|
|
|
{
|
|
|
|
|
ereport(WARNING,
|
|
|
|
|
(errmsg("GLOBAL is deprecated in temporary table creation"),
|
|
|
|
|
parser_errposition(@1)));
|
|
|
|
|
$$ = RELPERSISTENCE_TEMP;
|
|
|
|
|
}
|
2010-12-29 12:48:53 +01:00
|
|
|
| UNLOGGED { $$ = RELPERSISTENCE_UNLOGGED; }
|
2010-12-13 18:34:26 +01:00
|
|
|
| /*EMPTY*/ { $$ = RELPERSISTENCE_PERMANENT; }
|
1999-05-12 09:22:52 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
OptTableElementList:
|
2002-08-05 04:30:50 +02:00
|
|
|
TableElementList { $$ = $1; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
2010-01-29 00:21:13 +01:00
|
|
|
OptTypedTableElementList:
|
|
|
|
|
'(' TypedTableElementList ')' { $$ = $2; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
2002-08-05 04:30:50 +02:00
|
|
|
TableElementList:
|
2002-08-29 02:17:06 +02:00
|
|
|
TableElement
|
1998-04-08 08:39:01 +02:00
|
|
|
{
|
2004-05-31 01:40:41 +02:00
|
|
|
$$ = list_make1($1);
|
1998-04-08 08:39:01 +02:00
|
|
|
}
|
2002-08-29 02:17:06 +02:00
|
|
|
| TableElementList ',' TableElement
|
1998-04-08 08:39:01 +02:00
|
|
|
{
|
2002-08-29 02:17:06 +02:00
|
|
|
$$ = lappend($1, $3);
|
1998-04-08 08:39:01 +02:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2010-01-29 00:21:13 +01:00
|
|
|
TypedTableElementList:
|
|
|
|
|
TypedTableElement
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make1($1);
|
|
|
|
|
}
|
|
|
|
|
| TypedTableElementList ',' TypedTableElement
|
|
|
|
|
{
|
|
|
|
|
$$ = lappend($1, $3);
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2002-08-05 04:30:50 +02:00
|
|
|
TableElement:
|
2002-06-17 22:27:43 +02:00
|
|
|
columnDef { $$ = $1; }
|
2002-06-22 04:04:55 +02:00
|
|
|
| TableLikeClause { $$ = $1; }
|
1997-12-05 00:07:23 +01:00
|
|
|
| TableConstraint { $$ = $1; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2010-01-29 00:21:13 +01:00
|
|
|
TypedTableElement:
|
|
|
|
|
columnOptions { $$ = $1; }
|
|
|
|
|
| TableConstraint { $$ = $1; }
|
|
|
|
|
;
|
|
|
|
|
|
2022-07-13 12:21:45 +02:00
|
|
|
columnDef: ColId Typename opt_column_storage opt_column_compression create_generic_options ColQualList
|
1997-12-05 00:07:23 +01:00
|
|
|
{
|
|
|
|
|
ColumnDef *n = makeNode(ColumnDef);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
1997-12-05 00:07:23 +01:00
|
|
|
n->colname = $1;
|
2009-07-16 08:33:46 +02:00
|
|
|
n->typeName = $2;
|
2022-07-13 12:21:45 +02:00
|
|
|
n->storage_name = $3;
|
|
|
|
|
n->compression = $4;
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
n->inhcount = 0;
|
2002-09-22 21:42:52 +02:00
|
|
|
n->is_local = true;
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
n->is_not_null = false;
|
|
|
|
|
n->is_from_type = false;
|
|
|
|
|
n->storage = 0;
|
|
|
|
|
n->raw_default = NULL;
|
|
|
|
|
n->cooked_default = NULL;
|
|
|
|
|
n->collOid = InvalidOid;
|
2022-07-13 12:21:45 +02:00
|
|
|
n->fdwoptions = $5;
|
|
|
|
|
SplitColQualList($6, &n->constraints, &n->collClause,
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
yyscanner);
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
n->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-12-05 00:07:23 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2017-04-28 02:14:39 +02:00
|
|
|
columnOptions: ColId ColQualList
|
|
|
|
|
{
|
|
|
|
|
ColumnDef *n = makeNode(ColumnDef);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-04-28 02:14:39 +02:00
|
|
|
n->colname = $1;
|
|
|
|
|
n->typeName = NULL;
|
|
|
|
|
n->inhcount = 0;
|
|
|
|
|
n->is_local = true;
|
|
|
|
|
n->is_not_null = false;
|
|
|
|
|
n->is_from_type = false;
|
|
|
|
|
n->storage = 0;
|
|
|
|
|
n->raw_default = NULL;
|
|
|
|
|
n->cooked_default = NULL;
|
|
|
|
|
n->collOid = InvalidOid;
|
|
|
|
|
SplitColQualList($2, &n->constraints, &n->collClause,
|
|
|
|
|
yyscanner);
|
|
|
|
|
n->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-04-28 02:14:39 +02:00
|
|
|
}
|
|
|
|
|
| ColId WITH OPTIONS ColQualList
|
2010-01-29 00:21:13 +01:00
|
|
|
{
|
|
|
|
|
ColumnDef *n = makeNode(ColumnDef);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-01-29 00:21:13 +01:00
|
|
|
n->colname = $1;
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
n->typeName = NULL;
|
|
|
|
|
n->inhcount = 0;
|
2010-01-29 00:21:13 +01:00
|
|
|
n->is_local = true;
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
n->is_not_null = false;
|
|
|
|
|
n->is_from_type = false;
|
|
|
|
|
n->storage = 0;
|
|
|
|
|
n->raw_default = NULL;
|
|
|
|
|
n->cooked_default = NULL;
|
|
|
|
|
n->collOid = InvalidOid;
|
|
|
|
|
SplitColQualList($4, &n->constraints, &n->collClause,
|
|
|
|
|
yyscanner);
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
n->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2010-01-29 00:21:13 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2021-05-27 19:24:24 +02:00
|
|
|
column_compression:
|
|
|
|
|
COMPRESSION ColId { $$ = $2; }
|
|
|
|
|
| COMPRESSION DEFAULT { $$ = pstrdup("default"); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_column_compression:
|
|
|
|
|
column_compression { $$ = $1; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
|
|
|
|
;
|
Allow configurable LZ4 TOAST compression.
There is now a per-column COMPRESSION option which can be set to pglz
(the default, and the only option in up until now) or lz4. Or, if you
like, you can set the new default_toast_compression GUC to lz4, and
then that will be the default for new table columns for which no value
is specified. We don't have lz4 support in the PostgreSQL code, so
to use lz4 compression, PostgreSQL must be built --with-lz4.
In general, TOAST compression means compression of individual column
values, not the whole tuple, and those values can either be compressed
inline within the tuple or compressed and then stored externally in
the TOAST table, so those properties also apply to this feature.
Prior to this commit, a TOAST pointer has two unused bits as part of
the va_extsize field, and a compessed datum has two unused bits as
part of the va_rawsize field. These bits are unused because the length
of a varlena is limited to 1GB; we now use them to indicate the
compression type that was used. This means we only have bit space for
2 more built-in compresison types, but we could work around that
problem, if necessary, by introducing a new vartag_external value for
any further types we end up wanting to add. Hopefully, it won't be
too important to offer a wide selection of algorithms here, since
each one we add not only takes more coding but also adds a build
dependency for every packager. Nevertheless, it seems worth doing
at least this much, because LZ4 gets better compression than PGLZ
with less CPU usage.
It's possible for LZ4-compressed datums to leak into composite type
values stored on disk, just as it is for PGLZ. It's also possible for
LZ4-compressed attributes to be copied into a different table via SQL
commands such as CREATE TABLE AS or INSERT .. SELECT. It would be
expensive to force such values to be decompressed, so PostgreSQL has
never done so. For the same reasons, we also don't force recompression
of already-compressed values even if the target table prefers a
different compression method than was used for the source data. These
architectural decisions are perhaps arguable but revisiting them is
well beyond the scope of what seemed possible to do as part of this
project. However, it's relatively cheap to recompress as part of
VACUUM FULL or CLUSTER, so this commit adjusts those commands to do
so, if the configured compression method of the table happens not to
match what was used for some column value stored therein.
Dilip Kumar. The original patches on which this work was based were
written by Ildus Kurbangaliev, and those were patches were based on
even earlier work by Nikita Glukhov, but the design has since changed
very substantially, since allow a potentially large number of
compression methods that could be added and dropped on a running
system proved too problematic given some of the architectural issues
mentioned above; the choice of which specific compression method to
add first is now different; and a lot of the code has been heavily
refactored. More recently, Justin Przyby helped quite a bit with
testing and reviewing and this version also includes some code
contributions from him. Other design input and review from Tomas
Vondra, Álvaro Herrera, Andres Freund, Oleg Bartunov, Alexander
Korotkov, and me.
Discussion: http://postgr.es/m/20170907194236.4cefce96%40wp.localdomain
Discussion: http://postgr.es/m/CAFiTN-uUpX3ck%3DK0mLEk-G_kUQY%3DSNOTeqdaNRR9FMdQrHKebw%40mail.gmail.com
2021-03-19 20:10:38 +01:00
|
|
|
|
2022-07-13 12:21:45 +02:00
|
|
|
column_storage:
|
|
|
|
|
STORAGE ColId { $$ = $2; }
|
2022-11-11 00:20:49 +01:00
|
|
|
| STORAGE DEFAULT { $$ = pstrdup("default"); }
|
2022-07-13 12:21:45 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_column_storage:
|
|
|
|
|
column_storage { $$ = $1; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
ColQualList:
|
|
|
|
|
ColQualList ColConstraint { $$ = lappend($1, $2); }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
2000-02-15 04:26:38 +01:00
|
|
|
;
|
|
|
|
|
|
2000-03-01 06:18:20 +01:00
|
|
|
ColConstraint:
|
2002-06-17 22:27:43 +02:00
|
|
|
CONSTRAINT name ColConstraintElem
|
1997-12-05 00:07:23 +01:00
|
|
|
{
|
2017-02-21 17:33:07 +01:00
|
|
|
Constraint *n = castNode(Constraint, $3);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-07-30 04:45:38 +02:00
|
|
|
n->conname = $2;
|
|
|
|
|
n->location = @1;
|
|
|
|
|
$$ = (Node *) n;
|
1997-12-05 00:07:23 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| ColConstraintElem { $$ = $1; }
|
|
|
|
|
| ConstraintAttr { $$ = $1; }
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
| COLLATE any_name
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* Note: the CollateClause is momentarily included in
|
|
|
|
|
* the list built by ColQualList, but we split it out
|
|
|
|
|
* again in SplitColQualList.
|
|
|
|
|
*/
|
|
|
|
|
CollateClause *n = makeNode(CollateClause);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
n->arg = NULL;
|
2011-03-11 22:27:51 +01:00
|
|
|
n->collname = $2;
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
n->location = @1;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2000-02-15 04:26:38 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/* DEFAULT NULL is already the default for Postgres.
|
1999-10-04 01:55:40 +02:00
|
|
|
* But define it here and carry it forward into the system
|
1998-09-16 16:29:35 +02:00
|
|
|
* to make it explicit.
|
|
|
|
|
* - thomas 1998-09-13
|
1999-11-20 22:39:36 +01:00
|
|
|
*
|
2013-04-20 17:04:41 +02:00
|
|
|
* WITH NULL and NULL are not SQL-standard syntax elements,
|
1999-02-23 08:42:41 +01:00
|
|
|
* so leave them out. Use DEFAULT NULL to explicitly indicate
|
|
|
|
|
* that a column may have that value. WITH NULL leads to
|
|
|
|
|
* shift/reduce conflicts with WITH TIME ZONE anyway.
|
|
|
|
|
* - thomas 1999-01-08
|
2000-03-01 06:18:20 +01:00
|
|
|
*
|
|
|
|
|
* DEFAULT expression must be b_expr not a_expr to prevent shift/reduce
|
|
|
|
|
* conflict on NOT (since NOT might start a subsequent NOT NULL constraint,
|
|
|
|
|
* or be part of a_expr NOT LIKE or similar constructs).
|
1998-09-13 06:19:33 +02:00
|
|
|
*/
|
2000-03-01 06:18:20 +01:00
|
|
|
ColConstraintElem:
|
2002-06-17 22:27:43 +02:00
|
|
|
NOT NULL_P
|
2000-02-15 04:26:38 +01:00
|
|
|
{
|
2000-03-01 06:18:20 +01:00
|
|
|
Constraint *n = makeNode(Constraint);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2000-03-01 06:18:20 +01:00
|
|
|
n->contype = CONSTR_NOTNULL;
|
2009-07-30 04:45:38 +02:00
|
|
|
n->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-03-01 06:18:20 +01:00
|
|
|
}
|
|
|
|
|
| NULL_P
|
|
|
|
|
{
|
|
|
|
|
Constraint *n = makeNode(Constraint);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2000-03-01 06:18:20 +01:00
|
|
|
n->contype = CONSTR_NULL;
|
2009-07-30 04:45:38 +02:00
|
|
|
n->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-02-15 04:26:38 +01:00
|
|
|
}
|
2022-02-03 11:29:54 +01:00
|
|
|
| UNIQUE opt_unique_null_treatment opt_definition OptConsTableSpace
|
1998-09-16 16:29:35 +02:00
|
|
|
{
|
|
|
|
|
Constraint *n = makeNode(Constraint);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2000-02-15 04:26:38 +01:00
|
|
|
n->contype = CONSTR_UNIQUE;
|
2009-07-30 04:45:38 +02:00
|
|
|
n->location = @1;
|
2022-02-03 11:29:54 +01:00
|
|
|
n->nulls_not_distinct = !$2;
|
1998-09-16 16:29:35 +02:00
|
|
|
n->keys = NULL;
|
2022-02-03 11:29:54 +01:00
|
|
|
n->options = $3;
|
2011-01-25 21:42:03 +01:00
|
|
|
n->indexname = NULL;
|
2022-02-03 11:29:54 +01:00
|
|
|
n->indexspace = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1998-09-16 16:29:35 +02:00
|
|
|
}
|
2006-07-02 04:23:23 +02:00
|
|
|
| PRIMARY KEY opt_definition OptConsTableSpace
|
1997-12-05 00:07:23 +01:00
|
|
|
{
|
2000-03-01 06:18:20 +01:00
|
|
|
Constraint *n = makeNode(Constraint);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2000-03-01 06:18:20 +01:00
|
|
|
n->contype = CONSTR_PRIMARY;
|
2009-07-30 04:45:38 +02:00
|
|
|
n->location = @1;
|
2000-03-01 06:18:20 +01:00
|
|
|
n->keys = NULL;
|
2006-07-02 04:23:23 +02:00
|
|
|
n->options = $3;
|
2011-01-25 21:42:03 +01:00
|
|
|
n->indexname = NULL;
|
2006-07-02 04:23:23 +02:00
|
|
|
n->indexspace = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-12-05 00:07:23 +01:00
|
|
|
}
|
2012-07-24 21:49:54 +02:00
|
|
|
| CHECK '(' a_expr ')' opt_no_inherit
|
1997-12-05 00:07:23 +01:00
|
|
|
{
|
|
|
|
|
Constraint *n = makeNode(Constraint);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2000-02-15 04:26:38 +01:00
|
|
|
n->contype = CONSTR_CHECK;
|
2009-07-30 04:45:38 +02:00
|
|
|
n->location = @1;
|
2012-07-24 21:49:54 +02:00
|
|
|
n->is_no_inherit = $5;
|
|
|
|
|
n->raw_expr = $3;
|
1999-10-04 01:55:40 +02:00
|
|
|
n->cooked_expr = NULL;
|
2015-12-16 13:43:56 +01:00
|
|
|
n->skip_validation = false;
|
|
|
|
|
n->initially_valid = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-12-05 00:07:23 +01:00
|
|
|
}
|
2000-03-01 06:18:20 +01:00
|
|
|
| DEFAULT b_expr
|
|
|
|
|
{
|
|
|
|
|
Constraint *n = makeNode(Constraint);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2000-03-01 06:18:20 +01:00
|
|
|
n->contype = CONSTR_DEFAULT;
|
2009-07-30 04:45:38 +02:00
|
|
|
n->location = @1;
|
2007-10-29 20:40:40 +01:00
|
|
|
n->raw_expr = $2;
|
2000-03-01 06:18:20 +01:00
|
|
|
n->cooked_expr = NULL;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-03-01 06:18:20 +01:00
|
|
|
}
|
2017-04-06 14:33:16 +02:00
|
|
|
| GENERATED generated_when AS IDENTITY_P OptParenthesizedSeqOptList
|
|
|
|
|
{
|
|
|
|
|
Constraint *n = makeNode(Constraint);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-04-06 14:33:16 +02:00
|
|
|
n->contype = CONSTR_IDENTITY;
|
|
|
|
|
n->generated_when = $2;
|
|
|
|
|
n->options = $5;
|
|
|
|
|
n->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-04-06 14:33:16 +02:00
|
|
|
}
|
2019-03-30 08:13:09 +01:00
|
|
|
| GENERATED generated_when AS '(' a_expr ')' STORED
|
|
|
|
|
{
|
|
|
|
|
Constraint *n = makeNode(Constraint);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2019-03-30 08:13:09 +01:00
|
|
|
n->contype = CONSTR_GENERATED;
|
|
|
|
|
n->generated_when = $2;
|
|
|
|
|
n->raw_expr = $5;
|
|
|
|
|
n->cooked_expr = NULL;
|
|
|
|
|
n->location = @1;
|
2019-04-01 10:46:37 +02:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Can't do this in the grammar because of shift/reduce
|
|
|
|
|
* conflicts. (IDENTITY allows both ALWAYS and BY
|
|
|
|
|
* DEFAULT, but generated columns only allow ALWAYS.) We
|
|
|
|
|
* can also give a more useful error message and location.
|
|
|
|
|
*/
|
|
|
|
|
if ($2 != ATTRIBUTE_IDENTITY_ALWAYS)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("for a generated column, GENERATED ALWAYS must be specified"),
|
|
|
|
|
parser_errposition(@2)));
|
|
|
|
|
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2019-03-30 08:13:09 +01:00
|
|
|
}
|
2002-06-17 07:40:32 +02:00
|
|
|
| REFERENCES qualified_name opt_column_list key_match key_actions
|
1997-12-05 00:07:23 +01:00
|
|
|
{
|
2009-07-30 04:45:38 +02:00
|
|
|
Constraint *n = makeNode(Constraint);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-07-30 04:45:38 +02:00
|
|
|
n->contype = CONSTR_FOREIGN;
|
|
|
|
|
n->location = @1;
|
2021-07-14 23:54:56 +02:00
|
|
|
n->pktable = $2;
|
|
|
|
|
n->fk_attrs = NIL;
|
|
|
|
|
n->pk_attrs = $3;
|
|
|
|
|
n->fk_matchtype = $4;
|
2021-12-08 11:09:44 +01:00
|
|
|
n->fk_upd_action = ($5)->updateAction->action;
|
|
|
|
|
n->fk_del_action = ($5)->deleteAction->action;
|
|
|
|
|
n->fk_del_set_cols = ($5)->deleteAction->cols;
|
2021-07-14 23:54:56 +02:00
|
|
|
n->skip_validation = false;
|
|
|
|
|
n->initially_valid = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-12-05 00:07:23 +01:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1997-08-20 03:12:38 +02:00
|
|
|
|
2022-02-03 11:29:54 +01:00
|
|
|
opt_unique_null_treatment:
|
|
|
|
|
NULLS_P DISTINCT { $$ = true; }
|
|
|
|
|
| NULLS_P NOT DISTINCT { $$ = false; }
|
|
|
|
|
| /*EMPTY*/ { $$ = true; }
|
|
|
|
|
;
|
|
|
|
|
|
2017-04-06 14:33:16 +02:00
|
|
|
generated_when:
|
|
|
|
|
ALWAYS { $$ = ATTRIBUTE_IDENTITY_ALWAYS; }
|
|
|
|
|
| BY DEFAULT { $$ = ATTRIBUTE_IDENTITY_BY_DEFAULT; }
|
|
|
|
|
;
|
|
|
|
|
|
2000-03-01 06:18:20 +01:00
|
|
|
/*
|
|
|
|
|
* ConstraintAttr represents constraint attributes, which we parse as if
|
|
|
|
|
* they were independent constraint clauses, in order to avoid shift/reduce
|
|
|
|
|
* conflicts (since NOT might start either an independent NOT NULL clause
|
2007-06-24 00:12:52 +02:00
|
|
|
* or an attribute). parse_utilcmd.c is responsible for attaching the
|
|
|
|
|
* attribute information to the preceding "real" constraint node, and for
|
|
|
|
|
* complaining if attribute clauses appear in the wrong place or wrong
|
|
|
|
|
* combinations.
|
2000-03-01 06:18:20 +01:00
|
|
|
*
|
|
|
|
|
* See also ConstraintAttributeSpec, which can be used in places where
|
2012-07-24 21:49:54 +02:00
|
|
|
* there is no parsing conflict. (Note: currently, NOT VALID and NO INHERIT
|
|
|
|
|
* are allowed clauses in ConstraintAttributeSpec, but not here. Someday we
|
|
|
|
|
* might need to allow them here too, but for the moment it doesn't seem
|
|
|
|
|
* useful in the statements that use ConstraintAttr.)
|
2000-03-01 06:18:20 +01:00
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
ConstraintAttr:
|
|
|
|
|
DEFERRABLE
|
2000-02-19 09:25:49 +01:00
|
|
|
{
|
|
|
|
|
Constraint *n = makeNode(Constraint);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2000-03-01 06:18:20 +01:00
|
|
|
n->contype = CONSTR_ATTR_DEFERRABLE;
|
2009-07-30 04:45:38 +02:00
|
|
|
n->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-02-19 09:25:49 +01:00
|
|
|
}
|
2000-03-01 06:18:20 +01:00
|
|
|
| NOT DEFERRABLE
|
2000-02-19 09:25:49 +01:00
|
|
|
{
|
|
|
|
|
Constraint *n = makeNode(Constraint);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2000-03-01 06:18:20 +01:00
|
|
|
n->contype = CONSTR_ATTR_NOT_DEFERRABLE;
|
2009-07-30 04:45:38 +02:00
|
|
|
n->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-03-01 06:18:20 +01:00
|
|
|
}
|
|
|
|
|
| INITIALLY DEFERRED
|
|
|
|
|
{
|
|
|
|
|
Constraint *n = makeNode(Constraint);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2000-03-01 06:18:20 +01:00
|
|
|
n->contype = CONSTR_ATTR_DEFERRED;
|
2009-07-30 04:45:38 +02:00
|
|
|
n->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-03-01 06:18:20 +01:00
|
|
|
}
|
|
|
|
|
| INITIALLY IMMEDIATE
|
|
|
|
|
{
|
|
|
|
|
Constraint *n = makeNode(Constraint);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2000-03-01 06:18:20 +01:00
|
|
|
n->contype = CONSTR_ATTR_IMMEDIATE;
|
2009-07-30 04:45:38 +02:00
|
|
|
n->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-02-19 09:25:49 +01:00
|
|
|
}
|
2000-03-01 06:18:20 +01:00
|
|
|
;
|
|
|
|
|
|
2000-02-19 09:25:49 +01:00
|
|
|
|
2003-06-25 05:40:19 +02:00
|
|
|
TableLikeClause:
|
2006-06-27 05:43:20 +02:00
|
|
|
LIKE qualified_name TableLikeOptionList
|
2002-06-22 04:04:55 +02:00
|
|
|
{
|
2012-01-07 13:58:13 +01:00
|
|
|
TableLikeClause *n = makeNode(TableLikeClause);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-06-25 05:40:19 +02:00
|
|
|
n->relation = $2;
|
2006-06-27 05:43:20 +02:00
|
|
|
n->options = $3;
|
2020-12-01 20:02:27 +01:00
|
|
|
n->relationOid = InvalidOid;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-06-22 04:04:55 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2006-06-27 05:43:20 +02:00
|
|
|
TableLikeOptionList:
|
2009-10-12 21:49:24 +02:00
|
|
|
TableLikeOptionList INCLUDING TableLikeOption { $$ = $1 | $3; }
|
|
|
|
|
| TableLikeOptionList EXCLUDING TableLikeOption { $$ = $1 & ~$3; }
|
|
|
|
|
| /* EMPTY */ { $$ = 0; }
|
2006-06-27 05:43:20 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
TableLikeOption:
|
Clone extended stats in CREATE TABLE (LIKE INCLUDING ALL)
The LIKE INCLUDING ALL clause to CREATE TABLE intuitively indicates
cloning of extended statistics on the source table, but it failed to do
so. Patch it up so that it does. Also include an INCLUDING STATISTICS
option to the LIKE clause, so that the behavior can be requested
individually, or excluded individually.
While at it, reorder the INCLUDING options, both in code and in docs, in
alphabetical order which makes more sense than feature-implementation
order that was previously used.
Backpatch this to Postgres 10, where extended statistics were
introduced, because this is seen as an oversight in a fresh feature
which is better to get consistent from the get-go instead of changing
only in pg11.
In pg11, comments on statistics objects are cloned too. In pg10 they
are not, because I (Álvaro) was too coward to change the parse node as
required to support it. Also, in pg10 I chose not to renumber the
parser symbols for the various INCLUDING options in LIKE, for the same
reason. Any corresponding user-visible changes (docs) are backpatched,
though.
Reported-by: Stephen Froehlich
Author: David Rowley
Reviewed-by: Álvaro Herrera, Tomas Vondra
Discussion: https://postgr.es/m/CY1PR0601MB1927315B45667A1B679D0FD5E5EF0@CY1PR0601MB1927.namprd06.prod.outlook.com
2018-03-05 23:37:19 +01:00
|
|
|
COMMENTS { $$ = CREATE_TABLE_LIKE_COMMENTS; }
|
2021-04-23 12:10:24 +02:00
|
|
|
| COMPRESSION { $$ = CREATE_TABLE_LIKE_COMPRESSION; }
|
2009-10-12 21:49:24 +02:00
|
|
|
| CONSTRAINTS { $$ = CREATE_TABLE_LIKE_CONSTRAINTS; }
|
Clone extended stats in CREATE TABLE (LIKE INCLUDING ALL)
The LIKE INCLUDING ALL clause to CREATE TABLE intuitively indicates
cloning of extended statistics on the source table, but it failed to do
so. Patch it up so that it does. Also include an INCLUDING STATISTICS
option to the LIKE clause, so that the behavior can be requested
individually, or excluded individually.
While at it, reorder the INCLUDING options, both in code and in docs, in
alphabetical order which makes more sense than feature-implementation
order that was previously used.
Backpatch this to Postgres 10, where extended statistics were
introduced, because this is seen as an oversight in a fresh feature
which is better to get consistent from the get-go instead of changing
only in pg11.
In pg11, comments on statistics objects are cloned too. In pg10 they
are not, because I (Álvaro) was too coward to change the parse node as
required to support it. Also, in pg10 I chose not to renumber the
parser symbols for the various INCLUDING options in LIKE, for the same
reason. Any corresponding user-visible changes (docs) are backpatched,
though.
Reported-by: Stephen Froehlich
Author: David Rowley
Reviewed-by: Álvaro Herrera, Tomas Vondra
Discussion: https://postgr.es/m/CY1PR0601MB1927315B45667A1B679D0FD5E5EF0@CY1PR0601MB1927.namprd06.prod.outlook.com
2018-03-05 23:37:19 +01:00
|
|
|
| DEFAULTS { $$ = CREATE_TABLE_LIKE_DEFAULTS; }
|
2017-04-06 14:33:16 +02:00
|
|
|
| IDENTITY_P { $$ = CREATE_TABLE_LIKE_IDENTITY; }
|
2019-03-30 08:13:09 +01:00
|
|
|
| GENERATED { $$ = CREATE_TABLE_LIKE_GENERATED; }
|
2009-10-12 21:49:24 +02:00
|
|
|
| INDEXES { $$ = CREATE_TABLE_LIKE_INDEXES; }
|
Clone extended stats in CREATE TABLE (LIKE INCLUDING ALL)
The LIKE INCLUDING ALL clause to CREATE TABLE intuitively indicates
cloning of extended statistics on the source table, but it failed to do
so. Patch it up so that it does. Also include an INCLUDING STATISTICS
option to the LIKE clause, so that the behavior can be requested
individually, or excluded individually.
While at it, reorder the INCLUDING options, both in code and in docs, in
alphabetical order which makes more sense than feature-implementation
order that was previously used.
Backpatch this to Postgres 10, where extended statistics were
introduced, because this is seen as an oversight in a fresh feature
which is better to get consistent from the get-go instead of changing
only in pg11.
In pg11, comments on statistics objects are cloned too. In pg10 they
are not, because I (Álvaro) was too coward to change the parse node as
required to support it. Also, in pg10 I chose not to renumber the
parser symbols for the various INCLUDING options in LIKE, for the same
reason. Any corresponding user-visible changes (docs) are backpatched,
though.
Reported-by: Stephen Froehlich
Author: David Rowley
Reviewed-by: Álvaro Herrera, Tomas Vondra
Discussion: https://postgr.es/m/CY1PR0601MB1927315B45667A1B679D0FD5E5EF0@CY1PR0601MB1927.namprd06.prod.outlook.com
2018-03-05 23:37:19 +01:00
|
|
|
| STATISTICS { $$ = CREATE_TABLE_LIKE_STATISTICS; }
|
2009-10-12 21:49:24 +02:00
|
|
|
| STORAGE { $$ = CREATE_TABLE_LIKE_STORAGE; }
|
|
|
|
|
| ALL { $$ = CREATE_TABLE_LIKE_ALL; }
|
2003-06-25 05:40:19 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-22 04:04:55 +02:00
|
|
|
|
1997-12-05 00:07:23 +01:00
|
|
|
/* ConstraintElem specifies constraint syntax which is not embedded into
|
2002-06-17 22:27:43 +02:00
|
|
|
* a column definition. ColConstraintElem specifies the embedded form.
|
1997-12-05 00:07:23 +01:00
|
|
|
* - thomas 1997-12-03
|
|
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
TableConstraint:
|
|
|
|
|
CONSTRAINT name ConstraintElem
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2017-02-21 17:33:07 +01:00
|
|
|
Constraint *n = castNode(Constraint, $3);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-07-30 04:45:38 +02:00
|
|
|
n->conname = $2;
|
|
|
|
|
n->location = @1;
|
|
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| ConstraintElem { $$ = $1; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
ConstraintElem:
|
2012-07-24 21:49:54 +02:00
|
|
|
CHECK '(' a_expr ')' ConstraintAttributeSpec
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
1997-12-05 00:07:23 +01:00
|
|
|
Constraint *n = makeNode(Constraint);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
1997-12-05 00:07:23 +01:00
|
|
|
n->contype = CONSTR_CHECK;
|
2009-07-30 04:45:38 +02:00
|
|
|
n->location = @1;
|
2012-07-24 21:49:54 +02:00
|
|
|
n->raw_expr = $3;
|
1999-10-04 01:55:40 +02:00
|
|
|
n->cooked_expr = NULL;
|
2012-07-24 21:49:54 +02:00
|
|
|
processCASbits($5, @5, "CHECK",
|
2011-06-02 00:43:50 +02:00
|
|
|
NULL, NULL, &n->skip_validation,
|
2012-07-24 21:49:54 +02:00
|
|
|
&n->is_no_inherit, yyscanner);
|
2011-06-02 00:43:50 +02:00
|
|
|
n->initially_valid = !n->skip_validation;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2022-02-03 11:29:54 +01:00
|
|
|
| UNIQUE opt_unique_null_treatment '(' columnList ')' opt_c_include opt_definition OptConsTableSpace
|
2009-07-29 22:56:21 +02:00
|
|
|
ConstraintAttributeSpec
|
1997-12-05 00:07:23 +01:00
|
|
|
{
|
|
|
|
|
Constraint *n = makeNode(Constraint);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
1997-12-05 00:07:23 +01:00
|
|
|
n->contype = CONSTR_UNIQUE;
|
2009-07-30 04:45:38 +02:00
|
|
|
n->location = @1;
|
2022-02-03 11:29:54 +01:00
|
|
|
n->nulls_not_distinct = !$2;
|
|
|
|
|
n->keys = $4;
|
|
|
|
|
n->including = $6;
|
|
|
|
|
n->options = $7;
|
2011-01-25 21:42:03 +01:00
|
|
|
n->indexname = NULL;
|
2022-02-03 11:29:54 +01:00
|
|
|
n->indexspace = $8;
|
|
|
|
|
processCASbits($9, @9, "UNIQUE",
|
2011-06-16 01:05:11 +02:00
|
|
|
&n->deferrable, &n->initdeferred, NULL,
|
2012-07-24 21:49:54 +02:00
|
|
|
NULL, yyscanner);
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-12-05 00:07:23 +01:00
|
|
|
}
|
2011-01-25 21:42:03 +01:00
|
|
|
| UNIQUE ExistingIndex ConstraintAttributeSpec
|
|
|
|
|
{
|
|
|
|
|
Constraint *n = makeNode(Constraint);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-01-25 21:42:03 +01:00
|
|
|
n->contype = CONSTR_UNIQUE;
|
|
|
|
|
n->location = @1;
|
|
|
|
|
n->keys = NIL;
|
2018-04-07 22:00:39 +02:00
|
|
|
n->including = NIL;
|
2011-01-25 21:42:03 +01:00
|
|
|
n->options = NIL;
|
|
|
|
|
n->indexname = $2;
|
|
|
|
|
n->indexspace = NULL;
|
2011-06-16 01:05:11 +02:00
|
|
|
processCASbits($3, @3, "UNIQUE",
|
|
|
|
|
&n->deferrable, &n->initdeferred, NULL,
|
2012-07-24 21:49:54 +02:00
|
|
|
NULL, yyscanner);
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-01-25 21:42:03 +01:00
|
|
|
}
|
2018-04-07 22:00:39 +02:00
|
|
|
| PRIMARY KEY '(' columnList ')' opt_c_include opt_definition OptConsTableSpace
|
2009-07-29 22:56:21 +02:00
|
|
|
ConstraintAttributeSpec
|
1997-12-05 00:07:23 +01:00
|
|
|
{
|
2000-03-01 06:18:20 +01:00
|
|
|
Constraint *n = makeNode(Constraint);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2000-03-01 06:18:20 +01:00
|
|
|
n->contype = CONSTR_PRIMARY;
|
2009-07-30 04:45:38 +02:00
|
|
|
n->location = @1;
|
2000-03-01 06:18:20 +01:00
|
|
|
n->keys = $4;
|
2018-04-07 22:00:39 +02:00
|
|
|
n->including = $6;
|
|
|
|
|
n->options = $7;
|
2011-01-25 21:42:03 +01:00
|
|
|
n->indexname = NULL;
|
2018-04-07 22:00:39 +02:00
|
|
|
n->indexspace = $8;
|
|
|
|
|
processCASbits($9, @9, "PRIMARY KEY",
|
2011-06-16 01:05:11 +02:00
|
|
|
&n->deferrable, &n->initdeferred, NULL,
|
2012-07-24 21:49:54 +02:00
|
|
|
NULL, yyscanner);
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-12-05 00:07:23 +01:00
|
|
|
}
|
2011-01-25 21:42:03 +01:00
|
|
|
| PRIMARY KEY ExistingIndex ConstraintAttributeSpec
|
|
|
|
|
{
|
|
|
|
|
Constraint *n = makeNode(Constraint);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-01-25 21:42:03 +01:00
|
|
|
n->contype = CONSTR_PRIMARY;
|
|
|
|
|
n->location = @1;
|
|
|
|
|
n->keys = NIL;
|
2018-04-07 22:00:39 +02:00
|
|
|
n->including = NIL;
|
2011-01-25 21:42:03 +01:00
|
|
|
n->options = NIL;
|
|
|
|
|
n->indexname = $3;
|
|
|
|
|
n->indexspace = NULL;
|
2011-06-16 01:05:11 +02:00
|
|
|
processCASbits($4, @4, "PRIMARY KEY",
|
|
|
|
|
&n->deferrable, &n->initdeferred, NULL,
|
2012-07-24 21:49:54 +02:00
|
|
|
NULL, yyscanner);
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-01-25 21:42:03 +01:00
|
|
|
}
|
2009-12-07 06:22:23 +01:00
|
|
|
| EXCLUDE access_method_clause '(' ExclusionConstraintList ')'
|
2021-03-25 10:17:52 +01:00
|
|
|
opt_c_include opt_definition OptConsTableSpace OptWhereClause
|
2009-12-07 06:22:23 +01:00
|
|
|
ConstraintAttributeSpec
|
|
|
|
|
{
|
|
|
|
|
Constraint *n = makeNode(Constraint);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-12-07 06:22:23 +01:00
|
|
|
n->contype = CONSTR_EXCLUSION;
|
|
|
|
|
n->location = @1;
|
2021-07-14 23:54:56 +02:00
|
|
|
n->access_method = $2;
|
|
|
|
|
n->exclusions = $4;
|
|
|
|
|
n->including = $6;
|
|
|
|
|
n->options = $7;
|
|
|
|
|
n->indexname = NULL;
|
|
|
|
|
n->indexspace = $8;
|
|
|
|
|
n->where_clause = $9;
|
2018-04-07 22:00:39 +02:00
|
|
|
processCASbits($10, @10, "EXCLUDE",
|
2011-06-16 01:05:11 +02:00
|
|
|
&n->deferrable, &n->initdeferred, NULL,
|
2012-07-24 21:49:54 +02:00
|
|
|
NULL, yyscanner);
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2009-12-07 06:22:23 +01:00
|
|
|
}
|
2002-06-18 19:56:41 +02:00
|
|
|
| FOREIGN KEY '(' columnList ')' REFERENCES qualified_name
|
2002-07-12 20:43:19 +02:00
|
|
|
opt_column_list key_match key_actions ConstraintAttributeSpec
|
1999-12-06 19:02:47 +01:00
|
|
|
{
|
2009-07-30 04:45:38 +02:00
|
|
|
Constraint *n = makeNode(Constraint);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-07-30 04:45:38 +02:00
|
|
|
n->contype = CONSTR_FOREIGN;
|
|
|
|
|
n->location = @1;
|
2021-07-14 23:54:56 +02:00
|
|
|
n->pktable = $7;
|
|
|
|
|
n->fk_attrs = $4;
|
|
|
|
|
n->pk_attrs = $8;
|
|
|
|
|
n->fk_matchtype = $9;
|
2021-12-08 11:09:44 +01:00
|
|
|
n->fk_upd_action = ($10)->updateAction->action;
|
|
|
|
|
n->fk_del_action = ($10)->deleteAction->action;
|
|
|
|
|
n->fk_del_set_cols = ($10)->deleteAction->cols;
|
2011-06-16 01:05:11 +02:00
|
|
|
processCASbits($11, @11, "FOREIGN KEY",
|
|
|
|
|
&n->deferrable, &n->initdeferred,
|
2012-07-24 21:49:54 +02:00
|
|
|
&n->skip_validation, NULL,
|
2011-06-16 01:05:11 +02:00
|
|
|
yyscanner);
|
|
|
|
|
n->initially_valid = !n->skip_validation;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1998-04-08 08:39:01 +02:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
opt_no_inherit: NO INHERIT { $$ = true; }
|
|
|
|
|
| /* EMPTY */ { $$ = false; }
|
2012-04-21 04:46:20 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
opt_column_list:
|
|
|
|
|
'(' columnList ')' { $$ = $2; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
2002-03-21 17:02:16 +01:00
|
|
|
;
|
|
|
|
|
|
2002-06-18 02:28:11 +02:00
|
|
|
columnList:
|
2004-05-31 01:40:41 +02:00
|
|
|
columnElem { $$ = list_make1($1); }
|
2002-06-18 02:28:11 +02:00
|
|
|
| columnList ',' columnElem { $$ = lappend($1, $3); }
|
2002-03-21 17:02:16 +01:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
columnElem: ColId
|
2002-03-21 17:02:16 +01:00
|
|
|
{
|
2002-08-19 17:08:47 +02:00
|
|
|
$$ = (Node *) makeString($1);
|
2002-03-21 17:02:16 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2018-04-07 22:00:39 +02:00
|
|
|
opt_c_include: INCLUDE '(' columnList ')' { $$ = $3; }
|
|
|
|
|
| /* EMPTY */ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-22 04:04:55 +02:00
|
|
|
key_match: MATCH FULL
|
|
|
|
|
{
|
2002-07-12 20:43:19 +02:00
|
|
|
$$ = FKCONSTR_MATCH_FULL;
|
2002-06-22 04:04:55 +02:00
|
|
|
}
|
|
|
|
|
| MATCH PARTIAL
|
|
|
|
|
{
|
2003-07-19 22:20:53 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
2008-09-01 22:42:46 +02:00
|
|
|
errmsg("MATCH PARTIAL not yet implemented"),
|
2009-07-13 04:02:20 +02:00
|
|
|
parser_errposition(@1)));
|
2002-07-12 20:43:19 +02:00
|
|
|
$$ = FKCONSTR_MATCH_PARTIAL;
|
2002-06-22 04:04:55 +02:00
|
|
|
}
|
|
|
|
|
| MATCH SIMPLE
|
|
|
|
|
{
|
2012-06-18 02:16:07 +02:00
|
|
|
$$ = FKCONSTR_MATCH_SIMPLE;
|
2002-06-22 04:04:55 +02:00
|
|
|
}
|
|
|
|
|
| /*EMPTY*/
|
|
|
|
|
{
|
2012-06-18 02:16:07 +02:00
|
|
|
$$ = FKCONSTR_MATCH_SIMPLE;
|
2002-06-22 04:04:55 +02:00
|
|
|
}
|
1997-10-25 07:56:41 +02:00
|
|
|
;
|
|
|
|
|
|
2009-12-07 06:22:23 +01:00
|
|
|
ExclusionConstraintList:
|
|
|
|
|
ExclusionConstraintElem { $$ = list_make1($1); }
|
|
|
|
|
| ExclusionConstraintList ',' ExclusionConstraintElem
|
|
|
|
|
{ $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
ExclusionConstraintElem: index_elem WITH any_operator
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make2($1, $3);
|
|
|
|
|
}
|
|
|
|
|
/* allow OPERATOR() decoration for the benefit of ruleutils.c */
|
|
|
|
|
| index_elem WITH OPERATOR '(' any_operator ')'
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make2($1, $5);
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2021-03-25 10:06:32 +01:00
|
|
|
OptWhereClause:
|
2009-12-07 06:22:23 +01:00
|
|
|
WHERE '(' a_expr ')' { $$ = $3; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
key_actions:
|
2002-07-12 20:43:19 +02:00
|
|
|
key_update
|
2021-12-08 11:09:44 +01:00
|
|
|
{
|
|
|
|
|
KeyActions *n = palloc(sizeof(KeyActions));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-12-08 11:09:44 +01:00
|
|
|
n->updateAction = $1;
|
|
|
|
|
n->deleteAction = palloc(sizeof(KeyAction));
|
|
|
|
|
n->deleteAction->action = FKCONSTR_ACTION_NOACTION;
|
|
|
|
|
n->deleteAction->cols = NIL;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2002-07-12 20:43:19 +02:00
|
|
|
| key_delete
|
2021-12-08 11:09:44 +01:00
|
|
|
{
|
|
|
|
|
KeyActions *n = palloc(sizeof(KeyActions));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-12-08 11:09:44 +01:00
|
|
|
n->updateAction = palloc(sizeof(KeyAction));
|
|
|
|
|
n->updateAction->action = FKCONSTR_ACTION_NOACTION;
|
|
|
|
|
n->updateAction->cols = NIL;
|
|
|
|
|
n->deleteAction = $1;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2002-07-12 20:43:19 +02:00
|
|
|
| key_update key_delete
|
2021-12-08 11:09:44 +01:00
|
|
|
{
|
|
|
|
|
KeyActions *n = palloc(sizeof(KeyActions));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-12-08 11:09:44 +01:00
|
|
|
n->updateAction = $1;
|
|
|
|
|
n->deleteAction = $2;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2002-07-12 20:43:19 +02:00
|
|
|
| key_delete key_update
|
2021-12-08 11:09:44 +01:00
|
|
|
{
|
|
|
|
|
KeyActions *n = palloc(sizeof(KeyActions));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-12-08 11:09:44 +01:00
|
|
|
n->updateAction = $2;
|
|
|
|
|
n->deleteAction = $1;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2002-07-12 20:43:19 +02:00
|
|
|
| /*EMPTY*/
|
2021-12-08 11:09:44 +01:00
|
|
|
{
|
|
|
|
|
KeyActions *n = palloc(sizeof(KeyActions));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-12-08 11:09:44 +01:00
|
|
|
n->updateAction = palloc(sizeof(KeyAction));
|
|
|
|
|
n->updateAction->action = FKCONSTR_ACTION_NOACTION;
|
|
|
|
|
n->updateAction->cols = NIL;
|
|
|
|
|
n->deleteAction = palloc(sizeof(KeyAction));
|
|
|
|
|
n->deleteAction->action = FKCONSTR_ACTION_NOACTION;
|
|
|
|
|
n->deleteAction->cols = NIL;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
1997-10-25 07:56:41 +02:00
|
|
|
;
|
|
|
|
|
|
2021-12-08 11:09:44 +01:00
|
|
|
key_update: ON UPDATE key_action
|
|
|
|
|
{
|
|
|
|
|
if (($3)->cols)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
|
errmsg("a column list with %s is only supported for ON DELETE actions",
|
|
|
|
|
($3)->action == FKCONSTR_ACTION_SETNULL ? "SET NULL" : "SET DEFAULT"),
|
|
|
|
|
parser_errposition(@1)));
|
|
|
|
|
$$ = $3;
|
|
|
|
|
}
|
2000-02-19 09:25:49 +01:00
|
|
|
;
|
|
|
|
|
|
2021-12-08 11:09:44 +01:00
|
|
|
key_delete: ON DELETE_P key_action
|
|
|
|
|
{
|
|
|
|
|
$$ = $3;
|
|
|
|
|
}
|
1997-10-25 07:56:41 +02:00
|
|
|
;
|
|
|
|
|
|
2002-07-12 20:43:19 +02:00
|
|
|
key_action:
|
2021-12-08 11:09:44 +01:00
|
|
|
NO ACTION
|
|
|
|
|
{
|
|
|
|
|
KeyAction *n = palloc(sizeof(KeyAction));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-12-08 11:09:44 +01:00
|
|
|
n->action = FKCONSTR_ACTION_NOACTION;
|
|
|
|
|
n->cols = NIL;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| RESTRICT
|
|
|
|
|
{
|
|
|
|
|
KeyAction *n = palloc(sizeof(KeyAction));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-12-08 11:09:44 +01:00
|
|
|
n->action = FKCONSTR_ACTION_RESTRICT;
|
|
|
|
|
n->cols = NIL;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| CASCADE
|
|
|
|
|
{
|
|
|
|
|
KeyAction *n = palloc(sizeof(KeyAction));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-12-08 11:09:44 +01:00
|
|
|
n->action = FKCONSTR_ACTION_CASCADE;
|
|
|
|
|
n->cols = NIL;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| SET NULL_P opt_column_list
|
|
|
|
|
{
|
|
|
|
|
KeyAction *n = palloc(sizeof(KeyAction));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-12-08 11:09:44 +01:00
|
|
|
n->action = FKCONSTR_ACTION_SETNULL;
|
|
|
|
|
n->cols = $3;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| SET DEFAULT opt_column_list
|
|
|
|
|
{
|
|
|
|
|
KeyAction *n = palloc(sizeof(KeyAction));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-12-08 11:09:44 +01:00
|
|
|
n->action = FKCONSTR_ACTION_SETDEFAULT;
|
|
|
|
|
n->cols = $3;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
1997-10-25 07:56:41 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
OptInherit: INHERITS '(' qualified_name_list ')' { $$ = $3; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
1997-12-05 00:07:23 +01:00
|
|
|
;
|
|
|
|
|
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
/* Optional partition key specification */
|
|
|
|
|
OptPartitionSpec: PartitionSpec { $$ = $1; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
2020-05-20 02:09:59 +02:00
|
|
|
PartitionSpec: PARTITION BY ColId '(' part_params ')'
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
{
|
|
|
|
|
PartitionSpec *n = makeNode(PartitionSpec);
|
|
|
|
|
|
2022-11-03 16:25:54 +01:00
|
|
|
n->strategy = parsePartitionStrategy($3);
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
n->partParams = $5;
|
|
|
|
|
n->location = @1;
|
|
|
|
|
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
part_params: part_elem { $$ = list_make1($1); }
|
|
|
|
|
| part_params ',' part_elem { $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
2022-07-22 12:57:01 +02:00
|
|
|
part_elem: ColId opt_collate opt_qualified_name
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
{
|
|
|
|
|
PartitionElem *n = makeNode(PartitionElem);
|
|
|
|
|
|
|
|
|
|
n->name = $1;
|
|
|
|
|
n->expr = NULL;
|
|
|
|
|
n->collation = $2;
|
|
|
|
|
n->opclass = $3;
|
|
|
|
|
n->location = @1;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2022-07-22 12:57:01 +02:00
|
|
|
| func_expr_windowless opt_collate opt_qualified_name
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
{
|
|
|
|
|
PartitionElem *n = makeNode(PartitionElem);
|
|
|
|
|
|
|
|
|
|
n->name = NULL;
|
|
|
|
|
n->expr = $1;
|
|
|
|
|
n->collation = $2;
|
|
|
|
|
n->opclass = $3;
|
|
|
|
|
n->location = @1;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2022-07-22 12:57:01 +02:00
|
|
|
| '(' a_expr ')' opt_collate opt_qualified_name
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
{
|
|
|
|
|
PartitionElem *n = makeNode(PartitionElem);
|
|
|
|
|
|
|
|
|
|
n->name = NULL;
|
|
|
|
|
n->expr = $2;
|
|
|
|
|
n->collation = $4;
|
|
|
|
|
n->opclass = $5;
|
|
|
|
|
n->location = @1;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
;
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
|
|
|
|
|
table_access_method_clause:
|
2020-06-10 22:58:46 +02:00
|
|
|
USING name { $$ = $2; }
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
/* WITHOUT OIDS is legacy only */
|
2006-07-02 04:23:23 +02:00
|
|
|
OptWith:
|
2009-02-02 20:31:40 +01:00
|
|
|
WITH reloptions { $$ = $2; }
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
| WITHOUT OIDS { $$ = NIL; }
|
2006-07-04 00:45:41 +02:00
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
2001-08-10 20:57:42 +02:00
|
|
|
;
|
|
|
|
|
|
2002-11-11 23:19:25 +01:00
|
|
|
OnCommitOption: ON COMMIT DROP { $$ = ONCOMMIT_DROP; }
|
|
|
|
|
| ON COMMIT DELETE_P ROWS { $$ = ONCOMMIT_DELETE_ROWS; }
|
|
|
|
|
| ON COMMIT PRESERVE ROWS { $$ = ONCOMMIT_PRESERVE_ROWS; }
|
|
|
|
|
| /*EMPTY*/ { $$ = ONCOMMIT_NOOP; }
|
|
|
|
|
;
|
|
|
|
|
|
2004-06-18 08:14:31 +02:00
|
|
|
OptTableSpace: TABLESPACE name { $$ = $2; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
2004-08-02 06:28:29 +02:00
|
|
|
OptConsTableSpace: USING INDEX TABLESPACE name { $$ = $4; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
2020-06-10 22:58:46 +02:00
|
|
|
ExistingIndex: USING INDEX name { $$ = $3; }
|
2011-01-25 21:42:03 +01:00
|
|
|
;
|
|
|
|
|
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* QUERY :
|
2022-07-21 20:23:13 +02:00
|
|
|
* CREATE STATISTICS [[IF NOT EXISTS] stats_name] [(stat types)]
|
Change CREATE STATISTICS syntax
Previously, we had the WITH clause in the middle of the command, where
you'd specify both generic options as well as statistic types. Few
people liked this, so this commit changes it to remove the WITH keyword
from that clause and makes it accept statistic types only. (We
currently don't have any generic options, but if we invent in the
future, we will gain a new WITH clause, probably at the end of the
command).
Also, the column list is now specified without parens, which makes the
whole command look more similar to a SELECT command. This change will
let us expand the command to supporting expressions (not just columns
names) as well as multiple tables and their join conditions.
Tom added lots of code comments and fixed some parts of the CREATE
STATISTICS reference page, too; more changes in this area are
forthcoming. He also fixed a potential problem in the alter_generic
regression test, reducing verbosity on a cascaded drop to avoid
dependency on message ordering, as we do in other tests.
Tom also closed a security bug: we documented that table ownership was
required in order to create a statistics object on it, but didn't
actually implement it.
Implement tab-completion for statistics objects. This can stand some
more improvement.
Authors: Alvaro Herrera, with lots of cleanup by Tom Lane
Discussion: https://postgr.es/m/20170420212426.ltvgyhnefvhixm6i@alvherre.pgsql
2017-05-12 19:59:23 +02:00
|
|
|
* ON expression-list FROM from_list
|
|
|
|
|
*
|
|
|
|
|
* Note: the expectation here is that the clauses after ON are a subset of
|
|
|
|
|
* SELECT syntax, allowing for expressions and joined tables, and probably
|
|
|
|
|
* someday a WHERE clause. Much less than that is currently implemented,
|
|
|
|
|
* but the grammar accepts it and then we'll throw FEATURE_NOT_SUPPORTED
|
|
|
|
|
* errors as necessary at execution.
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
*
|
2022-07-22 12:57:01 +02:00
|
|
|
* Statistics name is optional unless IF NOT EXISTS is specified.
|
|
|
|
|
*
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
Change CREATE STATISTICS syntax
Previously, we had the WITH clause in the middle of the command, where
you'd specify both generic options as well as statistic types. Few
people liked this, so this commit changes it to remove the WITH keyword
from that clause and makes it accept statistic types only. (We
currently don't have any generic options, but if we invent in the
future, we will gain a new WITH clause, probably at the end of the
command).
Also, the column list is now specified without parens, which makes the
whole command look more similar to a SELECT command. This change will
let us expand the command to supporting expressions (not just columns
names) as well as multiple tables and their join conditions.
Tom added lots of code comments and fixed some parts of the CREATE
STATISTICS reference page, too; more changes in this area are
forthcoming. He also fixed a potential problem in the alter_generic
regression test, reducing verbosity on a cascaded drop to avoid
dependency on message ordering, as we do in other tests.
Tom also closed a security bug: we documented that table ownership was
required in order to create a statistics object on it, but didn't
actually implement it.
Implement tab-completion for statistics objects. This can stand some
more improvement.
Authors: Alvaro Herrera, with lots of cleanup by Tom Lane
Discussion: https://postgr.es/m/20170420212426.ltvgyhnefvhixm6i@alvherre.pgsql
2017-05-12 19:59:23 +02:00
|
|
|
CreateStatsStmt:
|
2022-07-22 12:57:01 +02:00
|
|
|
CREATE STATISTICS opt_qualified_name
|
Extended statistics on expressions
Allow defining extended statistics on expressions, not just just on
simple column references. With this commit, expressions are supported
by all existing extended statistics kinds, improving the same types of
estimates. A simple example may look like this:
CREATE TABLE t (a int);
CREATE STATISTICS s ON mod(a,10), mod(a,20) FROM t;
ANALYZE t;
The collected statistics are useful e.g. to estimate queries with those
expressions in WHERE or GROUP BY clauses:
SELECT * FROM t WHERE mod(a,10) = 0 AND mod(a,20) = 0;
SELECT 1 FROM t GROUP BY mod(a,10), mod(a,20);
This introduces new internal statistics kind 'e' (expressions) which is
built automatically when the statistics object definition includes any
expressions. This represents single-expression statistics, as if there
was an expression index (but without the index maintenance overhead).
The statistics is stored in pg_statistics_ext_data as an array of
composite types, which is possible thanks to 79f6a942bd.
CREATE STATISTICS allows building statistics on a single expression, in
which case in which case it's not possible to specify statistics kinds.
A new system view pg_stats_ext_exprs can be used to display expression
statistics, similarly to pg_stats and pg_stats_ext views.
ALTER TABLE ... ALTER COLUMN ... TYPE now treats indexes the same way it
treats indexes, i.e. it drops and recreates the statistics. This means
all statistics are reset, and we no longer try to preserve at least the
functional dependencies. This should not be a major issue in practice,
as the functional dependencies actually rely on per-column statistics,
which were always reset anyway.
Author: Tomas Vondra
Reviewed-by: Justin Pryzby, Dean Rasheed, Zhihong Yu
Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com
2021-03-26 23:22:01 +01:00
|
|
|
opt_name_list ON stats_params FROM from_list
|
Change CREATE STATISTICS syntax
Previously, we had the WITH clause in the middle of the command, where
you'd specify both generic options as well as statistic types. Few
people liked this, so this commit changes it to remove the WITH keyword
from that clause and makes it accept statistic types only. (We
currently don't have any generic options, but if we invent in the
future, we will gain a new WITH clause, probably at the end of the
command).
Also, the column list is now specified without parens, which makes the
whole command look more similar to a SELECT command. This change will
let us expand the command to supporting expressions (not just columns
names) as well as multiple tables and their join conditions.
Tom added lots of code comments and fixed some parts of the CREATE
STATISTICS reference page, too; more changes in this area are
forthcoming. He also fixed a potential problem in the alter_generic
regression test, reducing verbosity on a cascaded drop to avoid
dependency on message ordering, as we do in other tests.
Tom also closed a security bug: we documented that table ownership was
required in order to create a statistics object on it, but didn't
actually implement it.
Implement tab-completion for statistics objects. This can stand some
more improvement.
Authors: Alvaro Herrera, with lots of cleanup by Tom Lane
Discussion: https://postgr.es/m/20170420212426.ltvgyhnefvhixm6i@alvherre.pgsql
2017-05-12 19:59:23 +02:00
|
|
|
{
|
|
|
|
|
CreateStatsStmt *n = makeNode(CreateStatsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-06-22 19:17:08 +02:00
|
|
|
n->defnames = $3;
|
|
|
|
|
n->stat_types = $4;
|
|
|
|
|
n->exprs = $6;
|
|
|
|
|
n->relations = $8;
|
Clone extended stats in CREATE TABLE (LIKE INCLUDING ALL)
The LIKE INCLUDING ALL clause to CREATE TABLE intuitively indicates
cloning of extended statistics on the source table, but it failed to do
so. Patch it up so that it does. Also include an INCLUDING STATISTICS
option to the LIKE clause, so that the behavior can be requested
individually, or excluded individually.
While at it, reorder the INCLUDING options, both in code and in docs, in
alphabetical order which makes more sense than feature-implementation
order that was previously used.
Backpatch this to Postgres 10, where extended statistics were
introduced, because this is seen as an oversight in a fresh feature
which is better to get consistent from the get-go instead of changing
only in pg11.
In pg11, comments on statistics objects are cloned too. In pg10 they
are not, because I (Álvaro) was too coward to change the parse node as
required to support it. Also, in pg10 I chose not to renumber the
parser symbols for the various INCLUDING options in LIKE, for the same
reason. Any corresponding user-visible changes (docs) are backpatched,
though.
Reported-by: Stephen Froehlich
Author: David Rowley
Reviewed-by: Álvaro Herrera, Tomas Vondra
Discussion: https://postgr.es/m/CY1PR0601MB1927315B45667A1B679D0FD5E5EF0@CY1PR0601MB1927.namprd06.prod.outlook.com
2018-03-05 23:37:19 +01:00
|
|
|
n->stxcomment = NULL;
|
2017-06-22 19:17:08 +02:00
|
|
|
n->if_not_exists = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-06-22 19:17:08 +02:00
|
|
|
}
|
|
|
|
|
| CREATE STATISTICS IF_P NOT EXISTS any_name
|
Extended statistics on expressions
Allow defining extended statistics on expressions, not just just on
simple column references. With this commit, expressions are supported
by all existing extended statistics kinds, improving the same types of
estimates. A simple example may look like this:
CREATE TABLE t (a int);
CREATE STATISTICS s ON mod(a,10), mod(a,20) FROM t;
ANALYZE t;
The collected statistics are useful e.g. to estimate queries with those
expressions in WHERE or GROUP BY clauses:
SELECT * FROM t WHERE mod(a,10) = 0 AND mod(a,20) = 0;
SELECT 1 FROM t GROUP BY mod(a,10), mod(a,20);
This introduces new internal statistics kind 'e' (expressions) which is
built automatically when the statistics object definition includes any
expressions. This represents single-expression statistics, as if there
was an expression index (but without the index maintenance overhead).
The statistics is stored in pg_statistics_ext_data as an array of
composite types, which is possible thanks to 79f6a942bd.
CREATE STATISTICS allows building statistics on a single expression, in
which case in which case it's not possible to specify statistics kinds.
A new system view pg_stats_ext_exprs can be used to display expression
statistics, similarly to pg_stats and pg_stats_ext views.
ALTER TABLE ... ALTER COLUMN ... TYPE now treats indexes the same way it
treats indexes, i.e. it drops and recreates the statistics. This means
all statistics are reset, and we no longer try to preserve at least the
functional dependencies. This should not be a major issue in practice,
as the functional dependencies actually rely on per-column statistics,
which were always reset anyway.
Author: Tomas Vondra
Reviewed-by: Justin Pryzby, Dean Rasheed, Zhihong Yu
Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com
2021-03-26 23:22:01 +01:00
|
|
|
opt_name_list ON stats_params FROM from_list
|
2017-06-22 19:17:08 +02:00
|
|
|
{
|
|
|
|
|
CreateStatsStmt *n = makeNode(CreateStatsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-06-22 19:17:08 +02:00
|
|
|
n->defnames = $6;
|
|
|
|
|
n->stat_types = $7;
|
|
|
|
|
n->exprs = $9;
|
|
|
|
|
n->relations = $11;
|
Clone extended stats in CREATE TABLE (LIKE INCLUDING ALL)
The LIKE INCLUDING ALL clause to CREATE TABLE intuitively indicates
cloning of extended statistics on the source table, but it failed to do
so. Patch it up so that it does. Also include an INCLUDING STATISTICS
option to the LIKE clause, so that the behavior can be requested
individually, or excluded individually.
While at it, reorder the INCLUDING options, both in code and in docs, in
alphabetical order which makes more sense than feature-implementation
order that was previously used.
Backpatch this to Postgres 10, where extended statistics were
introduced, because this is seen as an oversight in a fresh feature
which is better to get consistent from the get-go instead of changing
only in pg11.
In pg11, comments on statistics objects are cloned too. In pg10 they
are not, because I (Álvaro) was too coward to change the parse node as
required to support it. Also, in pg10 I chose not to renumber the
parser symbols for the various INCLUDING options in LIKE, for the same
reason. Any corresponding user-visible changes (docs) are backpatched,
though.
Reported-by: Stephen Froehlich
Author: David Rowley
Reviewed-by: Álvaro Herrera, Tomas Vondra
Discussion: https://postgr.es/m/CY1PR0601MB1927315B45667A1B679D0FD5E5EF0@CY1PR0601MB1927.namprd06.prod.outlook.com
2018-03-05 23:37:19 +01:00
|
|
|
n->stxcomment = NULL;
|
2017-06-22 19:17:08 +02:00
|
|
|
n->if_not_exists = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Change CREATE STATISTICS syntax
Previously, we had the WITH clause in the middle of the command, where
you'd specify both generic options as well as statistic types. Few
people liked this, so this commit changes it to remove the WITH keyword
from that clause and makes it accept statistic types only. (We
currently don't have any generic options, but if we invent in the
future, we will gain a new WITH clause, probably at the end of the
command).
Also, the column list is now specified without parens, which makes the
whole command look more similar to a SELECT command. This change will
let us expand the command to supporting expressions (not just columns
names) as well as multiple tables and their join conditions.
Tom added lots of code comments and fixed some parts of the CREATE
STATISTICS reference page, too; more changes in this area are
forthcoming. He also fixed a potential problem in the alter_generic
regression test, reducing verbosity on a cascaded drop to avoid
dependency on message ordering, as we do in other tests.
Tom also closed a security bug: we documented that table ownership was
required in order to create a statistics object on it, but didn't
actually implement it.
Implement tab-completion for statistics objects. This can stand some
more improvement.
Authors: Alvaro Herrera, with lots of cleanup by Tom Lane
Discussion: https://postgr.es/m/20170420212426.ltvgyhnefvhixm6i@alvherre.pgsql
2017-05-12 19:59:23 +02:00
|
|
|
}
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
;
|
2002-11-11 23:19:25 +01:00
|
|
|
|
Extended statistics on expressions
Allow defining extended statistics on expressions, not just just on
simple column references. With this commit, expressions are supported
by all existing extended statistics kinds, improving the same types of
estimates. A simple example may look like this:
CREATE TABLE t (a int);
CREATE STATISTICS s ON mod(a,10), mod(a,20) FROM t;
ANALYZE t;
The collected statistics are useful e.g. to estimate queries with those
expressions in WHERE or GROUP BY clauses:
SELECT * FROM t WHERE mod(a,10) = 0 AND mod(a,20) = 0;
SELECT 1 FROM t GROUP BY mod(a,10), mod(a,20);
This introduces new internal statistics kind 'e' (expressions) which is
built automatically when the statistics object definition includes any
expressions. This represents single-expression statistics, as if there
was an expression index (but without the index maintenance overhead).
The statistics is stored in pg_statistics_ext_data as an array of
composite types, which is possible thanks to 79f6a942bd.
CREATE STATISTICS allows building statistics on a single expression, in
which case in which case it's not possible to specify statistics kinds.
A new system view pg_stats_ext_exprs can be used to display expression
statistics, similarly to pg_stats and pg_stats_ext views.
ALTER TABLE ... ALTER COLUMN ... TYPE now treats indexes the same way it
treats indexes, i.e. it drops and recreates the statistics. This means
all statistics are reset, and we no longer try to preserve at least the
functional dependencies. This should not be a major issue in practice,
as the functional dependencies actually rely on per-column statistics,
which were always reset anyway.
Author: Tomas Vondra
Reviewed-by: Justin Pryzby, Dean Rasheed, Zhihong Yu
Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com
2021-03-26 23:22:01 +01:00
|
|
|
/*
|
|
|
|
|
* Statistics attributes can be either simple column references, or arbitrary
|
|
|
|
|
* expressions in parens. For compatibility with index attributes permitted
|
|
|
|
|
* in CREATE INDEX, we allow an expression that's just a function call to be
|
|
|
|
|
* written without parens.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
stats_params: stats_param { $$ = list_make1($1); }
|
|
|
|
|
| stats_params ',' stats_param { $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
stats_param: ColId
|
|
|
|
|
{
|
|
|
|
|
$$ = makeNode(StatsElem);
|
|
|
|
|
$$->name = $1;
|
|
|
|
|
$$->expr = NULL;
|
|
|
|
|
}
|
|
|
|
|
| func_expr_windowless
|
|
|
|
|
{
|
|
|
|
|
$$ = makeNode(StatsElem);
|
|
|
|
|
$$->name = NULL;
|
|
|
|
|
$$->expr = $1;
|
|
|
|
|
}
|
|
|
|
|
| '(' a_expr ')'
|
|
|
|
|
{
|
|
|
|
|
$$ = makeNode(StatsElem);
|
|
|
|
|
$$->name = NULL;
|
|
|
|
|
$$->expr = $2;
|
|
|
|
|
}
|
|
|
|
|
;
|
Allow setting statistics target for extended statistics
When building statistics, we need to decide how many rows to sample and
how accurate the resulting statistics should be. Until now, it was not
possible to explicitly define statistics target for extended statistics
objects, the value was always computed from the per-attribute targets
with a fallback to the system-wide default statistics target.
That's a bit inconvenient, as it ties together the statistics target set
for per-column and extended statistics. In some cases it may be useful
to require larger sample / higher accuracy for extended statics (or the
other way around), but with this approach that's not possible.
So this commit introduces a new command, allowing to specify statistics
target for individual extended statistics objects, overriding the value
derived from per-attribute targets (and the system default).
ALTER STATISTICS stat_name SET STATISTICS target_value;
When determining statistics target for an extended statistics object we
first look at this explicitly set value. When this value is -1, we fall
back to the old formula, looking at the per-attribute targets first and
then the system default. This means the behavior is backwards compatible
with older PostgreSQL releases.
Author: Tomas Vondra
Discussion: https://postgr.es/m/20190618213357.vli3i23vpkset2xd@development
Reviewed-by: Kirk Jamison, Dean Rasheed
2019-09-10 20:09:27 +02:00
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* QUERY :
|
|
|
|
|
* ALTER STATISTICS [IF EXISTS] stats_name
|
|
|
|
|
* SET STATISTICS <SignedIconst>
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
AlterStatsStmt:
|
|
|
|
|
ALTER STATISTICS any_name SET STATISTICS SignedIconst
|
|
|
|
|
{
|
|
|
|
|
AlterStatsStmt *n = makeNode(AlterStatsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Allow setting statistics target for extended statistics
When building statistics, we need to decide how many rows to sample and
how accurate the resulting statistics should be. Until now, it was not
possible to explicitly define statistics target for extended statistics
objects, the value was always computed from the per-attribute targets
with a fallback to the system-wide default statistics target.
That's a bit inconvenient, as it ties together the statistics target set
for per-column and extended statistics. In some cases it may be useful
to require larger sample / higher accuracy for extended statics (or the
other way around), but with this approach that's not possible.
So this commit introduces a new command, allowing to specify statistics
target for individual extended statistics objects, overriding the value
derived from per-attribute targets (and the system default).
ALTER STATISTICS stat_name SET STATISTICS target_value;
When determining statistics target for an extended statistics object we
first look at this explicitly set value. When this value is -1, we fall
back to the old formula, looking at the per-attribute targets first and
then the system default. This means the behavior is backwards compatible
with older PostgreSQL releases.
Author: Tomas Vondra
Discussion: https://postgr.es/m/20190618213357.vli3i23vpkset2xd@development
Reviewed-by: Kirk Jamison, Dean Rasheed
2019-09-10 20:09:27 +02:00
|
|
|
n->defnames = $3;
|
|
|
|
|
n->missing_ok = false;
|
|
|
|
|
n->stxstattarget = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Allow setting statistics target for extended statistics
When building statistics, we need to decide how many rows to sample and
how accurate the resulting statistics should be. Until now, it was not
possible to explicitly define statistics target for extended statistics
objects, the value was always computed from the per-attribute targets
with a fallback to the system-wide default statistics target.
That's a bit inconvenient, as it ties together the statistics target set
for per-column and extended statistics. In some cases it may be useful
to require larger sample / higher accuracy for extended statics (or the
other way around), but with this approach that's not possible.
So this commit introduces a new command, allowing to specify statistics
target for individual extended statistics objects, overriding the value
derived from per-attribute targets (and the system default).
ALTER STATISTICS stat_name SET STATISTICS target_value;
When determining statistics target for an extended statistics object we
first look at this explicitly set value. When this value is -1, we fall
back to the old formula, looking at the per-attribute targets first and
then the system default. This means the behavior is backwards compatible
with older PostgreSQL releases.
Author: Tomas Vondra
Discussion: https://postgr.es/m/20190618213357.vli3i23vpkset2xd@development
Reviewed-by: Kirk Jamison, Dean Rasheed
2019-09-10 20:09:27 +02:00
|
|
|
}
|
|
|
|
|
| ALTER STATISTICS IF_P EXISTS any_name SET STATISTICS SignedIconst
|
|
|
|
|
{
|
|
|
|
|
AlterStatsStmt *n = makeNode(AlterStatsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Allow setting statistics target for extended statistics
When building statistics, we need to decide how many rows to sample and
how accurate the resulting statistics should be. Until now, it was not
possible to explicitly define statistics target for extended statistics
objects, the value was always computed from the per-attribute targets
with a fallback to the system-wide default statistics target.
That's a bit inconvenient, as it ties together the statistics target set
for per-column and extended statistics. In some cases it may be useful
to require larger sample / higher accuracy for extended statics (or the
other way around), but with this approach that's not possible.
So this commit introduces a new command, allowing to specify statistics
target for individual extended statistics objects, overriding the value
derived from per-attribute targets (and the system default).
ALTER STATISTICS stat_name SET STATISTICS target_value;
When determining statistics target for an extended statistics object we
first look at this explicitly set value. When this value is -1, we fall
back to the old formula, looking at the per-attribute targets first and
then the system default. This means the behavior is backwards compatible
with older PostgreSQL releases.
Author: Tomas Vondra
Discussion: https://postgr.es/m/20190618213357.vli3i23vpkset2xd@development
Reviewed-by: Kirk Jamison, Dean Rasheed
2019-09-10 20:09:27 +02:00
|
|
|
n->defnames = $5;
|
|
|
|
|
n->missing_ok = true;
|
|
|
|
|
n->stxstattarget = $8;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Allow setting statistics target for extended statistics
When building statistics, we need to decide how many rows to sample and
how accurate the resulting statistics should be. Until now, it was not
possible to explicitly define statistics target for extended statistics
objects, the value was always computed from the per-attribute targets
with a fallback to the system-wide default statistics target.
That's a bit inconvenient, as it ties together the statistics target set
for per-column and extended statistics. In some cases it may be useful
to require larger sample / higher accuracy for extended statics (or the
other way around), but with this approach that's not possible.
So this commit introduces a new command, allowing to specify statistics
target for individual extended statistics objects, overriding the value
derived from per-attribute targets (and the system default).
ALTER STATISTICS stat_name SET STATISTICS target_value;
When determining statistics target for an extended statistics object we
first look at this explicitly set value. When this value is -1, we fall
back to the old formula, looking at the per-attribute targets first and
then the system default. This means the behavior is backwards compatible
with older PostgreSQL releases.
Author: Tomas Vondra
Discussion: https://postgr.es/m/20190618213357.vli3i23vpkset2xd@development
Reviewed-by: Kirk Jamison, Dean Rasheed
2019-09-10 20:09:27 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
2012-03-20 02:37:19 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* QUERY :
|
|
|
|
|
* CREATE TABLE relname AS SelectStmt [ WITH [NO] DATA ]
|
|
|
|
|
*
|
|
|
|
|
*
|
|
|
|
|
* Note: SELECT ... INTO is a now-deprecated alternative for this.
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
1999-11-15 03:00:15 +01:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
CreateAsStmt:
|
2008-10-28 15:09:45 +01:00
|
|
|
CREATE OptTemp TABLE create_as_target AS SelectStmt opt_with_data
|
1997-12-23 20:47:32 +01:00
|
|
|
{
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
2012-03-20 02:37:19 +01:00
|
|
|
CreateTableAsStmt *ctas = makeNode(CreateTableAsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
2012-03-20 02:37:19 +01:00
|
|
|
ctas->query = $6;
|
|
|
|
|
ctas->into = $4;
|
2020-07-11 06:32:28 +02:00
|
|
|
ctas->objtype = OBJECT_TABLE;
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
2012-03-20 02:37:19 +01:00
|
|
|
ctas->is_select_into = false;
|
2014-12-13 19:56:09 +01:00
|
|
|
ctas->if_not_exists = false;
|
2011-11-25 05:21:06 +01:00
|
|
|
/* cram additional flags into the IntoClause */
|
|
|
|
|
$4->rel->relpersistence = $2;
|
|
|
|
|
$4->skipData = !($7);
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
2012-03-20 02:37:19 +01:00
|
|
|
$$ = (Node *) ctas;
|
2007-02-20 18:32:18 +01:00
|
|
|
}
|
2014-12-13 19:56:09 +01:00
|
|
|
| CREATE OptTemp TABLE IF_P NOT EXISTS create_as_target AS SelectStmt opt_with_data
|
|
|
|
|
{
|
|
|
|
|
CreateTableAsStmt *ctas = makeNode(CreateTableAsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-12-13 19:56:09 +01:00
|
|
|
ctas->query = $9;
|
|
|
|
|
ctas->into = $7;
|
2020-07-11 06:32:28 +02:00
|
|
|
ctas->objtype = OBJECT_TABLE;
|
2014-12-13 19:56:09 +01:00
|
|
|
ctas->is_select_into = false;
|
|
|
|
|
ctas->if_not_exists = true;
|
|
|
|
|
/* cram additional flags into the IntoClause */
|
|
|
|
|
$7->rel->relpersistence = $2;
|
|
|
|
|
$7->skipData = !($10);
|
|
|
|
|
$$ = (Node *) ctas;
|
|
|
|
|
}
|
2007-02-20 18:32:18 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
create_as_target:
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
qualified_name opt_column_list table_access_method_clause
|
|
|
|
|
OptWith OnCommitOption OptTableSpace
|
2007-02-20 18:32:18 +01:00
|
|
|
{
|
|
|
|
|
$$ = makeNode(IntoClause);
|
|
|
|
|
$$->rel = $1;
|
|
|
|
|
$$->colNames = $2;
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
$$->accessMethod = $3;
|
|
|
|
|
$$->options = $4;
|
|
|
|
|
$$->onCommit = $5;
|
|
|
|
|
$$->tableSpaceName = $6;
|
Clean up the mess around EXPLAIN and materialized views.
Revert the matview-related changes in explain.c's API, as per recent
complaint from Robert Haas. The reason for these appears to have been
principally some ill-considered choices around having intorel_startup do
what ought to be parse-time checking, plus a poor arrangement for passing
it the view parsetree it needs to store into pg_rewrite when creating a
materialized view. Do the latter by having parse analysis stick a copy
into the IntoClause, instead of doing it at runtime. (On the whole,
I seriously question the choice to represent CREATE MATERIALIZED VIEW as a
variant of SELECT INTO/CREATE TABLE AS, because that means injecting even
more complexity into what was already a horrid legacy kluge. However,
I didn't go so far as to rethink that choice ... yet.)
I also moved several error checks into matview parse analysis, and
made the check for external Params in a matview more accurate.
In passing, clean things up a bit more around interpretOidsOption(),
and fix things so that we can use that to force no-oids for views,
sequences, etc, thereby eliminating the need to cons up "oids = false"
options when creating them.
catversion bump due to change in IntoClause. (I wonder though if we
really need readfuncs/outfuncs support for IntoClause anymore.)
2013-04-13 01:25:20 +02:00
|
|
|
$$->viewQuery = NULL;
|
2011-11-25 05:21:06 +01:00
|
|
|
$$->skipData = false; /* might get changed later */
|
1997-12-23 20:47:32 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2008-10-28 15:09:45 +01:00
|
|
|
opt_with_data:
|
2017-08-16 06:22:32 +02:00
|
|
|
WITH DATA_P { $$ = true; }
|
|
|
|
|
| WITH NO DATA_P { $$ = false; }
|
|
|
|
|
| /*EMPTY*/ { $$ = true; }
|
2008-10-28 15:09:45 +01:00
|
|
|
;
|
|
|
|
|
|
1997-09-13 05:15:46 +02:00
|
|
|
|
2013-03-04 01:23:31 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* QUERY :
|
|
|
|
|
* CREATE MATERIALIZED VIEW relname AS SelectStmt
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
CreateMatViewStmt:
|
|
|
|
|
CREATE OptNoLog MATERIALIZED VIEW create_mv_target AS SelectStmt opt_with_data
|
|
|
|
|
{
|
|
|
|
|
CreateTableAsStmt *ctas = makeNode(CreateTableAsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2013-03-04 01:23:31 +01:00
|
|
|
ctas->query = $7;
|
|
|
|
|
ctas->into = $5;
|
2020-07-11 06:32:28 +02:00
|
|
|
ctas->objtype = OBJECT_MATVIEW;
|
2013-03-04 01:23:31 +01:00
|
|
|
ctas->is_select_into = false;
|
2014-12-13 19:56:09 +01:00
|
|
|
ctas->if_not_exists = false;
|
2013-03-04 01:23:31 +01:00
|
|
|
/* cram additional flags into the IntoClause */
|
|
|
|
|
$5->rel->relpersistence = $2;
|
|
|
|
|
$5->skipData = !($8);
|
|
|
|
|
$$ = (Node *) ctas;
|
|
|
|
|
}
|
2014-12-13 19:56:09 +01:00
|
|
|
| CREATE OptNoLog MATERIALIZED VIEW IF_P NOT EXISTS create_mv_target AS SelectStmt opt_with_data
|
|
|
|
|
{
|
|
|
|
|
CreateTableAsStmt *ctas = makeNode(CreateTableAsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-12-13 19:56:09 +01:00
|
|
|
ctas->query = $10;
|
|
|
|
|
ctas->into = $8;
|
2020-07-11 06:32:28 +02:00
|
|
|
ctas->objtype = OBJECT_MATVIEW;
|
2014-12-13 19:56:09 +01:00
|
|
|
ctas->is_select_into = false;
|
|
|
|
|
ctas->if_not_exists = true;
|
|
|
|
|
/* cram additional flags into the IntoClause */
|
|
|
|
|
$8->rel->relpersistence = $2;
|
|
|
|
|
$8->skipData = !($11);
|
|
|
|
|
$$ = (Node *) ctas;
|
|
|
|
|
}
|
2013-03-04 01:23:31 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
create_mv_target:
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
qualified_name opt_column_list table_access_method_clause opt_reloptions OptTableSpace
|
2013-03-04 01:23:31 +01:00
|
|
|
{
|
|
|
|
|
$$ = makeNode(IntoClause);
|
|
|
|
|
$$->rel = $1;
|
|
|
|
|
$$->colNames = $2;
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
$$->accessMethod = $3;
|
|
|
|
|
$$->options = $4;
|
2013-03-04 01:23:31 +01:00
|
|
|
$$->onCommit = ONCOMMIT_NOOP;
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
$$->tableSpaceName = $5;
|
Clean up the mess around EXPLAIN and materialized views.
Revert the matview-related changes in explain.c's API, as per recent
complaint from Robert Haas. The reason for these appears to have been
principally some ill-considered choices around having intorel_startup do
what ought to be parse-time checking, plus a poor arrangement for passing
it the view parsetree it needs to store into pg_rewrite when creating a
materialized view. Do the latter by having parse analysis stick a copy
into the IntoClause, instead of doing it at runtime. (On the whole,
I seriously question the choice to represent CREATE MATERIALIZED VIEW as a
variant of SELECT INTO/CREATE TABLE AS, because that means injecting even
more complexity into what was already a horrid legacy kluge. However,
I didn't go so far as to rethink that choice ... yet.)
I also moved several error checks into matview parse analysis, and
made the check for external Params in a matview more accurate.
In passing, clean things up a bit more around interpretOidsOption(),
and fix things so that we can use that to force no-oids for views,
sequences, etc, thereby eliminating the need to cons up "oids = false"
options when creating them.
catversion bump due to change in IntoClause. (I wonder though if we
really need readfuncs/outfuncs support for IntoClause anymore.)
2013-04-13 01:25:20 +02:00
|
|
|
$$->viewQuery = NULL; /* filled at analysis time */
|
2013-03-04 01:23:31 +01:00
|
|
|
$$->skipData = false; /* might get changed later */
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
OptNoLog: UNLOGGED { $$ = RELPERSISTENCE_UNLOGGED; }
|
|
|
|
|
| /*EMPTY*/ { $$ = RELPERSISTENCE_PERMANENT; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* QUERY :
|
|
|
|
|
* REFRESH MATERIALIZED VIEW qualified_name
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
RefreshMatViewStmt:
|
2013-07-16 19:55:44 +02:00
|
|
|
REFRESH MATERIALIZED VIEW opt_concurrently qualified_name opt_with_data
|
2013-03-04 01:23:31 +01:00
|
|
|
{
|
|
|
|
|
RefreshMatViewStmt *n = makeNode(RefreshMatViewStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2013-07-16 19:55:44 +02:00
|
|
|
n->concurrent = $4;
|
|
|
|
|
n->relation = $5;
|
|
|
|
|
n->skipData = !($6);
|
2013-03-04 01:23:31 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
1997-04-02 06:01:03 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* QUERY :
|
|
|
|
|
* CREATE SEQUENCE seqname
|
2003-03-20 08:02:11 +01:00
|
|
|
* ALTER SEQUENCE seqname
|
1997-04-02 06:01:03 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
CreateSeqStmt:
|
2008-06-15 03:25:54 +02:00
|
|
|
CREATE OptTemp SEQUENCE qualified_name OptSeqOptList
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
|
|
|
|
CreateSeqStmt *n = makeNode(CreateSeqStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-12-13 18:34:26 +01:00
|
|
|
$4->relpersistence = $2;
|
2002-03-21 17:02:16 +01:00
|
|
|
n->sequence = $4;
|
2001-06-23 02:07:34 +02:00
|
|
|
n->options = $5;
|
2010-08-18 20:35:21 +02:00
|
|
|
n->ownerId = InvalidOid;
|
2014-08-26 15:05:18 +02:00
|
|
|
n->if_not_exists = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2014-08-26 15:05:18 +02:00
|
|
|
}
|
|
|
|
|
| CREATE OptTemp SEQUENCE IF_P NOT EXISTS qualified_name OptSeqOptList
|
|
|
|
|
{
|
|
|
|
|
CreateSeqStmt *n = makeNode(CreateSeqStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-08-26 15:05:18 +02:00
|
|
|
$7->relpersistence = $2;
|
|
|
|
|
n->sequence = $7;
|
|
|
|
|
n->options = $8;
|
|
|
|
|
n->ownerId = InvalidOid;
|
|
|
|
|
n->if_not_exists = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
|
|
|
|
;
|
1997-04-02 06:01:03 +02:00
|
|
|
|
2003-03-20 08:02:11 +01:00
|
|
|
AlterSeqStmt:
|
2009-01-12 10:38:30 +01:00
|
|
|
ALTER SEQUENCE qualified_name SeqOptList
|
2003-03-20 08:02:11 +01:00
|
|
|
{
|
|
|
|
|
AlterSeqStmt *n = makeNode(AlterSeqStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-03-20 08:02:11 +01:00
|
|
|
n->sequence = $3;
|
|
|
|
|
n->options = $4;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2003-03-20 08:02:11 +01:00
|
|
|
}
|
2012-01-24 00:25:04 +01:00
|
|
|
| ALTER SEQUENCE IF_P EXISTS qualified_name SeqOptList
|
|
|
|
|
{
|
|
|
|
|
AlterSeqStmt *n = makeNode(AlterSeqStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-01-24 00:25:04 +01:00
|
|
|
n->sequence = $5;
|
|
|
|
|
n->options = $6;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-01-24 00:25:04 +01:00
|
|
|
}
|
|
|
|
|
|
2003-03-20 08:02:11 +01:00
|
|
|
;
|
|
|
|
|
|
2008-06-15 03:25:54 +02:00
|
|
|
OptSeqOptList: SeqOptList { $$ = $1; }
|
2002-08-05 04:30:50 +02:00
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
2017-04-06 14:33:16 +02:00
|
|
|
OptParenthesizedSeqOptList: '(' SeqOptList ')' { $$ = $2; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
2008-06-15 03:25:54 +02:00
|
|
|
SeqOptList: SeqOptElem { $$ = list_make1($1); }
|
|
|
|
|
| SeqOptList SeqOptElem { $$ = lappend($1, $2); }
|
|
|
|
|
;
|
|
|
|
|
|
2017-02-10 21:12:32 +01:00
|
|
|
SeqOptElem: AS SimpleTypename
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("as", (Node *) $2, @1);
|
2017-02-10 21:12:32 +01:00
|
|
|
}
|
|
|
|
|
| CACHE NumericOnly
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("cache", (Node *) $2, @1);
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
1998-03-18 17:50:25 +01:00
|
|
|
| CYCLE
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("cycle", (Node *) makeBoolean(true), @1);
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2002-11-10 01:10:20 +01:00
|
|
|
| NO CYCLE
|
1998-03-18 17:50:25 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("cycle", (Node *) makeBoolean(false), @1);
|
2002-11-10 01:10:20 +01:00
|
|
|
}
|
|
|
|
|
| INCREMENT opt_by NumericOnly
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("increment", (Node *) $3, @1);
|
1998-03-18 17:50:25 +01:00
|
|
|
}
|
2001-08-16 22:38:56 +02:00
|
|
|
| MAXVALUE NumericOnly
|
1998-03-18 17:50:25 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("maxvalue", (Node *) $2, @1);
|
1998-03-18 17:50:25 +01:00
|
|
|
}
|
2001-08-16 22:38:56 +02:00
|
|
|
| MINVALUE NumericOnly
|
1998-03-18 17:50:25 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("minvalue", (Node *) $2, @1);
|
1998-03-18 17:50:25 +01:00
|
|
|
}
|
2003-02-13 06:25:24 +01:00
|
|
|
| NO MAXVALUE
|
|
|
|
|
{
|
2016-09-06 18:00:00 +02:00
|
|
|
$$ = makeDefElem("maxvalue", NULL, @1);
|
2003-02-13 06:25:24 +01:00
|
|
|
}
|
|
|
|
|
| NO MINVALUE
|
|
|
|
|
{
|
2016-09-06 18:00:00 +02:00
|
|
|
$$ = makeDefElem("minvalue", NULL, @1);
|
2003-02-13 06:25:24 +01:00
|
|
|
}
|
2006-08-21 02:57:26 +02:00
|
|
|
| OWNED BY any_name
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("owned_by", (Node *) $3, @1);
|
2006-08-21 02:57:26 +02:00
|
|
|
}
|
2017-04-06 14:33:16 +02:00
|
|
|
| SEQUENCE NAME_P any_name
|
|
|
|
|
{
|
|
|
|
|
/* not documented, only used by pg_dump */
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("sequence_name", (Node *) $3, @1);
|
2017-04-06 14:33:16 +02:00
|
|
|
}
|
2002-11-10 01:10:20 +01:00
|
|
|
| START opt_with NumericOnly
|
1998-03-18 17:50:25 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("start", (Node *) $3, @1);
|
1998-03-18 17:50:25 +01:00
|
|
|
}
|
2008-05-17 01:36:05 +02:00
|
|
|
| RESTART
|
|
|
|
|
{
|
2016-09-06 18:00:00 +02:00
|
|
|
$$ = makeDefElem("restart", NULL, @1);
|
2008-05-17 01:36:05 +02:00
|
|
|
}
|
2003-03-20 08:02:11 +01:00
|
|
|
| RESTART opt_with NumericOnly
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("restart", (Node *) $3, @1);
|
2003-03-20 08:02:11 +01:00
|
|
|
}
|
1998-03-18 17:50:25 +01:00
|
|
|
;
|
|
|
|
|
|
2020-11-12 07:48:36 +01:00
|
|
|
opt_by: BY
|
2020-11-16 11:54:52 +01:00
|
|
|
| /* EMPTY */
|
2002-11-10 01:10:20 +01:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
NumericOnly:
|
Remove Value node struct
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and the node
type don't match most of the time, and so it has to be treated
specially a lot. There doesn't seem to be any value in the special
construct. There is very little code that wants to accept all Value
variants but nothing else (and even if it did, this doesn't provide
any convenient way to check it), and most code wants either just one
particular node type (usually String), or it accepts a broader set of
node types besides just Value.
This change removes the Value struct and node type and replaces them
by separate Integer, Float, String, and BitString node types that are
proper node types and structs of their own and behave mostly like
normal node types.
Also, this removes the T_Null node tag, which was previously also a
possible variant of Value but wasn't actually used outside of the
Value contained in A_Const. Replace that by an isnull field in
A_Const.
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/5ba6bc5b-3f95-04f2-2419-f8ddb4c046fb@enterprisedb.com
2021-09-09 07:58:12 +02:00
|
|
|
FCONST { $$ = (Node *) makeFloat($1); }
|
|
|
|
|
| '+' FCONST { $$ = (Node *) makeFloat($2); }
|
1998-07-08 16:04:11 +02:00
|
|
|
| '-' FCONST
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
Float *f = makeFloat($2);
|
|
|
|
|
|
Remove Value node struct
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and the node
type don't match most of the time, and so it has to be treated
specially a lot. There doesn't seem to be any value in the special
construct. There is very little code that wants to accept all Value
variants but nothing else (and even if it did, this doesn't provide
any convenient way to check it), and most code wants either just one
particular node type (usually String), or it accepts a broader set of
node types besides just Value.
This change removes the Value struct and node type and replaces them
by separate Integer, Float, String, and BitString node types that are
proper node types and structs of their own and behave mostly like
normal node types.
Also, this removes the T_Null node tag, which was previously also a
possible variant of Value but wasn't actually used outside of the
Value contained in A_Const. Replace that by an isnull field in
A_Const.
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/5ba6bc5b-3f95-04f2-2419-f8ddb4c046fb@enterprisedb.com
2021-09-09 07:58:12 +02:00
|
|
|
doNegateFloat(f);
|
|
|
|
|
$$ = (Node *) f;
|
1998-07-08 16:04:11 +02:00
|
|
|
}
|
Remove Value node struct
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and the node
type don't match most of the time, and so it has to be treated
specially a lot. There doesn't seem to be any value in the special
construct. There is very little code that wants to accept all Value
variants but nothing else (and even if it did, this doesn't provide
any convenient way to check it), and most code wants either just one
particular node type (usually String), or it accepts a broader set of
node types besides just Value.
This change removes the Value struct and node type and replaces them
by separate Integer, Float, String, and BitString node types that are
proper node types and structs of their own and behave mostly like
normal node types.
Also, this removes the T_Null node tag, which was previously also a
possible variant of Value but wasn't actually used outside of the
Value contained in A_Const. Replace that by an isnull field in
A_Const.
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/5ba6bc5b-3f95-04f2-2419-f8ddb4c046fb@enterprisedb.com
2021-09-09 07:58:12 +02:00
|
|
|
| SignedIconst { $$ = (Node *) makeInteger($1); }
|
1998-07-08 16:04:11 +02:00
|
|
|
;
|
|
|
|
|
|
2010-06-13 19:43:13 +02:00
|
|
|
NumericOnly_list: NumericOnly { $$ = list_make1($1); }
|
|
|
|
|
| NumericOnly_list ',' NumericOnly { $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
1997-10-28 16:11:45 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* QUERIES :
|
2010-02-23 23:51:43 +01:00
|
|
|
* CREATE [OR REPLACE] [TRUSTED] [PROCEDURAL] LANGUAGE ...
|
|
|
|
|
* DROP [PROCEDURAL] LANGUAGE ...
|
1997-10-28 16:11:45 +01:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
CreatePLangStmt:
|
2020-06-11 10:26:12 +02:00
|
|
|
CREATE opt_or_replace opt_trusted opt_procedural LANGUAGE name
|
2005-09-06 01:50:49 +02:00
|
|
|
{
|
Invent "trusted" extensions, and remove the pg_pltemplate catalog.
This patch creates a new extension property, "trusted". An extension
that's marked that way in its control file can be installed by a
non-superuser who has the CREATE privilege on the current database,
even if the extension contains objects that normally would have to be
created by a superuser. The objects within the extension will (by
default) be owned by the bootstrap superuser, but the extension itself
will be owned by the calling user. This allows replicating the old
behavior around trusted procedural languages, without all the
special-case logic in CREATE LANGUAGE. We have, however, chosen to
loosen the rules slightly: formerly, only a database owner could take
advantage of the special case that allowed installation of a trusted
language, but now anyone who has CREATE privilege can do so.
Having done that, we can delete the pg_pltemplate catalog, moving the
knowledge it contained into the extension script files for the various
PLs. This ends up being no change at all for the in-core PLs, but it is
a large step forward for external PLs: they can now have the same ease
of installation as core PLs do. The old "trusted PL" behavior was only
available to PLs that had entries in pg_pltemplate, but now any
extension can be marked trusted if appropriate.
This also removes one of the stumbling blocks for our Python 2 -> 3
migration, since the association of "plpythonu" with Python 2 is no
longer hard-wired into pg_pltemplate's initial contents. Exactly where
we go from here on that front remains to be settled, but one problem
is fixed.
Patch by me, reviewed by Peter Eisentraut, Stephen Frost, and others.
Discussion: https://postgr.es/m/5889.1566415762@sss.pgh.pa.us
2020-01-30 00:42:43 +01:00
|
|
|
/*
|
|
|
|
|
* We now interpret parameterless CREATE LANGUAGE as
|
|
|
|
|
* CREATE EXTENSION. "OR REPLACE" is silently translated
|
|
|
|
|
* to "IF NOT EXISTS", which isn't quite the same, but
|
|
|
|
|
* seems more useful than throwing an error. We just
|
|
|
|
|
* ignore TRUSTED, as the previous code would have too.
|
|
|
|
|
*/
|
|
|
|
|
CreateExtensionStmt *n = makeNode(CreateExtensionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Invent "trusted" extensions, and remove the pg_pltemplate catalog.
This patch creates a new extension property, "trusted". An extension
that's marked that way in its control file can be installed by a
non-superuser who has the CREATE privilege on the current database,
even if the extension contains objects that normally would have to be
created by a superuser. The objects within the extension will (by
default) be owned by the bootstrap superuser, but the extension itself
will be owned by the calling user. This allows replicating the old
behavior around trusted procedural languages, without all the
special-case logic in CREATE LANGUAGE. We have, however, chosen to
loosen the rules slightly: formerly, only a database owner could take
advantage of the special case that allowed installation of a trusted
language, but now anyone who has CREATE privilege can do so.
Having done that, we can delete the pg_pltemplate catalog, moving the
knowledge it contained into the extension script files for the various
PLs. This ends up being no change at all for the in-core PLs, but it is
a large step forward for external PLs: they can now have the same ease
of installation as core PLs do. The old "trusted PL" behavior was only
available to PLs that had entries in pg_pltemplate, but now any
extension can be marked trusted if appropriate.
This also removes one of the stumbling blocks for our Python 2 -> 3
migration, since the association of "plpythonu" with Python 2 is no
longer hard-wired into pg_pltemplate's initial contents. Exactly where
we go from here on that front remains to be settled, but one problem
is fixed.
Patch by me, reviewed by Peter Eisentraut, Stephen Frost, and others.
Discussion: https://postgr.es/m/5889.1566415762@sss.pgh.pa.us
2020-01-30 00:42:43 +01:00
|
|
|
n->if_not_exists = $2;
|
|
|
|
|
n->extname = $6;
|
|
|
|
|
n->options = NIL;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-09-06 01:50:49 +02:00
|
|
|
}
|
2020-06-11 10:26:12 +02:00
|
|
|
| CREATE opt_or_replace opt_trusted opt_procedural LANGUAGE name
|
2009-09-23 01:43:43 +02:00
|
|
|
HANDLER handler_name opt_inline_handler opt_validator
|
1997-10-28 16:11:45 +01:00
|
|
|
{
|
|
|
|
|
CreatePLangStmt *n = makeNode(CreatePLangStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-02-23 23:51:43 +01:00
|
|
|
n->replace = $2;
|
|
|
|
|
n->plname = $6;
|
|
|
|
|
n->plhandler = $8;
|
|
|
|
|
n->plinline = $9;
|
|
|
|
|
n->plvalidator = $10;
|
|
|
|
|
n->pltrusted = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-10-28 16:11:45 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
opt_trusted:
|
2017-08-16 06:22:32 +02:00
|
|
|
TRUSTED { $$ = true; }
|
|
|
|
|
| /*EMPTY*/ { $$ = false; }
|
2000-11-04 22:04:56 +01:00
|
|
|
;
|
1997-10-28 16:11:45 +01:00
|
|
|
|
2002-03-29 20:06:29 +01:00
|
|
|
/* This ought to be just func_name, but that causes reduce/reduce conflicts
|
|
|
|
|
* (CREATE LANGUAGE is the only place where func_name isn't followed by '(').
|
2004-06-09 21:08:20 +02:00
|
|
|
* Work around by using simple names, instead.
|
2002-03-29 20:06:29 +01:00
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
handler_name:
|
2004-06-09 21:08:20 +02:00
|
|
|
name { $$ = list_make1(makeString($1)); }
|
|
|
|
|
| name attrs { $$ = lcons(makeString($1), $2); }
|
2002-03-29 20:06:29 +01:00
|
|
|
;
|
|
|
|
|
|
2009-09-23 01:43:43 +02:00
|
|
|
opt_inline_handler:
|
|
|
|
|
INLINE_P handler_name { $$ = $2; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
2009-02-24 11:06:36 +01:00
|
|
|
validator_clause:
|
2005-09-06 01:50:49 +02:00
|
|
|
VALIDATOR handler_name { $$ = $2; }
|
2009-02-24 11:06:36 +01:00
|
|
|
| NO VALIDATOR { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_validator:
|
|
|
|
|
validator_clause { $$ = $1; }
|
2005-09-06 01:50:49 +02:00
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
2002-03-21 17:02:16 +01:00
|
|
|
;
|
2001-08-13 23:34:54 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
opt_procedural:
|
2020-11-12 07:48:36 +01:00
|
|
|
PROCEDURAL
|
|
|
|
|
| /*EMPTY*/
|
2000-11-04 22:04:56 +01:00
|
|
|
;
|
2002-06-17 07:40:32 +02:00
|
|
|
|
2004-06-18 08:14:31 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2011-11-01 20:50:00 +01:00
|
|
|
* QUERY:
|
2004-06-18 08:14:31 +02:00
|
|
|
* CREATE TABLESPACE tablespace LOCATION '/path/to/tablespace/'
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2014-01-19 02:59:31 +01:00
|
|
|
CreateTableSpaceStmt: CREATE TABLESPACE name OptTableSpaceOwner LOCATION Sconst opt_reloptions
|
2004-06-18 08:14:31 +02:00
|
|
|
{
|
|
|
|
|
CreateTableSpaceStmt *n = makeNode(CreateTableSpaceStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-06-18 08:14:31 +02:00
|
|
|
n->tablespacename = $3;
|
|
|
|
|
n->owner = $4;
|
|
|
|
|
n->location = $6;
|
2014-01-19 02:59:31 +01:00
|
|
|
n->options = $7;
|
2004-06-18 08:14:31 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
OptTableSpaceOwner: OWNER RoleSpec { $$ = $2; }
|
2004-06-18 08:14:31 +02:00
|
|
|
| /*EMPTY */ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2011-11-01 20:50:00 +01:00
|
|
|
* QUERY :
|
2004-06-18 08:14:31 +02:00
|
|
|
* DROP TABLESPACE <tablespace>
|
|
|
|
|
*
|
|
|
|
|
* No need for drop behaviour as we cannot implement dependencies for
|
|
|
|
|
* objects in other databases; we can only support RESTRICT.
|
|
|
|
|
*
|
|
|
|
|
****************************************************************************/
|
|
|
|
|
|
|
|
|
|
DropTableSpaceStmt: DROP TABLESPACE name
|
|
|
|
|
{
|
|
|
|
|
DropTableSpaceStmt *n = makeNode(DropTableSpaceStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-06-18 08:14:31 +02:00
|
|
|
n->tablespacename = $3;
|
2006-06-16 22:23:45 +02:00
|
|
|
n->missing_ok = false;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| DROP TABLESPACE IF_P EXISTS name
|
2011-11-01 20:50:00 +01:00
|
|
|
{
|
2006-06-16 22:23:45 +02:00
|
|
|
DropTableSpaceStmt *n = makeNode(DropTableSpaceStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2006-06-16 22:23:45 +02:00
|
|
|
n->tablespacename = $5;
|
|
|
|
|
n->missing_ok = true;
|
2004-06-18 08:14:31 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2011-02-08 22:08:41 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2011-11-01 20:50:00 +01:00
|
|
|
* QUERY:
|
2011-02-08 22:08:41 +01:00
|
|
|
* CREATE EXTENSION extension
|
2020-02-19 22:59:14 +01:00
|
|
|
* [ WITH ] [ SCHEMA schema ] [ VERSION version ]
|
2011-02-08 22:08:41 +01:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
CreateExtensionStmt: CREATE EXTENSION name opt_with create_extension_opt_list
|
|
|
|
|
{
|
|
|
|
|
CreateExtensionStmt *n = makeNode(CreateExtensionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-02-08 22:08:41 +01:00
|
|
|
n->extname = $3;
|
2011-03-04 22:08:24 +01:00
|
|
|
n->if_not_exists = false;
|
2011-02-08 22:08:41 +01:00
|
|
|
n->options = $5;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2011-03-04 22:08:24 +01:00
|
|
|
| CREATE EXTENSION IF_P NOT EXISTS name opt_with create_extension_opt_list
|
|
|
|
|
{
|
|
|
|
|
CreateExtensionStmt *n = makeNode(CreateExtensionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-03-04 22:08:24 +01:00
|
|
|
n->extname = $6;
|
|
|
|
|
n->if_not_exists = true;
|
|
|
|
|
n->options = $8;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2011-02-08 22:08:41 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
create_extension_opt_list:
|
|
|
|
|
create_extension_opt_list create_extension_opt_item
|
|
|
|
|
{ $$ = lappend($1, $2); }
|
|
|
|
|
| /* EMPTY */
|
|
|
|
|
{ $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
create_extension_opt_item:
|
2011-02-12 03:25:20 +01:00
|
|
|
SCHEMA name
|
2011-02-08 22:08:41 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("schema", (Node *) makeString($2), @1);
|
2011-02-12 03:25:20 +01:00
|
|
|
}
|
2013-06-03 02:09:20 +02:00
|
|
|
| VERSION_P NonReservedWord_or_Sconst
|
2011-02-12 03:25:20 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("new_version", (Node *) makeString($2), @1);
|
2011-02-12 03:25:20 +01:00
|
|
|
}
|
2013-06-03 02:09:20 +02:00
|
|
|
| FROM NonReservedWord_or_Sconst
|
2011-02-12 03:25:20 +01:00
|
|
|
{
|
2020-02-19 22:59:14 +01:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
|
errmsg("CREATE EXTENSION ... FROM is no longer supported"),
|
|
|
|
|
parser_errposition(@1)));
|
2011-02-12 03:25:20 +01:00
|
|
|
}
|
2015-10-03 18:19:37 +02:00
|
|
|
| CASCADE
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("cascade", (Node *) makeBoolean(true), @1);
|
2015-10-03 18:19:37 +02:00
|
|
|
}
|
2011-02-12 03:25:20 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* ALTER EXTENSION name UPDATE [ TO version ]
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
AlterExtensionStmt: ALTER EXTENSION name UPDATE alter_extension_opt_list
|
|
|
|
|
{
|
|
|
|
|
AlterExtensionStmt *n = makeNode(AlterExtensionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-02-12 03:25:20 +01:00
|
|
|
n->extname = $3;
|
|
|
|
|
n->options = $5;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
alter_extension_opt_list:
|
|
|
|
|
alter_extension_opt_list alter_extension_opt_item
|
|
|
|
|
{ $$ = lappend($1, $2); }
|
|
|
|
|
| /* EMPTY */
|
|
|
|
|
{ $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
alter_extension_opt_item:
|
2013-06-03 02:09:20 +02:00
|
|
|
TO NonReservedWord_or_Sconst
|
2011-02-12 03:25:20 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("new_version", (Node *) makeString($2), @1);
|
2011-02-08 22:08:41 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2011-02-09 17:55:32 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2011-02-10 23:36:44 +01:00
|
|
|
* ALTER EXTENSION name ADD/DROP object-identifier
|
2011-02-09 17:55:32 +01:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2011-02-10 23:36:44 +01:00
|
|
|
AlterExtensionContentsStmt:
|
2020-06-13 09:03:28 +02:00
|
|
|
ALTER EXTENSION name add_drop object_type_name name
|
2016-10-02 20:31:28 +02:00
|
|
|
{
|
|
|
|
|
AlterExtensionContentsStmt *n = makeNode(AlterExtensionContentsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2016-10-02 20:31:28 +02:00
|
|
|
n->extname = $3;
|
|
|
|
|
n->action = $4;
|
2020-06-13 09:03:28 +02:00
|
|
|
n->objtype = $5;
|
|
|
|
|
n->object = (Node *) makeString($6);
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2016-10-02 20:31:28 +02:00
|
|
|
}
|
2020-06-13 09:03:28 +02:00
|
|
|
| ALTER EXTENSION name add_drop object_type_any_name any_name
|
2011-02-09 17:55:32 +01:00
|
|
|
{
|
2011-02-10 23:36:44 +01:00
|
|
|
AlterExtensionContentsStmt *n = makeNode(AlterExtensionContentsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-02-09 17:55:32 +01:00
|
|
|
n->extname = $3;
|
2011-02-10 23:36:44 +01:00
|
|
|
n->action = $4;
|
2020-06-13 09:03:28 +02:00
|
|
|
n->objtype = $5;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-02-09 17:55:32 +01:00
|
|
|
}
|
2020-06-13 09:03:28 +02:00
|
|
|
| ALTER EXTENSION name add_drop AGGREGATE aggregate_with_argtypes
|
2011-02-12 14:54:13 +01:00
|
|
|
{
|
|
|
|
|
AlterExtensionContentsStmt *n = makeNode(AlterExtensionContentsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-02-12 14:54:13 +01:00
|
|
|
n->extname = $3;
|
|
|
|
|
n->action = $4;
|
2020-06-13 09:03:28 +02:00
|
|
|
n->objtype = OBJECT_AGGREGATE;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-02-12 14:54:13 +01:00
|
|
|
}
|
2020-06-13 09:03:28 +02:00
|
|
|
| ALTER EXTENSION name add_drop CAST '(' Typename AS Typename ')'
|
2011-02-09 17:55:32 +01:00
|
|
|
{
|
2011-02-10 23:36:44 +01:00
|
|
|
AlterExtensionContentsStmt *n = makeNode(AlterExtensionContentsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-02-09 17:55:32 +01:00
|
|
|
n->extname = $3;
|
2011-02-10 23:36:44 +01:00
|
|
|
n->action = $4;
|
2020-06-13 09:03:28 +02:00
|
|
|
n->objtype = OBJECT_CAST;
|
|
|
|
|
n->object = (Node *) list_make2($7, $9);
|
|
|
|
|
$$ = (Node *) n;
|
2011-02-09 17:55:32 +01:00
|
|
|
}
|
2015-01-12 19:32:48 +01:00
|
|
|
| ALTER EXTENSION name add_drop DOMAIN_P Typename
|
2011-02-09 17:55:32 +01:00
|
|
|
{
|
2011-02-10 23:36:44 +01:00
|
|
|
AlterExtensionContentsStmt *n = makeNode(AlterExtensionContentsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-02-09 17:55:32 +01:00
|
|
|
n->extname = $3;
|
2011-02-10 23:36:44 +01:00
|
|
|
n->action = $4;
|
2011-02-09 17:55:32 +01:00
|
|
|
n->objtype = OBJECT_DOMAIN;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-02-09 17:55:32 +01:00
|
|
|
}
|
2011-02-10 23:36:44 +01:00
|
|
|
| ALTER EXTENSION name add_drop FUNCTION function_with_argtypes
|
2011-02-09 17:55:32 +01:00
|
|
|
{
|
2011-02-10 23:36:44 +01:00
|
|
|
AlterExtensionContentsStmt *n = makeNode(AlterExtensionContentsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-02-09 17:55:32 +01:00
|
|
|
n->extname = $3;
|
2011-02-10 23:36:44 +01:00
|
|
|
n->action = $4;
|
2011-02-09 17:55:32 +01:00
|
|
|
n->objtype = OBJECT_FUNCTION;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-02-09 17:55:32 +01:00
|
|
|
}
|
2016-12-28 18:00:00 +01:00
|
|
|
| ALTER EXTENSION name add_drop OPERATOR operator_with_argtypes
|
2011-02-09 17:55:32 +01:00
|
|
|
{
|
2011-02-10 23:36:44 +01:00
|
|
|
AlterExtensionContentsStmt *n = makeNode(AlterExtensionContentsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-02-09 17:55:32 +01:00
|
|
|
n->extname = $3;
|
2011-02-10 23:36:44 +01:00
|
|
|
n->action = $4;
|
2011-02-09 17:55:32 +01:00
|
|
|
n->objtype = OBJECT_OPERATOR;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-02-09 17:55:32 +01:00
|
|
|
}
|
2020-06-10 22:58:46 +02:00
|
|
|
| ALTER EXTENSION name add_drop OPERATOR CLASS any_name USING name
|
2011-02-09 17:55:32 +01:00
|
|
|
{
|
2011-02-10 23:36:44 +01:00
|
|
|
AlterExtensionContentsStmt *n = makeNode(AlterExtensionContentsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-02-09 17:55:32 +01:00
|
|
|
n->extname = $3;
|
2011-02-10 23:36:44 +01:00
|
|
|
n->action = $4;
|
2011-02-09 17:55:32 +01:00
|
|
|
n->objtype = OBJECT_OPCLASS;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) lcons(makeString($9), $7);
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-02-09 17:55:32 +01:00
|
|
|
}
|
2020-06-10 22:58:46 +02:00
|
|
|
| ALTER EXTENSION name add_drop OPERATOR FAMILY any_name USING name
|
2011-02-09 17:55:32 +01:00
|
|
|
{
|
2011-02-10 23:36:44 +01:00
|
|
|
AlterExtensionContentsStmt *n = makeNode(AlterExtensionContentsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-02-09 17:55:32 +01:00
|
|
|
n->extname = $3;
|
2011-02-10 23:36:44 +01:00
|
|
|
n->action = $4;
|
2011-02-09 17:55:32 +01:00
|
|
|
n->objtype = OBJECT_OPFAMILY;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) lcons(makeString($9), $7);
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-02-09 17:55:32 +01:00
|
|
|
}
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| ALTER EXTENSION name add_drop PROCEDURE function_with_argtypes
|
2017-11-30 14:46:13 +01:00
|
|
|
{
|
|
|
|
|
AlterExtensionContentsStmt *n = makeNode(AlterExtensionContentsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->extname = $3;
|
|
|
|
|
n->action = $4;
|
|
|
|
|
n->objtype = OBJECT_PROCEDURE;
|
|
|
|
|
n->object = (Node *) $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-11-30 14:46:13 +01:00
|
|
|
}
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| ALTER EXTENSION name add_drop ROUTINE function_with_argtypes
|
2017-11-30 14:46:13 +01:00
|
|
|
{
|
|
|
|
|
AlterExtensionContentsStmt *n = makeNode(AlterExtensionContentsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->extname = $3;
|
|
|
|
|
n->action = $4;
|
|
|
|
|
n->objtype = OBJECT_ROUTINE;
|
|
|
|
|
n->object = (Node *) $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-11-30 14:46:13 +01:00
|
|
|
}
|
2015-04-26 16:33:14 +02:00
|
|
|
| ALTER EXTENSION name add_drop TRANSFORM FOR Typename LANGUAGE name
|
|
|
|
|
{
|
|
|
|
|
AlterExtensionContentsStmt *n = makeNode(AlterExtensionContentsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2015-04-26 16:33:14 +02:00
|
|
|
n->extname = $3;
|
|
|
|
|
n->action = $4;
|
|
|
|
|
n->objtype = OBJECT_TRANSFORM;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) list_make2($7, makeString($9));
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2015-04-26 16:33:14 +02:00
|
|
|
}
|
2015-01-12 19:32:48 +01:00
|
|
|
| ALTER EXTENSION name add_drop TYPE_P Typename
|
2011-02-09 17:55:32 +01:00
|
|
|
{
|
2011-02-10 23:36:44 +01:00
|
|
|
AlterExtensionContentsStmt *n = makeNode(AlterExtensionContentsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-02-09 17:55:32 +01:00
|
|
|
n->extname = $3;
|
2011-02-10 23:36:44 +01:00
|
|
|
n->action = $4;
|
2011-02-09 17:55:32 +01:00
|
|
|
n->objtype = OBJECT_TYPE;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-02-09 17:55:32 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2008-12-19 17:25:19 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2011-11-01 20:50:00 +01:00
|
|
|
* QUERY:
|
2011-02-19 06:06:18 +01:00
|
|
|
* CREATE FOREIGN DATA WRAPPER name options
|
2008-12-19 17:25:19 +01:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2011-02-19 06:06:18 +01:00
|
|
|
CreateFdwStmt: CREATE FOREIGN DATA_P WRAPPER name opt_fdw_options create_generic_options
|
2008-12-19 17:25:19 +01:00
|
|
|
{
|
|
|
|
|
CreateFdwStmt *n = makeNode(CreateFdwStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-12-19 17:25:19 +01:00
|
|
|
n->fdwname = $5;
|
2011-02-19 06:06:18 +01:00
|
|
|
n->func_options = $6;
|
2009-02-24 11:06:36 +01:00
|
|
|
n->options = $7;
|
2008-12-19 17:25:19 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2011-02-19 06:06:18 +01:00
|
|
|
fdw_option:
|
2022-05-13 07:17:29 +02:00
|
|
|
HANDLER handler_name { $$ = makeDefElem("handler", (Node *) $2, @1); }
|
2016-09-06 18:00:00 +02:00
|
|
|
| NO HANDLER { $$ = makeDefElem("handler", NULL, @1); }
|
2022-05-13 07:17:29 +02:00
|
|
|
| VALIDATOR handler_name { $$ = makeDefElem("validator", (Node *) $2, @1); }
|
2016-09-06 18:00:00 +02:00
|
|
|
| NO VALIDATOR { $$ = makeDefElem("validator", NULL, @1); }
|
2011-02-19 06:06:18 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
fdw_options:
|
|
|
|
|
fdw_option { $$ = list_make1($1); }
|
|
|
|
|
| fdw_options fdw_option { $$ = lappend($1, $2); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_fdw_options:
|
|
|
|
|
fdw_options { $$ = $1; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
2008-12-19 17:25:19 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2011-11-01 20:50:00 +01:00
|
|
|
* QUERY :
|
2011-02-19 06:06:18 +01:00
|
|
|
* ALTER FOREIGN DATA WRAPPER name options
|
2008-12-19 17:25:19 +01:00
|
|
|
*
|
|
|
|
|
****************************************************************************/
|
|
|
|
|
|
2011-02-19 06:06:18 +01:00
|
|
|
AlterFdwStmt: ALTER FOREIGN DATA_P WRAPPER name opt_fdw_options alter_generic_options
|
2008-12-19 17:25:19 +01:00
|
|
|
{
|
|
|
|
|
AlterFdwStmt *n = makeNode(AlterFdwStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-12-19 17:25:19 +01:00
|
|
|
n->fdwname = $5;
|
2011-02-19 06:06:18 +01:00
|
|
|
n->func_options = $6;
|
2009-02-24 11:06:36 +01:00
|
|
|
n->options = $7;
|
2008-12-19 17:25:19 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2011-02-19 06:06:18 +01:00
|
|
|
| ALTER FOREIGN DATA_P WRAPPER name fdw_options
|
2008-12-19 17:25:19 +01:00
|
|
|
{
|
|
|
|
|
AlterFdwStmt *n = makeNode(AlterFdwStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-12-19 17:25:19 +01:00
|
|
|
n->fdwname = $5;
|
2011-02-19 06:06:18 +01:00
|
|
|
n->func_options = $6;
|
|
|
|
|
n->options = NIL;
|
2008-12-19 17:25:19 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/* Options definition for CREATE FDW, SERVER and USER MAPPING */
|
|
|
|
|
create_generic_options:
|
2009-04-04 23:12:31 +02:00
|
|
|
OPTIONS '(' generic_option_list ')' { $$ = $3; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
2008-12-19 17:25:19 +01:00
|
|
|
;
|
|
|
|
|
|
2009-04-04 23:12:31 +02:00
|
|
|
generic_option_list:
|
|
|
|
|
generic_option_elem
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make1($1);
|
|
|
|
|
}
|
|
|
|
|
| generic_option_list ',' generic_option_elem
|
|
|
|
|
{
|
|
|
|
|
$$ = lappend($1, $3);
|
|
|
|
|
}
|
2008-12-19 17:25:19 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/* Options definition for ALTER FDW, SERVER and USER MAPPING */
|
|
|
|
|
alter_generic_options:
|
2009-04-04 23:12:31 +02:00
|
|
|
OPTIONS '(' alter_generic_option_list ')' { $$ = $3; }
|
2008-12-19 17:25:19 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
alter_generic_option_list:
|
2009-04-04 23:12:31 +02:00
|
|
|
alter_generic_option_elem
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make1($1);
|
|
|
|
|
}
|
|
|
|
|
| alter_generic_option_list ',' alter_generic_option_elem
|
|
|
|
|
{
|
|
|
|
|
$$ = lappend($1, $3);
|
|
|
|
|
}
|
2008-12-19 17:25:19 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
alter_generic_option_elem:
|
2009-04-04 23:12:31 +02:00
|
|
|
generic_option_elem
|
|
|
|
|
{
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
|
|
|
|
| SET generic_option_elem
|
|
|
|
|
{
|
|
|
|
|
$$ = $2;
|
|
|
|
|
$$->defaction = DEFELEM_SET;
|
|
|
|
|
}
|
|
|
|
|
| ADD_P generic_option_elem
|
|
|
|
|
{
|
|
|
|
|
$$ = $2;
|
|
|
|
|
$$->defaction = DEFELEM_ADD;
|
|
|
|
|
}
|
|
|
|
|
| DROP generic_option_name
|
|
|
|
|
{
|
2016-09-06 18:00:00 +02:00
|
|
|
$$ = makeDefElemExtended(NULL, $2, NULL, DEFELEM_DROP, @2);
|
2009-04-04 23:12:31 +02:00
|
|
|
}
|
2008-12-19 17:25:19 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
generic_option_elem:
|
2009-04-04 23:12:31 +02:00
|
|
|
generic_option_name generic_option_arg
|
|
|
|
|
{
|
2016-09-06 18:00:00 +02:00
|
|
|
$$ = makeDefElem($1, $2, @1);
|
2009-04-04 23:12:31 +02:00
|
|
|
}
|
2008-12-19 17:25:19 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
generic_option_name:
|
2009-04-04 23:12:31 +02:00
|
|
|
ColLabel { $$ = $1; }
|
2008-12-19 17:25:19 +01:00
|
|
|
;
|
|
|
|
|
|
2009-04-04 23:12:31 +02:00
|
|
|
/* We could use def_arg here, but the spec only requires string literals */
|
2008-12-19 17:25:19 +01:00
|
|
|
generic_option_arg:
|
2009-04-04 23:12:31 +02:00
|
|
|
Sconst { $$ = (Node *) makeString($1); }
|
2008-12-19 17:25:19 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2011-11-01 20:50:00 +01:00
|
|
|
* QUERY:
|
2008-12-19 17:25:19 +01:00
|
|
|
* CREATE SERVER name [TYPE] [VERSION] [OPTIONS]
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
CreateForeignServerStmt: CREATE SERVER name opt_type opt_foreign_server_version
|
|
|
|
|
FOREIGN DATA_P WRAPPER name create_generic_options
|
|
|
|
|
{
|
|
|
|
|
CreateForeignServerStmt *n = makeNode(CreateForeignServerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-12-19 17:25:19 +01:00
|
|
|
n->servername = $3;
|
|
|
|
|
n->servertype = $4;
|
|
|
|
|
n->version = $5;
|
|
|
|
|
n->fdwname = $9;
|
|
|
|
|
n->options = $10;
|
2017-03-20 21:40:45 +01:00
|
|
|
n->if_not_exists = false;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| CREATE SERVER IF_P NOT EXISTS name opt_type opt_foreign_server_version
|
|
|
|
|
FOREIGN DATA_P WRAPPER name create_generic_options
|
|
|
|
|
{
|
|
|
|
|
CreateForeignServerStmt *n = makeNode(CreateForeignServerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-03-20 21:40:45 +01:00
|
|
|
n->servername = $6;
|
|
|
|
|
n->servertype = $7;
|
|
|
|
|
n->version = $8;
|
|
|
|
|
n->fdwname = $12;
|
|
|
|
|
n->options = $13;
|
|
|
|
|
n->if_not_exists = true;
|
2008-12-19 17:25:19 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_type:
|
|
|
|
|
TYPE_P Sconst { $$ = $2; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
foreign_server_version:
|
|
|
|
|
VERSION_P Sconst { $$ = $2; }
|
|
|
|
|
| VERSION_P NULL_P { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_foreign_server_version:
|
2011-11-01 20:50:00 +01:00
|
|
|
foreign_server_version { $$ = $1; }
|
2008-12-19 17:25:19 +01:00
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2011-11-01 20:50:00 +01:00
|
|
|
* QUERY :
|
2008-12-19 17:25:19 +01:00
|
|
|
* ALTER SERVER name [VERSION] [OPTIONS]
|
|
|
|
|
*
|
|
|
|
|
****************************************************************************/
|
|
|
|
|
|
|
|
|
|
AlterForeignServerStmt: ALTER SERVER name foreign_server_version alter_generic_options
|
|
|
|
|
{
|
|
|
|
|
AlterForeignServerStmt *n = makeNode(AlterForeignServerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-12-19 17:25:19 +01:00
|
|
|
n->servername = $3;
|
|
|
|
|
n->version = $4;
|
|
|
|
|
n->options = $5;
|
|
|
|
|
n->has_version = true;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| ALTER SERVER name foreign_server_version
|
|
|
|
|
{
|
|
|
|
|
AlterForeignServerStmt *n = makeNode(AlterForeignServerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-12-19 17:25:19 +01:00
|
|
|
n->servername = $3;
|
|
|
|
|
n->version = $4;
|
|
|
|
|
n->has_version = true;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| ALTER SERVER name alter_generic_options
|
|
|
|
|
{
|
|
|
|
|
AlterForeignServerStmt *n = makeNode(AlterForeignServerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-12-19 17:25:19 +01:00
|
|
|
n->servername = $3;
|
|
|
|
|
n->options = $4;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2011-01-02 05:48:11 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2011-11-01 20:50:00 +01:00
|
|
|
* QUERY:
|
2011-01-02 05:48:11 +01:00
|
|
|
* CREATE FOREIGN TABLE relname (...) SERVER name (...)
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
CreateForeignTableStmt:
|
|
|
|
|
CREATE FOREIGN TABLE qualified_name
|
2013-03-12 22:37:07 +01:00
|
|
|
'(' OptTableElementList ')'
|
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
|
|
|
OptInherit SERVER name create_generic_options
|
2011-01-02 05:48:11 +01:00
|
|
|
{
|
|
|
|
|
CreateForeignTableStmt *n = makeNode(CreateForeignTableStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-01-02 05:48:11 +01:00
|
|
|
$4->relpersistence = RELPERSISTENCE_PERMANENT;
|
|
|
|
|
n->base.relation = $4;
|
2013-03-12 22:37:07 +01:00
|
|
|
n->base.tableElts = $6;
|
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
|
|
|
n->base.inhRelations = $8;
|
|
|
|
|
n->base.ofTypename = NULL;
|
|
|
|
|
n->base.constraints = NIL;
|
|
|
|
|
n->base.options = NIL;
|
|
|
|
|
n->base.oncommit = ONCOMMIT_NOOP;
|
|
|
|
|
n->base.tablespacename = NULL;
|
2011-01-02 05:48:11 +01:00
|
|
|
n->base.if_not_exists = false;
|
|
|
|
|
/* FDW-specific data */
|
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
|
|
|
n->servername = $10;
|
|
|
|
|
n->options = $11;
|
2011-01-02 05:48:11 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| CREATE FOREIGN TABLE IF_P NOT EXISTS qualified_name
|
2013-03-12 22:37:07 +01:00
|
|
|
'(' OptTableElementList ')'
|
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
|
|
|
OptInherit SERVER name create_generic_options
|
2011-01-02 05:48:11 +01:00
|
|
|
{
|
|
|
|
|
CreateForeignTableStmt *n = makeNode(CreateForeignTableStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-01-02 05:48:11 +01:00
|
|
|
$7->relpersistence = RELPERSISTENCE_PERMANENT;
|
|
|
|
|
n->base.relation = $7;
|
2013-03-12 22:37:07 +01:00
|
|
|
n->base.tableElts = $9;
|
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
|
|
|
n->base.inhRelations = $11;
|
|
|
|
|
n->base.ofTypename = NULL;
|
|
|
|
|
n->base.constraints = NIL;
|
|
|
|
|
n->base.options = NIL;
|
|
|
|
|
n->base.oncommit = ONCOMMIT_NOOP;
|
|
|
|
|
n->base.tablespacename = NULL;
|
2011-01-02 05:48:11 +01:00
|
|
|
n->base.if_not_exists = true;
|
|
|
|
|
/* FDW-specific data */
|
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
|
|
|
n->servername = $13;
|
|
|
|
|
n->options = $14;
|
2011-01-02 05:48:11 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
| CREATE FOREIGN TABLE qualified_name
|
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
|
|
|
PARTITION OF qualified_name OptTypedTableElementList PartitionBoundSpec
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
SERVER name create_generic_options
|
|
|
|
|
{
|
|
|
|
|
CreateForeignTableStmt *n = makeNode(CreateForeignTableStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
$4->relpersistence = RELPERSISTENCE_PERMANENT;
|
|
|
|
|
n->base.relation = $4;
|
|
|
|
|
n->base.inhRelations = list_make1($7);
|
|
|
|
|
n->base.tableElts = $8;
|
Code review focused on new node types added by partitioning support.
Fix failure to check that we got a plain Const from const-simplification of
a coercion request. This is the cause of bug #14666 from Tian Bing: there
is an int4 to money cast, but it's only stable not immutable (because of
dependence on lc_monetary), resulting in a FuncExpr that the code was
miserably unequipped to deal with, or indeed even to notice that it was
failing to deal with. Add test cases around this coercion behavior.
In view of the above, sprinkle the code liberally with castNode() macros,
in hope of catching the next such bug a bit sooner. Also, change some
functions that were randomly declared to take Node* to take more specific
pointer types. And change some struct fields that were declared Node*
but could be given more specific types, allowing removal of assorted
explicit casts.
Place PARTITION_MAX_KEYS check a bit closer to the code it's protecting.
Likewise check only-one-key-for-list-partitioning restriction in a less
random place.
Avoid not-per-project-style usages like !strcmp(...).
Fix assorted failures to avoid scribbling on the input of parse
transformation. I'm not sure how necessary this is, but it's entirely
silly for these functions to be expending cycles to avoid that and not
getting it right.
Add guards against partitioning on system columns.
Put backend/nodes/ support code into an order that matches handling
of these node types elsewhere.
Annotate the fact that somebody added location fields to PartitionBoundSpec
and PartitionRangeDatum but forgot to handle them in
outfuncs.c/readfuncs.c. This is fairly harmless for production purposes
(since readfuncs.c would just substitute -1 anyway) but it's still bogus.
It's not worth forcing a post-beta1 initdb just to fix this, but if we
have another reason to force initdb before 10.0, we should go back and
clean this up.
Contrariwise, somebody added location fields to PartitionElem and
PartitionSpec but forgot to teach exprLocation() about them.
Consolidate duplicative code in transformPartitionBound().
Improve a couple of error messages.
Improve assorted commentary.
Re-pgindent the files touched by this patch; this affects a few comment
blocks that must have been added quite recently.
Report: https://postgr.es/m/20170524024550.29935.14396@wrigleys.postgresql.org
2017-05-29 05:20:28 +02:00
|
|
|
n->base.partbound = $9;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
n->base.ofTypename = NULL;
|
|
|
|
|
n->base.constraints = NIL;
|
|
|
|
|
n->base.options = NIL;
|
|
|
|
|
n->base.oncommit = ONCOMMIT_NOOP;
|
|
|
|
|
n->base.tablespacename = NULL;
|
|
|
|
|
n->base.if_not_exists = false;
|
|
|
|
|
/* FDW-specific data */
|
|
|
|
|
n->servername = $11;
|
|
|
|
|
n->options = $12;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| CREATE FOREIGN TABLE IF_P NOT EXISTS qualified_name
|
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
|
|
|
PARTITION OF qualified_name OptTypedTableElementList PartitionBoundSpec
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
SERVER name create_generic_options
|
|
|
|
|
{
|
|
|
|
|
CreateForeignTableStmt *n = makeNode(CreateForeignTableStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
$7->relpersistence = RELPERSISTENCE_PERMANENT;
|
|
|
|
|
n->base.relation = $7;
|
|
|
|
|
n->base.inhRelations = list_make1($10);
|
|
|
|
|
n->base.tableElts = $11;
|
Code review focused on new node types added by partitioning support.
Fix failure to check that we got a plain Const from const-simplification of
a coercion request. This is the cause of bug #14666 from Tian Bing: there
is an int4 to money cast, but it's only stable not immutable (because of
dependence on lc_monetary), resulting in a FuncExpr that the code was
miserably unequipped to deal with, or indeed even to notice that it was
failing to deal with. Add test cases around this coercion behavior.
In view of the above, sprinkle the code liberally with castNode() macros,
in hope of catching the next such bug a bit sooner. Also, change some
functions that were randomly declared to take Node* to take more specific
pointer types. And change some struct fields that were declared Node*
but could be given more specific types, allowing removal of assorted
explicit casts.
Place PARTITION_MAX_KEYS check a bit closer to the code it's protecting.
Likewise check only-one-key-for-list-partitioning restriction in a less
random place.
Avoid not-per-project-style usages like !strcmp(...).
Fix assorted failures to avoid scribbling on the input of parse
transformation. I'm not sure how necessary this is, but it's entirely
silly for these functions to be expending cycles to avoid that and not
getting it right.
Add guards against partitioning on system columns.
Put backend/nodes/ support code into an order that matches handling
of these node types elsewhere.
Annotate the fact that somebody added location fields to PartitionBoundSpec
and PartitionRangeDatum but forgot to handle them in
outfuncs.c/readfuncs.c. This is fairly harmless for production purposes
(since readfuncs.c would just substitute -1 anyway) but it's still bogus.
It's not worth forcing a post-beta1 initdb just to fix this, but if we
have another reason to force initdb before 10.0, we should go back and
clean this up.
Contrariwise, somebody added location fields to PartitionElem and
PartitionSpec but forgot to teach exprLocation() about them.
Consolidate duplicative code in transformPartitionBound().
Improve a couple of error messages.
Improve assorted commentary.
Re-pgindent the files touched by this patch; this affects a few comment
blocks that must have been added quite recently.
Report: https://postgr.es/m/20170524024550.29935.14396@wrigleys.postgresql.org
2017-05-29 05:20:28 +02:00
|
|
|
n->base.partbound = $12;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
n->base.ofTypename = NULL;
|
|
|
|
|
n->base.constraints = NIL;
|
|
|
|
|
n->base.options = NIL;
|
|
|
|
|
n->base.oncommit = ONCOMMIT_NOOP;
|
|
|
|
|
n->base.tablespacename = NULL;
|
|
|
|
|
n->base.if_not_exists = true;
|
|
|
|
|
/* FDW-specific data */
|
|
|
|
|
n->servername = $14;
|
|
|
|
|
n->options = $15;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2011-01-02 05:48:11 +01:00
|
|
|
;
|
|
|
|
|
|
2014-07-10 21:01:31 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* QUERY:
|
|
|
|
|
* IMPORT FOREIGN SCHEMA remote_schema
|
|
|
|
|
* [ { LIMIT TO | EXCEPT } ( table_list ) ]
|
|
|
|
|
* FROM SERVER server_name INTO local_schema [ OPTIONS (...) ]
|
|
|
|
|
*
|
|
|
|
|
****************************************************************************/
|
|
|
|
|
|
|
|
|
|
ImportForeignSchemaStmt:
|
|
|
|
|
IMPORT_P FOREIGN SCHEMA name import_qualification
|
|
|
|
|
FROM SERVER name INTO name create_generic_options
|
|
|
|
|
{
|
|
|
|
|
ImportForeignSchemaStmt *n = makeNode(ImportForeignSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-07-10 21:01:31 +02:00
|
|
|
n->server_name = $8;
|
|
|
|
|
n->remote_schema = $4;
|
|
|
|
|
n->local_schema = $10;
|
|
|
|
|
n->list_type = $5->type;
|
|
|
|
|
n->table_list = $5->table_names;
|
|
|
|
|
n->options = $11;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
import_qualification_type:
|
2020-11-11 17:37:18 +01:00
|
|
|
LIMIT TO { $$ = FDW_IMPORT_SCHEMA_LIMIT_TO; }
|
|
|
|
|
| EXCEPT { $$ = FDW_IMPORT_SCHEMA_EXCEPT; }
|
2014-07-10 21:01:31 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
import_qualification:
|
|
|
|
|
import_qualification_type '(' relation_expr_list ')'
|
|
|
|
|
{
|
|
|
|
|
ImportQual *n = (ImportQual *) palloc(sizeof(ImportQual));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-07-10 21:01:31 +02:00
|
|
|
n->type = $1;
|
|
|
|
|
n->table_names = $3;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| /*EMPTY*/
|
|
|
|
|
{
|
|
|
|
|
ImportQual *n = (ImportQual *) palloc(sizeof(ImportQual));
|
|
|
|
|
n->type = FDW_IMPORT_SCHEMA_ALL;
|
|
|
|
|
n->table_names = NIL;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2008-12-19 17:25:19 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2011-11-01 20:50:00 +01:00
|
|
|
* QUERY:
|
2008-12-19 17:25:19 +01:00
|
|
|
* CREATE USER MAPPING FOR auth_ident SERVER name [OPTIONS]
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
CreateUserMappingStmt: CREATE USER MAPPING FOR auth_ident SERVER name create_generic_options
|
|
|
|
|
{
|
|
|
|
|
CreateUserMappingStmt *n = makeNode(CreateUserMappingStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
n->user = $5;
|
2008-12-19 17:25:19 +01:00
|
|
|
n->servername = $7;
|
|
|
|
|
n->options = $8;
|
2017-03-20 21:40:45 +01:00
|
|
|
n->if_not_exists = false;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| CREATE USER MAPPING IF_P NOT EXISTS FOR auth_ident SERVER name create_generic_options
|
|
|
|
|
{
|
|
|
|
|
CreateUserMappingStmt *n = makeNode(CreateUserMappingStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-03-20 21:40:45 +01:00
|
|
|
n->user = $8;
|
|
|
|
|
n->servername = $10;
|
|
|
|
|
n->options = $11;
|
|
|
|
|
n->if_not_exists = true;
|
2008-12-19 17:25:19 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/* User mapping authorization identifier */
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
auth_ident: RoleSpec { $$ = $1; }
|
|
|
|
|
| USER { $$ = makeRoleSpec(ROLESPEC_CURRENT_USER, @1); }
|
2008-12-19 17:25:19 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2011-11-01 20:50:00 +01:00
|
|
|
* QUERY :
|
2008-12-19 17:25:19 +01:00
|
|
|
* DROP USER MAPPING FOR auth_ident SERVER name
|
|
|
|
|
*
|
2016-08-13 00:45:18 +02:00
|
|
|
* XXX you'd think this should have a CASCADE/RESTRICT option, even if it's
|
|
|
|
|
* only pro forma; but the SQL standard doesn't show one.
|
2008-12-19 17:25:19 +01:00
|
|
|
****************************************************************************/
|
|
|
|
|
|
|
|
|
|
DropUserMappingStmt: DROP USER MAPPING FOR auth_ident SERVER name
|
|
|
|
|
{
|
|
|
|
|
DropUserMappingStmt *n = makeNode(DropUserMappingStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
n->user = $5;
|
2008-12-19 17:25:19 +01:00
|
|
|
n->servername = $7;
|
|
|
|
|
n->missing_ok = false;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| DROP USER MAPPING IF_P EXISTS FOR auth_ident SERVER name
|
2011-11-01 20:50:00 +01:00
|
|
|
{
|
2008-12-19 17:25:19 +01:00
|
|
|
DropUserMappingStmt *n = makeNode(DropUserMappingStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
n->user = $7;
|
2008-12-19 17:25:19 +01:00
|
|
|
n->servername = $9;
|
|
|
|
|
n->missing_ok = true;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2011-11-01 20:50:00 +01:00
|
|
|
* QUERY :
|
2008-12-19 17:25:19 +01:00
|
|
|
* ALTER USER MAPPING FOR auth_ident SERVER name OPTIONS
|
|
|
|
|
*
|
|
|
|
|
****************************************************************************/
|
|
|
|
|
|
|
|
|
|
AlterUserMappingStmt: ALTER USER MAPPING FOR auth_ident SERVER name alter_generic_options
|
|
|
|
|
{
|
|
|
|
|
AlterUserMappingStmt *n = makeNode(AlterUserMappingStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
n->user = $5;
|
2008-12-19 17:25:19 +01:00
|
|
|
n->servername = $7;
|
|
|
|
|
n->options = $8;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* QUERIES:
|
2016-12-05 21:50:55 +01:00
|
|
|
* CREATE POLICY name ON table
|
|
|
|
|
* [AS { PERMISSIVE | RESTRICTIVE } ]
|
|
|
|
|
* [FOR { SELECT | INSERT | UPDATE | DELETE } ]
|
|
|
|
|
* [TO role, ...]
|
|
|
|
|
* [USING (qual)] [WITH CHECK (with check qual)]
|
2015-03-25 18:16:47 +01:00
|
|
|
* ALTER POLICY name ON table [TO role, ...]
|
2016-12-05 21:50:55 +01:00
|
|
|
* [USING (qual)] [WITH CHECK (with check qual)]
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
CreatePolicyStmt:
|
2016-12-05 21:50:55 +01:00
|
|
|
CREATE POLICY name ON qualified_name RowSecurityDefaultPermissive
|
|
|
|
|
RowSecurityDefaultForCmd RowSecurityDefaultToRole
|
|
|
|
|
RowSecurityOptionalExpr RowSecurityOptionalWithCheck
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
{
|
|
|
|
|
CreatePolicyStmt *n = makeNode(CreatePolicyStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
n->policy_name = $3;
|
|
|
|
|
n->table = $5;
|
2016-12-05 21:50:55 +01:00
|
|
|
n->permissive = $6;
|
|
|
|
|
n->cmd_name = $7;
|
|
|
|
|
n->roles = $8;
|
|
|
|
|
n->qual = $9;
|
|
|
|
|
n->with_check = $10;
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
AlterPolicyStmt:
|
|
|
|
|
ALTER POLICY name ON qualified_name RowSecurityOptionalToRole
|
|
|
|
|
RowSecurityOptionalExpr RowSecurityOptionalWithCheck
|
|
|
|
|
{
|
|
|
|
|
AlterPolicyStmt *n = makeNode(AlterPolicyStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
n->policy_name = $3;
|
|
|
|
|
n->table = $5;
|
|
|
|
|
n->roles = $6;
|
|
|
|
|
n->qual = $7;
|
|
|
|
|
n->with_check = $8;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
RowSecurityOptionalExpr:
|
|
|
|
|
USING '(' a_expr ')' { $$ = $3; }
|
|
|
|
|
| /* EMPTY */ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
RowSecurityOptionalWithCheck:
|
|
|
|
|
WITH CHECK '(' a_expr ')' { $$ = $4; }
|
|
|
|
|
| /* EMPTY */ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
RowSecurityDefaultToRole:
|
|
|
|
|
TO role_list { $$ = $2; }
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
| /* EMPTY */ { $$ = list_make1(makeRoleSpec(ROLESPEC_PUBLIC, -1)); }
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
RowSecurityOptionalToRole:
|
|
|
|
|
TO role_list { $$ = $2; }
|
|
|
|
|
| /* EMPTY */ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
2016-12-05 21:50:55 +01:00
|
|
|
RowSecurityDefaultPermissive:
|
|
|
|
|
AS IDENT
|
|
|
|
|
{
|
|
|
|
|
if (strcmp($2, "permissive") == 0)
|
|
|
|
|
$$ = true;
|
|
|
|
|
else if (strcmp($2, "restrictive") == 0)
|
|
|
|
|
$$ = false;
|
|
|
|
|
else
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
2022-05-13 07:17:29 +02:00
|
|
|
errmsg("unrecognized row security option \"%s\"", $2),
|
2016-12-05 21:50:55 +01:00
|
|
|
errhint("Only PERMISSIVE or RESTRICTIVE policies are supported currently."),
|
2022-05-13 07:17:29 +02:00
|
|
|
parser_errposition(@2)));
|
2016-12-05 21:50:55 +01:00
|
|
|
|
|
|
|
|
}
|
|
|
|
|
| /* EMPTY */ { $$ = true; }
|
|
|
|
|
;
|
|
|
|
|
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
RowSecurityDefaultForCmd:
|
|
|
|
|
FOR row_security_cmd { $$ = $2; }
|
|
|
|
|
| /* EMPTY */ { $$ = "all"; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
row_security_cmd:
|
|
|
|
|
ALL { $$ = "all"; }
|
|
|
|
|
| SELECT { $$ = "select"; }
|
|
|
|
|
| INSERT { $$ = "insert"; }
|
|
|
|
|
| UPDATE { $$ = "update"; }
|
|
|
|
|
| DELETE_P { $$ = "delete"; }
|
|
|
|
|
;
|
|
|
|
|
|
2016-03-24 03:01:35 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* QUERY:
|
|
|
|
|
* CREATE ACCESS METHOD name HANDLER handler_name
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
CreateAmStmt: CREATE ACCESS METHOD name TYPE_P am_type HANDLER handler_name
|
2016-03-24 03:01:35 +01:00
|
|
|
{
|
|
|
|
|
CreateAmStmt *n = makeNode(CreateAmStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2016-03-24 03:01:35 +01:00
|
|
|
n->amname = $4;
|
|
|
|
|
n->handler_name = $8;
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
n->amtype = $6;
|
2016-03-24 03:01:35 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
am_type:
|
|
|
|
|
INDEX { $$ = AMTYPE_INDEX; }
|
|
|
|
|
| TABLE { $$ = AMTYPE_TABLE; }
|
|
|
|
|
;
|
|
|
|
|
|
1997-09-04 15:24:26 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* QUERIES :
|
|
|
|
|
* CREATE TRIGGER ...
|
1997-09-04 15:24:26 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
CreateTrigStmt:
|
2020-11-14 23:05:34 +01:00
|
|
|
CREATE opt_or_replace TRIGGER name TriggerActionTime TriggerEvents ON
|
2016-11-04 16:49:50 +01:00
|
|
|
qualified_name TriggerReferencing TriggerForSpec TriggerWhen
|
2018-08-15 23:08:34 +02:00
|
|
|
EXECUTE FUNCTION_or_PROCEDURE func_name '(' TriggerFuncArgs ')'
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
|
|
|
|
CreateTrigStmt *n = makeNode(CreateTrigStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2020-11-14 23:05:34 +01:00
|
|
|
n->replace = $2;
|
|
|
|
|
n->isconstraint = false;
|
|
|
|
|
n->trigname = $4;
|
|
|
|
|
n->relation = $8;
|
|
|
|
|
n->funcname = $14;
|
|
|
|
|
n->args = $16;
|
|
|
|
|
n->row = $10;
|
|
|
|
|
n->timing = $5;
|
|
|
|
|
n->events = intVal(linitial($6));
|
|
|
|
|
n->columns = (List *) lsecond($6);
|
|
|
|
|
n->whenClause = $11;
|
|
|
|
|
n->transitionRels = $9;
|
2021-03-25 10:17:52 +01:00
|
|
|
n->deferrable = false;
|
|
|
|
|
n->initdeferred = false;
|
2002-03-21 17:02:16 +01:00
|
|
|
n->constrrel = NULL;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1999-09-29 18:06:40 +02:00
|
|
|
}
|
2020-11-14 23:05:34 +01:00
|
|
|
| CREATE opt_or_replace CONSTRAINT TRIGGER name AFTER TriggerEvents ON
|
2009-11-20 21:38:12 +01:00
|
|
|
qualified_name OptConstrFromTable ConstraintAttributeSpec
|
|
|
|
|
FOR EACH ROW TriggerWhen
|
2018-08-15 23:08:34 +02:00
|
|
|
EXECUTE FUNCTION_or_PROCEDURE func_name '(' TriggerFuncArgs ')'
|
1999-09-29 18:06:40 +02:00
|
|
|
{
|
|
|
|
|
CreateTrigStmt *n = makeNode(CreateTrigStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2020-11-14 23:05:34 +01:00
|
|
|
n->replace = $2;
|
|
|
|
|
if (n->replace) /* not supported, see CreateTrigger */
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
|
errmsg("CREATE OR REPLACE CONSTRAINT TRIGGER is not supported")));
|
|
|
|
|
n->isconstraint = true;
|
|
|
|
|
n->trigname = $5;
|
|
|
|
|
n->relation = $9;
|
|
|
|
|
n->funcname = $18;
|
|
|
|
|
n->args = $20;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->row = true;
|
2010-10-10 19:43:33 +02:00
|
|
|
n->timing = TRIGGER_TYPE_AFTER;
|
2020-11-14 23:05:34 +01:00
|
|
|
n->events = intVal(linitial($7));
|
|
|
|
|
n->columns = (List *) lsecond($7);
|
|
|
|
|
n->whenClause = $15;
|
2016-11-04 16:49:50 +01:00
|
|
|
n->transitionRels = NIL;
|
2020-11-14 23:05:34 +01:00
|
|
|
processCASbits($11, @11, "TRIGGER",
|
2011-06-16 01:05:11 +02:00
|
|
|
&n->deferrable, &n->initdeferred, NULL,
|
2012-07-24 21:49:54 +02:00
|
|
|
NULL, yyscanner);
|
2020-11-14 23:05:34 +01:00
|
|
|
n->constrrel = $10;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
TriggerActionTime:
|
2010-10-10 19:43:33 +02:00
|
|
|
BEFORE { $$ = TRIGGER_TYPE_BEFORE; }
|
|
|
|
|
| AFTER { $$ = TRIGGER_TYPE_AFTER; }
|
|
|
|
|
| INSTEAD OF { $$ = TRIGGER_TYPE_INSTEAD; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
TriggerEvents:
|
|
|
|
|
TriggerOneEvent
|
2009-06-18 03:27:02 +02:00
|
|
|
{ $$ = $1; }
|
|
|
|
|
| TriggerEvents OR TriggerOneEvent
|
1998-02-11 05:09:54 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
int events1 = intVal(linitial($1));
|
|
|
|
|
int events2 = intVal(linitial($3));
|
|
|
|
|
List *columns1 = (List *) lsecond($1);
|
|
|
|
|
List *columns2 = (List *) lsecond($3);
|
2009-10-15 00:14:25 +02:00
|
|
|
|
|
|
|
|
if (events1 & events2)
|
2009-07-13 04:02:20 +02:00
|
|
|
parser_yyerror("duplicate trigger events specified");
|
2009-10-15 00:14:25 +02:00
|
|
|
/*
|
|
|
|
|
* concat'ing the columns lists loses information about
|
|
|
|
|
* which columns went with which event, but so long as
|
|
|
|
|
* only UPDATE carries columns and we disallow multiple
|
|
|
|
|
* UPDATE items, it doesn't matter. Command execution
|
|
|
|
|
* should just ignore the columns for non-UPDATE events.
|
|
|
|
|
*/
|
|
|
|
|
$$ = list_make2(makeInteger(events1 | events2),
|
|
|
|
|
list_concat(columns1, columns2));
|
1998-02-11 05:09:54 +01:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
TriggerOneEvent:
|
2009-10-15 00:14:25 +02:00
|
|
|
INSERT
|
|
|
|
|
{ $$ = list_make2(makeInteger(TRIGGER_TYPE_INSERT), NIL); }
|
|
|
|
|
| DELETE_P
|
|
|
|
|
{ $$ = list_make2(makeInteger(TRIGGER_TYPE_DELETE), NIL); }
|
|
|
|
|
| UPDATE
|
|
|
|
|
{ $$ = list_make2(makeInteger(TRIGGER_TYPE_UPDATE), NIL); }
|
|
|
|
|
| UPDATE OF columnList
|
|
|
|
|
{ $$ = list_make2(makeInteger(TRIGGER_TYPE_UPDATE), $3); }
|
|
|
|
|
| TRUNCATE
|
|
|
|
|
{ $$ = list_make2(makeInteger(TRIGGER_TYPE_TRUNCATE), NIL); }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
2016-11-04 16:49:50 +01:00
|
|
|
TriggerReferencing:
|
|
|
|
|
REFERENCING TriggerTransitions { $$ = $2; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
TriggerTransitions:
|
|
|
|
|
TriggerTransition { $$ = list_make1($1); }
|
|
|
|
|
| TriggerTransitions TriggerTransition { $$ = lappend($1, $2); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
TriggerTransition:
|
|
|
|
|
TransitionOldOrNew TransitionRowOrTable opt_as TransitionRelName
|
|
|
|
|
{
|
|
|
|
|
TriggerTransition *n = makeNode(TriggerTransition);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2016-11-04 16:49:50 +01:00
|
|
|
n->name = $4;
|
|
|
|
|
n->isNew = $1;
|
|
|
|
|
n->isTable = $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2016-11-04 16:49:50 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
TransitionOldOrNew:
|
2017-08-16 06:22:32 +02:00
|
|
|
NEW { $$ = true; }
|
|
|
|
|
| OLD { $$ = false; }
|
2016-11-04 16:49:50 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
TransitionRowOrTable:
|
2017-08-16 06:22:32 +02:00
|
|
|
TABLE { $$ = true; }
|
2016-11-04 16:49:50 +01:00
|
|
|
/*
|
|
|
|
|
* According to the standard, lack of a keyword here implies ROW.
|
|
|
|
|
* Support for that would require prohibiting ROW entirely here,
|
|
|
|
|
* reserving the keyword ROW, and/or requiring AS (instead of
|
|
|
|
|
* allowing it to be optional, as the standard specifies) as the
|
|
|
|
|
* next token. Requiring ROW seems cleanest and easiest to
|
|
|
|
|
* explain.
|
|
|
|
|
*/
|
2017-08-16 06:22:32 +02:00
|
|
|
| ROW { $$ = false; }
|
2016-11-04 16:49:50 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
TransitionRelName:
|
|
|
|
|
ColId { $$ = $1; }
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
TriggerForSpec:
|
2010-10-10 19:43:33 +02:00
|
|
|
FOR TriggerForOptEach TriggerForType
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
1998-02-11 05:09:54 +01:00
|
|
|
$$ = $3;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2002-11-23 04:59:09 +01:00
|
|
|
| /* EMPTY */
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* If ROW/STATEMENT not specified, default to
|
|
|
|
|
* STATEMENT, per SQL
|
|
|
|
|
*/
|
2017-08-16 06:22:32 +02:00
|
|
|
$$ = false;
|
2002-11-23 04:59:09 +01:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1997-09-04 15:24:26 +02:00
|
|
|
|
2010-10-10 19:43:33 +02:00
|
|
|
TriggerForOptEach:
|
2020-11-12 07:48:36 +01:00
|
|
|
EACH
|
|
|
|
|
| /*EMPTY*/
|
1998-02-11 05:09:54 +01:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
TriggerForType:
|
2017-08-16 06:22:32 +02:00
|
|
|
ROW { $$ = true; }
|
|
|
|
|
| STATEMENT { $$ = false; }
|
1998-02-11 05:09:54 +01:00
|
|
|
;
|
|
|
|
|
|
2009-11-20 21:38:12 +01:00
|
|
|
TriggerWhen:
|
|
|
|
|
WHEN '(' a_expr ')' { $$ = $3; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
2018-08-15 23:08:34 +02:00
|
|
|
FUNCTION_or_PROCEDURE:
|
|
|
|
|
FUNCTION
|
|
|
|
|
| PROCEDURE
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
TriggerFuncArgs:
|
2004-05-31 01:40:41 +02:00
|
|
|
TriggerFuncArg { $$ = list_make1($1); }
|
2002-06-18 02:28:11 +02:00
|
|
|
| TriggerFuncArgs ',' TriggerFuncArg { $$ = lappend($1, $3); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
TriggerFuncArg:
|
2008-11-12 16:50:20 +01:00
|
|
|
Iconst
|
1998-02-11 05:09:54 +01:00
|
|
|
{
|
Remove Value node struct
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and the node
type don't match most of the time, and so it has to be treated
specially a lot. There doesn't seem to be any value in the special
construct. There is very little code that wants to accept all Value
variants but nothing else (and even if it did, this doesn't provide
any convenient way to check it), and most code wants either just one
particular node type (usually String), or it accepts a broader set of
node types besides just Value.
This change removes the Value struct and node type and replaces them
by separate Integer, Float, String, and BitString node types that are
proper node types and structs of their own and behave mostly like
normal node types.
Also, this removes the T_Null node tag, which was previously also a
possible variant of Value but wasn't actually used outside of the
Value contained in A_Const. Replace that by an isnull field in
A_Const.
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/5ba6bc5b-3f95-04f2-2419-f8ddb4c046fb@enterprisedb.com
2021-09-09 07:58:12 +02:00
|
|
|
$$ = (Node *) makeString(psprintf("%d", $1));
|
2000-08-12 01:45:35 +02:00
|
|
|
}
|
Remove Value node struct
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and the node
type don't match most of the time, and so it has to be treated
specially a lot. There doesn't seem to be any value in the special
construct. There is very little code that wants to accept all Value
variants but nothing else (and even if it did, this doesn't provide
any convenient way to check it), and most code wants either just one
particular node type (usually String), or it accepts a broader set of
node types besides just Value.
This change removes the Value struct and node type and replaces them
by separate Integer, Float, String, and BitString node types that are
proper node types and structs of their own and behave mostly like
normal node types.
Also, this removes the T_Null node tag, which was previously also a
possible variant of Value but wasn't actually used outside of the
Value contained in A_Const. Replace that by an isnull field in
A_Const.
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/5ba6bc5b-3f95-04f2-2419-f8ddb4c046fb@enterprisedb.com
2021-09-09 07:58:12 +02:00
|
|
|
| FCONST { $$ = (Node *) makeString($1); }
|
|
|
|
|
| Sconst { $$ = (Node *) makeString($1); }
|
|
|
|
|
| ColLabel { $$ = (Node *) makeString($1); }
|
2002-06-17 22:27:43 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
OptConstrFromTable:
|
|
|
|
|
FROM qualified_name { $$ = $2; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1997-09-04 15:24:26 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
ConstraintAttributeSpec:
|
2011-06-16 01:05:11 +02:00
|
|
|
/*EMPTY*/
|
|
|
|
|
{ $$ = 0; }
|
|
|
|
|
| ConstraintAttributeSpec ConstraintAttributeElem
|
1999-09-29 18:06:40 +02:00
|
|
|
{
|
2011-06-16 01:05:11 +02:00
|
|
|
/*
|
|
|
|
|
* We must complain about conflicting options.
|
|
|
|
|
* We could, but choose not to, complain about redundant
|
|
|
|
|
* options (ie, where $2's bit is already set in $1).
|
|
|
|
|
*/
|
|
|
|
|
int newspec = $1 | $2;
|
|
|
|
|
|
|
|
|
|
/* special message for this case */
|
|
|
|
|
if ((newspec & (CAS_NOT_DEFERRABLE | CAS_INITIALLY_DEFERRED)) == (CAS_NOT_DEFERRABLE | CAS_INITIALLY_DEFERRED))
|
2003-07-19 22:20:53 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
2008-09-01 22:42:46 +02:00
|
|
|
errmsg("constraint declared INITIALLY DEFERRED must be DEFERRABLE"),
|
2011-06-16 01:05:11 +02:00
|
|
|
parser_errposition(@2)));
|
|
|
|
|
/* generic message for other conflicts */
|
|
|
|
|
if ((newspec & (CAS_NOT_DEFERRABLE | CAS_DEFERRABLE)) == (CAS_NOT_DEFERRABLE | CAS_DEFERRABLE) ||
|
|
|
|
|
(newspec & (CAS_INITIALLY_IMMEDIATE | CAS_INITIALLY_DEFERRED)) == (CAS_INITIALLY_IMMEDIATE | CAS_INITIALLY_DEFERRED))
|
2003-07-19 22:20:53 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
2011-06-16 01:05:11 +02:00
|
|
|
errmsg("conflicting constraint properties"),
|
|
|
|
|
parser_errposition(@2)));
|
|
|
|
|
$$ = newspec;
|
2002-06-17 22:27:43 +02:00
|
|
|
}
|
1999-09-29 18:06:40 +02:00
|
|
|
;
|
|
|
|
|
|
2011-06-16 01:05:11 +02:00
|
|
|
ConstraintAttributeElem:
|
|
|
|
|
NOT DEFERRABLE { $$ = CAS_NOT_DEFERRABLE; }
|
|
|
|
|
| DEFERRABLE { $$ = CAS_DEFERRABLE; }
|
|
|
|
|
| INITIALLY IMMEDIATE { $$ = CAS_INITIALLY_IMMEDIATE; }
|
|
|
|
|
| INITIALLY DEFERRED { $$ = CAS_INITIALLY_DEFERRED; }
|
|
|
|
|
| NOT VALID { $$ = CAS_NOT_VALID; }
|
2012-07-24 21:49:54 +02:00
|
|
|
| NO INHERIT { $$ = CAS_NO_INHERIT; }
|
1999-09-29 18:06:40 +02:00
|
|
|
;
|
1999-12-10 04:01:05 +01:00
|
|
|
|
1999-09-29 18:06:40 +02:00
|
|
|
|
2012-07-18 16:16:16 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* QUERIES :
|
|
|
|
|
* CREATE EVENT TRIGGER ...
|
|
|
|
|
* ALTER EVENT TRIGGER ...
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
CreateEventTrigStmt:
|
|
|
|
|
CREATE EVENT TRIGGER name ON ColLabel
|
2018-10-01 23:02:55 +02:00
|
|
|
EXECUTE FUNCTION_or_PROCEDURE func_name '(' ')'
|
2012-07-18 16:16:16 +02:00
|
|
|
{
|
|
|
|
|
CreateEventTrigStmt *n = makeNode(CreateEventTrigStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-07-18 16:16:16 +02:00
|
|
|
n->trigname = $4;
|
|
|
|
|
n->eventname = $6;
|
|
|
|
|
n->whenclause = NULL;
|
|
|
|
|
n->funcname = $9;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-07-18 16:16:16 +02:00
|
|
|
}
|
|
|
|
|
| CREATE EVENT TRIGGER name ON ColLabel
|
|
|
|
|
WHEN event_trigger_when_list
|
2018-10-01 23:02:55 +02:00
|
|
|
EXECUTE FUNCTION_or_PROCEDURE func_name '(' ')'
|
2012-07-18 16:16:16 +02:00
|
|
|
{
|
|
|
|
|
CreateEventTrigStmt *n = makeNode(CreateEventTrigStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-07-18 16:16:16 +02:00
|
|
|
n->trigname = $4;
|
|
|
|
|
n->eventname = $6;
|
|
|
|
|
n->whenclause = $8;
|
|
|
|
|
n->funcname = $11;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-07-18 16:16:16 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
event_trigger_when_list:
|
|
|
|
|
event_trigger_when_item
|
|
|
|
|
{ $$ = list_make1($1); }
|
|
|
|
|
| event_trigger_when_list AND event_trigger_when_item
|
|
|
|
|
{ $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
event_trigger_when_item:
|
|
|
|
|
ColId IN_P '(' event_trigger_value_list ')'
|
2016-09-06 18:00:00 +02:00
|
|
|
{ $$ = makeDefElem($1, (Node *) $4, @1); }
|
2012-07-18 16:16:16 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
event_trigger_value_list:
|
|
|
|
|
SCONST
|
|
|
|
|
{ $$ = list_make1(makeString($1)); }
|
|
|
|
|
| event_trigger_value_list ',' SCONST
|
|
|
|
|
{ $$ = lappend($1, makeString($3)); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
AlterEventTrigStmt:
|
|
|
|
|
ALTER EVENT TRIGGER name enable_trigger
|
|
|
|
|
{
|
|
|
|
|
AlterEventTrigStmt *n = makeNode(AlterEventTrigStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-07-18 16:16:16 +02:00
|
|
|
n->trigname = $4;
|
|
|
|
|
n->tgenabled = $5;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
enable_trigger:
|
|
|
|
|
ENABLE_P { $$ = TRIGGER_FIRES_ON_ORIGIN; }
|
|
|
|
|
| ENABLE_P REPLICA { $$ = TRIGGER_FIRES_ON_REPLICA; }
|
|
|
|
|
| ENABLE_P ALWAYS { $$ = TRIGGER_FIRES_ALWAYS; }
|
|
|
|
|
| DISABLE_P { $$ = TRIGGER_DISABLED; }
|
|
|
|
|
;
|
|
|
|
|
|
2002-04-21 21:21:49 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2018-09-26 13:26:24 +02:00
|
|
|
* QUERY :
|
2002-04-21 21:21:49 +02:00
|
|
|
* CREATE ASSERTION ...
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2018-09-26 13:26:24 +02:00
|
|
|
CreateAssertionStmt:
|
|
|
|
|
CREATE ASSERTION any_name CHECK '(' a_expr ')' ConstraintAttributeSpec
|
2002-04-21 21:21:49 +02:00
|
|
|
{
|
2003-07-19 22:20:53 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
|
errmsg("CREATE ASSERTION is not yet implemented")));
|
2002-04-21 21:21:49 +02:00
|
|
|
|
2018-09-26 13:26:24 +02:00
|
|
|
$$ = NULL;
|
2002-04-21 21:21:49 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* QUERY :
|
2000-12-22 08:07:58 +01:00
|
|
|
* define (aggregate,operator,type)
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
DefineStmt:
|
2019-03-19 02:16:50 +01:00
|
|
|
CREATE opt_or_replace AGGREGATE func_name aggr_args definition
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2000-04-07 15:40:45 +02:00
|
|
|
DefineStmt *n = makeNode(DefineStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-06-27 16:45:32 +02:00
|
|
|
n->kind = OBJECT_AGGREGATE;
|
2006-04-15 19:45:46 +02:00
|
|
|
n->oldstyle = false;
|
2019-03-19 02:16:50 +01:00
|
|
|
n->replace = $2;
|
|
|
|
|
n->defnames = $4;
|
|
|
|
|
n->args = $5;
|
|
|
|
|
n->definition = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2006-04-15 19:45:46 +02:00
|
|
|
}
|
2019-03-19 02:16:50 +01:00
|
|
|
| CREATE opt_or_replace AGGREGATE func_name old_aggr_definition
|
2006-04-15 19:45:46 +02:00
|
|
|
{
|
|
|
|
|
/* old-style (pre-8.2) syntax for CREATE AGGREGATE */
|
|
|
|
|
DefineStmt *n = makeNode(DefineStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2006-04-15 19:45:46 +02:00
|
|
|
n->kind = OBJECT_AGGREGATE;
|
|
|
|
|
n->oldstyle = true;
|
2019-03-19 02:16:50 +01:00
|
|
|
n->replace = $2;
|
|
|
|
|
n->defnames = $4;
|
2006-04-15 19:45:46 +02:00
|
|
|
n->args = NIL;
|
2019-03-19 02:16:50 +01:00
|
|
|
n->definition = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-12-22 08:07:58 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| CREATE OPERATOR any_operator definition
|
2000-12-22 08:07:58 +01:00
|
|
|
{
|
|
|
|
|
DefineStmt *n = makeNode(DefineStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-06-27 16:45:32 +02:00
|
|
|
n->kind = OBJECT_OPERATOR;
|
2006-04-15 19:45:46 +02:00
|
|
|
n->oldstyle = false;
|
2002-04-17 01:08:12 +02:00
|
|
|
n->defnames = $3;
|
2006-04-15 19:45:46 +02:00
|
|
|
n->args = NIL;
|
2000-12-22 08:07:58 +01:00
|
|
|
n->definition = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-12-22 08:07:58 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| CREATE TYPE_P any_name definition
|
2000-12-22 08:07:58 +01:00
|
|
|
{
|
|
|
|
|
DefineStmt *n = makeNode(DefineStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-06-27 16:45:32 +02:00
|
|
|
n->kind = OBJECT_TYPE;
|
2006-04-15 19:45:46 +02:00
|
|
|
n->oldstyle = false;
|
2002-03-29 20:06:29 +01:00
|
|
|
n->defnames = $3;
|
2006-04-15 19:45:46 +02:00
|
|
|
n->args = NIL;
|
2000-04-07 15:40:45 +02:00
|
|
|
n->definition = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2006-12-30 22:21:56 +01:00
|
|
|
| CREATE TYPE_P any_name
|
2006-02-28 23:37:27 +01:00
|
|
|
{
|
|
|
|
|
/* Shell type (identified by lack of definition) */
|
|
|
|
|
DefineStmt *n = makeNode(DefineStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2006-02-28 23:37:27 +01:00
|
|
|
n->kind = OBJECT_TYPE;
|
2006-04-15 19:45:46 +02:00
|
|
|
n->oldstyle = false;
|
2006-02-28 23:37:27 +01:00
|
|
|
n->defnames = $3;
|
2006-04-15 19:45:46 +02:00
|
|
|
n->args = NIL;
|
2006-02-28 23:37:27 +01:00
|
|
|
n->definition = NIL;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2006-02-28 23:37:27 +01:00
|
|
|
}
|
2010-09-26 13:41:03 +02:00
|
|
|
| CREATE TYPE_P any_name AS '(' OptTableFuncElementList ')'
|
2002-08-15 18:36:08 +02:00
|
|
|
{
|
|
|
|
|
CompositeTypeStmt *n = makeNode(CompositeTypeStmt);
|
|
|
|
|
|
2002-08-29 02:17:06 +02:00
|
|
|
/* can't use qualified_name, sigh */
|
2010-09-26 13:41:03 +02:00
|
|
|
n->typevar = makeRangeVarFromAnyName($3, @3, yyscanner);
|
2002-08-29 02:17:06 +02:00
|
|
|
n->coldeflist = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-08-15 18:36:08 +02:00
|
|
|
}
|
2009-12-26 17:55:21 +01:00
|
|
|
| CREATE TYPE_P any_name AS ENUM_P '(' opt_enum_val_list ')'
|
2007-04-02 05:49:42 +02:00
|
|
|
{
|
|
|
|
|
CreateEnumStmt *n = makeNode(CreateEnumStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-07-16 08:33:46 +02:00
|
|
|
n->typeName = $3;
|
2007-04-02 05:49:42 +02:00
|
|
|
n->vals = $7;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-04-02 05:49:42 +02:00
|
|
|
}
|
2011-11-03 12:16:28 +01:00
|
|
|
| CREATE TYPE_P any_name AS RANGE definition
|
|
|
|
|
{
|
|
|
|
|
CreateRangeStmt *n = makeNode(CreateRangeStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-11-03 12:16:28 +01:00
|
|
|
n->typeName = $3;
|
2021-07-14 23:54:56 +02:00
|
|
|
n->params = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-11-03 12:16:28 +01:00
|
|
|
}
|
2007-08-21 17:13:42 +02:00
|
|
|
| CREATE TEXT_P SEARCH PARSER any_name definition
|
2007-08-21 03:11:32 +02:00
|
|
|
{
|
|
|
|
|
DefineStmt *n = makeNode(DefineStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-08-21 03:11:32 +02:00
|
|
|
n->kind = OBJECT_TSPARSER;
|
|
|
|
|
n->args = NIL;
|
|
|
|
|
n->defnames = $5;
|
|
|
|
|
n->definition = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-08-21 03:11:32 +02:00
|
|
|
}
|
2007-08-21 17:13:42 +02:00
|
|
|
| CREATE TEXT_P SEARCH DICTIONARY any_name definition
|
2007-08-21 03:11:32 +02:00
|
|
|
{
|
|
|
|
|
DefineStmt *n = makeNode(DefineStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-08-21 03:11:32 +02:00
|
|
|
n->kind = OBJECT_TSDICTIONARY;
|
|
|
|
|
n->args = NIL;
|
|
|
|
|
n->defnames = $5;
|
|
|
|
|
n->definition = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-08-21 03:11:32 +02:00
|
|
|
}
|
2007-08-21 17:13:42 +02:00
|
|
|
| CREATE TEXT_P SEARCH TEMPLATE any_name definition
|
2007-08-21 03:11:32 +02:00
|
|
|
{
|
|
|
|
|
DefineStmt *n = makeNode(DefineStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-08-21 03:11:32 +02:00
|
|
|
n->kind = OBJECT_TSTEMPLATE;
|
|
|
|
|
n->args = NIL;
|
|
|
|
|
n->defnames = $5;
|
|
|
|
|
n->definition = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-08-21 03:11:32 +02:00
|
|
|
}
|
2007-08-21 17:13:42 +02:00
|
|
|
| CREATE TEXT_P SEARCH CONFIGURATION any_name definition
|
2007-08-21 03:11:32 +02:00
|
|
|
{
|
|
|
|
|
DefineStmt *n = makeNode(DefineStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-08-21 03:11:32 +02:00
|
|
|
n->kind = OBJECT_TSCONFIGURATION;
|
|
|
|
|
n->args = NIL;
|
|
|
|
|
n->defnames = $5;
|
|
|
|
|
n->definition = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-08-21 03:11:32 +02:00
|
|
|
}
|
2011-02-12 14:54:13 +01:00
|
|
|
| CREATE COLLATION any_name definition
|
|
|
|
|
{
|
|
|
|
|
DefineStmt *n = makeNode(DefineStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-02-12 14:54:13 +01:00
|
|
|
n->kind = OBJECT_COLLATION;
|
|
|
|
|
n->args = NIL;
|
|
|
|
|
n->defnames = $3;
|
|
|
|
|
n->definition = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-02-12 14:54:13 +01:00
|
|
|
}
|
2017-02-09 04:51:09 +01:00
|
|
|
| CREATE COLLATION IF_P NOT EXISTS any_name definition
|
|
|
|
|
{
|
|
|
|
|
DefineStmt *n = makeNode(DefineStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-02-09 04:51:09 +01:00
|
|
|
n->kind = OBJECT_COLLATION;
|
|
|
|
|
n->args = NIL;
|
|
|
|
|
n->defnames = $6;
|
|
|
|
|
n->definition = $7;
|
|
|
|
|
n->if_not_exists = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-02-09 04:51:09 +01:00
|
|
|
}
|
2011-02-12 14:54:13 +01:00
|
|
|
| CREATE COLLATION any_name FROM any_name
|
|
|
|
|
{
|
|
|
|
|
DefineStmt *n = makeNode(DefineStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-02-12 14:54:13 +01:00
|
|
|
n->kind = OBJECT_COLLATION;
|
|
|
|
|
n->args = NIL;
|
|
|
|
|
n->defnames = $3;
|
2016-09-06 18:00:00 +02:00
|
|
|
n->definition = list_make1(makeDefElem("from", (Node *) $5, @5));
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-02-12 14:54:13 +01:00
|
|
|
}
|
2017-02-09 04:51:09 +01:00
|
|
|
| CREATE COLLATION IF_P NOT EXISTS any_name FROM any_name
|
|
|
|
|
{
|
|
|
|
|
DefineStmt *n = makeNode(DefineStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-02-09 04:51:09 +01:00
|
|
|
n->kind = OBJECT_COLLATION;
|
|
|
|
|
n->args = NIL;
|
|
|
|
|
n->defnames = $6;
|
|
|
|
|
n->definition = list_make1(makeDefElem("from", (Node *) $8, @8));
|
|
|
|
|
n->if_not_exists = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-02-09 04:51:09 +01:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
definition: '(' def_list ')' { $$ = $2; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2011-11-01 20:50:00 +01:00
|
|
|
def_list: def_elem { $$ = list_make1($1); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| def_list ',' def_elem { $$ = lappend($1, $3); }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2017-05-12 14:57:01 +02:00
|
|
|
def_elem: ColLabel '=' def_arg
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2016-09-06 18:00:00 +02:00
|
|
|
$$ = makeDefElem($1, (Node *) $3, @1);
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2017-05-12 14:57:01 +02:00
|
|
|
| ColLabel
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2016-09-06 18:00:00 +02:00
|
|
|
$$ = makeDefElem($1, NULL, @1);
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2001-11-10 23:31:49 +01:00
|
|
|
/* Note: any simple identifier will be returned as a type name! */
|
2022-05-13 07:17:29 +02:00
|
|
|
def_arg: func_type { $$ = (Node *) $1; }
|
|
|
|
|
| reserved_keyword { $$ = (Node *) makeString(pstrdup($1)); }
|
|
|
|
|
| qual_all_Op { $$ = (Node *) $1; }
|
|
|
|
|
| NumericOnly { $$ = (Node *) $1; }
|
|
|
|
|
| Sconst { $$ = (Node *) makeString($1); }
|
|
|
|
|
| NONE { $$ = (Node *) makeString(pstrdup($1)); }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2006-04-15 19:45:46 +02:00
|
|
|
old_aggr_definition: '(' old_aggr_list ')' { $$ = $2; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
old_aggr_list: old_aggr_elem { $$ = list_make1($1); }
|
|
|
|
|
| old_aggr_list ',' old_aggr_elem { $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
2008-12-28 19:54:01 +01:00
|
|
|
/*
|
|
|
|
|
* Must use IDENT here to avoid reduce/reduce conflicts; fortunately none of
|
|
|
|
|
* the item names needed in old aggregate definitions are likely to become
|
|
|
|
|
* SQL keywords.
|
|
|
|
|
*/
|
2006-04-15 19:45:46 +02:00
|
|
|
old_aggr_elem: IDENT '=' def_arg
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem($1, (Node *) $3, @1);
|
2006-04-15 19:45:46 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2009-12-26 17:55:21 +01:00
|
|
|
opt_enum_val_list:
|
|
|
|
|
enum_val_list { $$ = $1; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
2007-04-02 05:49:42 +02:00
|
|
|
enum_val_list: Sconst
|
|
|
|
|
{ $$ = list_make1(makeString($1)); }
|
|
|
|
|
| enum_val_list ',' Sconst
|
|
|
|
|
{ $$ = lappend($1, makeString($3)); }
|
|
|
|
|
;
|
|
|
|
|
|
2010-10-25 05:04:37 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* ALTER TYPE enumtype ADD ...
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
AlterEnumStmt:
|
2012-09-22 18:53:31 +02:00
|
|
|
ALTER TYPE_P any_name ADD_P VALUE_P opt_if_not_exists Sconst
|
2011-11-01 20:50:00 +01:00
|
|
|
{
|
|
|
|
|
AlterEnumStmt *n = makeNode(AlterEnumStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-11-01 20:50:00 +01:00
|
|
|
n->typeName = $3;
|
2016-09-07 22:11:56 +02:00
|
|
|
n->oldVal = NULL;
|
2012-09-22 18:53:31 +02:00
|
|
|
n->newVal = $7;
|
2011-11-01 20:50:00 +01:00
|
|
|
n->newValNeighbor = NULL;
|
|
|
|
|
n->newValIsAfter = true;
|
2016-09-07 22:11:56 +02:00
|
|
|
n->skipIfNewValExists = $6;
|
2011-11-01 20:50:00 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2012-09-22 18:53:31 +02:00
|
|
|
| ALTER TYPE_P any_name ADD_P VALUE_P opt_if_not_exists Sconst BEFORE Sconst
|
2011-11-01 20:50:00 +01:00
|
|
|
{
|
|
|
|
|
AlterEnumStmt *n = makeNode(AlterEnumStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-11-01 20:50:00 +01:00
|
|
|
n->typeName = $3;
|
2016-09-07 22:11:56 +02:00
|
|
|
n->oldVal = NULL;
|
2012-09-22 18:53:31 +02:00
|
|
|
n->newVal = $7;
|
|
|
|
|
n->newValNeighbor = $9;
|
2011-11-01 20:50:00 +01:00
|
|
|
n->newValIsAfter = false;
|
2016-09-07 22:11:56 +02:00
|
|
|
n->skipIfNewValExists = $6;
|
2011-11-01 20:50:00 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2012-09-22 18:53:31 +02:00
|
|
|
| ALTER TYPE_P any_name ADD_P VALUE_P opt_if_not_exists Sconst AFTER Sconst
|
2011-11-01 20:50:00 +01:00
|
|
|
{
|
|
|
|
|
AlterEnumStmt *n = makeNode(AlterEnumStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-11-01 20:50:00 +01:00
|
|
|
n->typeName = $3;
|
2016-09-07 22:11:56 +02:00
|
|
|
n->oldVal = NULL;
|
2012-09-22 18:53:31 +02:00
|
|
|
n->newVal = $7;
|
|
|
|
|
n->newValNeighbor = $9;
|
2011-11-01 20:50:00 +01:00
|
|
|
n->newValIsAfter = true;
|
2016-09-07 22:11:56 +02:00
|
|
|
n->skipIfNewValExists = $6;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| ALTER TYPE_P any_name RENAME VALUE_P Sconst TO Sconst
|
|
|
|
|
{
|
|
|
|
|
AlterEnumStmt *n = makeNode(AlterEnumStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2016-09-07 22:11:56 +02:00
|
|
|
n->typeName = $3;
|
|
|
|
|
n->oldVal = $6;
|
|
|
|
|
n->newVal = $8;
|
|
|
|
|
n->newValNeighbor = NULL;
|
|
|
|
|
n->newValIsAfter = false;
|
|
|
|
|
n->skipIfNewValExists = false;
|
2011-11-01 20:50:00 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2010-10-25 05:04:37 +02:00
|
|
|
;
|
|
|
|
|
|
2012-09-22 18:53:31 +02:00
|
|
|
opt_if_not_exists: IF_P NOT EXISTS { $$ = true; }
|
2020-11-16 11:54:52 +01:00
|
|
|
| /* EMPTY */ { $$ = false; }
|
2013-11-10 15:20:52 +01:00
|
|
|
;
|
2012-09-22 18:53:31 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-07-30 00:14:11 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* QUERIES :
|
|
|
|
|
* CREATE OPERATOR CLASS ...
|
2007-01-23 06:07:18 +01:00
|
|
|
* CREATE OPERATOR FAMILY ...
|
|
|
|
|
* ALTER OPERATOR FAMILY ...
|
2002-07-30 00:14:11 +02:00
|
|
|
* DROP OPERATOR CLASS ...
|
2007-01-23 06:07:18 +01:00
|
|
|
* DROP OPERATOR FAMILY ...
|
2002-07-30 00:14:11 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
CreateOpClassStmt:
|
|
|
|
|
CREATE OPERATOR CLASS any_name opt_default FOR TYPE_P Typename
|
2020-06-10 22:58:46 +02:00
|
|
|
USING name opt_opfamily AS opclass_item_list
|
2002-07-30 00:14:11 +02:00
|
|
|
{
|
|
|
|
|
CreateOpClassStmt *n = makeNode(CreateOpClassStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-07-30 00:14:11 +02:00
|
|
|
n->opclassname = $4;
|
|
|
|
|
n->isDefault = $5;
|
|
|
|
|
n->datatype = $8;
|
|
|
|
|
n->amname = $10;
|
2007-01-23 06:07:18 +01:00
|
|
|
n->opfamilyname = $11;
|
|
|
|
|
n->items = $13;
|
2002-07-30 00:14:11 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opclass_item_list:
|
2004-05-31 01:40:41 +02:00
|
|
|
opclass_item { $$ = list_make1($1); }
|
2002-07-30 00:14:11 +02:00
|
|
|
| opclass_item_list ',' opclass_item { $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opclass_item:
|
2010-11-24 20:20:39 +01:00
|
|
|
OPERATOR Iconst any_operator opclass_purpose opt_recheck
|
2002-07-30 00:14:11 +02:00
|
|
|
{
|
|
|
|
|
CreateOpClassItem *n = makeNode(CreateOpClassItem);
|
2016-12-28 18:00:00 +01:00
|
|
|
ObjectWithArgs *owa = makeNode(ObjectWithArgs);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2016-12-28 18:00:00 +01:00
|
|
|
owa->objname = $3;
|
|
|
|
|
owa->objargs = NIL;
|
2002-07-30 00:14:11 +02:00
|
|
|
n->itemtype = OPCLASS_ITEM_OPERATOR;
|
2016-12-28 18:00:00 +01:00
|
|
|
n->name = owa;
|
2002-07-30 00:14:11 +02:00
|
|
|
n->number = $2;
|
2010-11-24 20:20:39 +01:00
|
|
|
n->order_family = $4;
|
2002-07-30 00:14:11 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2016-12-28 18:00:00 +01:00
|
|
|
| OPERATOR Iconst operator_with_argtypes opclass_purpose
|
2010-11-24 20:20:39 +01:00
|
|
|
opt_recheck
|
2002-07-30 00:14:11 +02:00
|
|
|
{
|
|
|
|
|
CreateOpClassItem *n = makeNode(CreateOpClassItem);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-07-30 00:14:11 +02:00
|
|
|
n->itemtype = OPCLASS_ITEM_OPERATOR;
|
2016-12-28 18:00:00 +01:00
|
|
|
n->name = $3;
|
2002-07-30 00:14:11 +02:00
|
|
|
n->number = $2;
|
2016-12-28 18:00:00 +01:00
|
|
|
n->order_family = $4;
|
2002-07-30 00:14:11 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2016-09-15 19:00:00 +02:00
|
|
|
| FUNCTION Iconst function_with_argtypes
|
2002-07-30 00:14:11 +02:00
|
|
|
{
|
|
|
|
|
CreateOpClassItem *n = makeNode(CreateOpClassItem);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-07-30 00:14:11 +02:00
|
|
|
n->itemtype = OPCLASS_ITEM_FUNCTION;
|
2016-12-28 18:00:00 +01:00
|
|
|
n->name = $3;
|
2002-07-30 00:14:11 +02:00
|
|
|
n->number = $2;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2016-09-15 19:00:00 +02:00
|
|
|
| FUNCTION Iconst '(' type_list ')' function_with_argtypes
|
2007-01-23 06:07:18 +01:00
|
|
|
{
|
|
|
|
|
CreateOpClassItem *n = makeNode(CreateOpClassItem);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-01-23 06:07:18 +01:00
|
|
|
n->itemtype = OPCLASS_ITEM_FUNCTION;
|
2016-12-28 18:00:00 +01:00
|
|
|
n->name = $6;
|
2007-01-23 06:07:18 +01:00
|
|
|
n->number = $2;
|
|
|
|
|
n->class_args = $4;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2002-07-30 00:14:11 +02:00
|
|
|
| STORAGE Typename
|
|
|
|
|
{
|
|
|
|
|
CreateOpClassItem *n = makeNode(CreateOpClassItem);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-07-30 00:14:11 +02:00
|
|
|
n->itemtype = OPCLASS_ITEM_STORAGETYPE;
|
|
|
|
|
n->storedtype = $2;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
opt_default: DEFAULT { $$ = true; }
|
|
|
|
|
| /*EMPTY*/ { $$ = false; }
|
2007-01-23 06:07:18 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_opfamily: FAMILY any_name { $$ = $2; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
2010-11-24 20:20:39 +01:00
|
|
|
opclass_purpose: FOR SEARCH { $$ = NIL; }
|
|
|
|
|
| FOR ORDER BY any_name { $$ = $4; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
2008-04-14 19:05:34 +02:00
|
|
|
opt_recheck: RECHECK
|
|
|
|
|
{
|
2009-05-27 22:42:29 +02:00
|
|
|
/*
|
|
|
|
|
* RECHECK no longer does anything in opclass definitions,
|
|
|
|
|
* but we still accept it to ease porting of old database
|
|
|
|
|
* dumps.
|
|
|
|
|
*/
|
|
|
|
|
ereport(NOTICE,
|
2008-04-14 19:05:34 +02:00
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
2009-05-27 22:42:29 +02:00
|
|
|
errmsg("RECHECK is no longer required"),
|
2008-09-01 22:42:46 +02:00
|
|
|
errhint("Update your data type."),
|
2009-07-13 04:02:20 +02:00
|
|
|
parser_errposition(@1)));
|
2017-08-16 06:22:32 +02:00
|
|
|
$$ = true;
|
2008-04-14 19:05:34 +02:00
|
|
|
}
|
2017-08-16 06:22:32 +02:00
|
|
|
| /*EMPTY*/ { $$ = false; }
|
2007-01-23 06:07:18 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CreateOpFamilyStmt:
|
2020-06-10 22:58:46 +02:00
|
|
|
CREATE OPERATOR FAMILY any_name USING name
|
2007-01-23 06:07:18 +01:00
|
|
|
{
|
|
|
|
|
CreateOpFamilyStmt *n = makeNode(CreateOpFamilyStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-01-23 06:07:18 +01:00
|
|
|
n->opfamilyname = $4;
|
|
|
|
|
n->amname = $6;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
AlterOpFamilyStmt:
|
2020-06-10 22:58:46 +02:00
|
|
|
ALTER OPERATOR FAMILY any_name USING name ADD_P opclass_item_list
|
2007-01-23 06:07:18 +01:00
|
|
|
{
|
|
|
|
|
AlterOpFamilyStmt *n = makeNode(AlterOpFamilyStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-01-23 06:07:18 +01:00
|
|
|
n->opfamilyname = $4;
|
|
|
|
|
n->amname = $6;
|
|
|
|
|
n->isDrop = false;
|
|
|
|
|
n->items = $8;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2020-06-10 22:58:46 +02:00
|
|
|
| ALTER OPERATOR FAMILY any_name USING name DROP opclass_drop_list
|
2007-01-23 06:07:18 +01:00
|
|
|
{
|
|
|
|
|
AlterOpFamilyStmt *n = makeNode(AlterOpFamilyStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-01-23 06:07:18 +01:00
|
|
|
n->opfamilyname = $4;
|
|
|
|
|
n->amname = $6;
|
|
|
|
|
n->isDrop = true;
|
|
|
|
|
n->items = $8;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opclass_drop_list:
|
|
|
|
|
opclass_drop { $$ = list_make1($1); }
|
|
|
|
|
| opclass_drop_list ',' opclass_drop { $$ = lappend($1, $3); }
|
2002-07-30 00:14:11 +02:00
|
|
|
;
|
|
|
|
|
|
2007-01-23 06:07:18 +01:00
|
|
|
opclass_drop:
|
|
|
|
|
OPERATOR Iconst '(' type_list ')'
|
|
|
|
|
{
|
|
|
|
|
CreateOpClassItem *n = makeNode(CreateOpClassItem);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-01-23 06:07:18 +01:00
|
|
|
n->itemtype = OPCLASS_ITEM_OPERATOR;
|
|
|
|
|
n->number = $2;
|
2016-12-28 18:00:00 +01:00
|
|
|
n->class_args = $4;
|
2007-01-23 06:07:18 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| FUNCTION Iconst '(' type_list ')'
|
|
|
|
|
{
|
|
|
|
|
CreateOpClassItem *n = makeNode(CreateOpClassItem);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-01-23 06:07:18 +01:00
|
|
|
n->itemtype = OPCLASS_ITEM_FUNCTION;
|
|
|
|
|
n->number = $2;
|
2016-12-28 18:00:00 +01:00
|
|
|
n->class_args = $4;
|
2007-01-23 06:07:18 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2002-07-30 00:14:11 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
DropOpClassStmt:
|
2020-06-10 22:58:46 +02:00
|
|
|
DROP OPERATOR CLASS any_name USING name opt_drop_behavior
|
2002-07-30 00:14:11 +02:00
|
|
|
{
|
2011-11-18 03:31:29 +01:00
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2015-03-16 16:06:34 +01:00
|
|
|
n->objects = list_make1(lcons(makeString($6), $4));
|
2011-11-18 03:31:29 +01:00
|
|
|
n->removeType = OBJECT_OPCLASS;
|
2002-07-30 00:14:11 +02:00
|
|
|
n->behavior = $7;
|
2006-06-16 22:23:45 +02:00
|
|
|
n->missing_ok = false;
|
2012-04-06 11:21:40 +02:00
|
|
|
n->concurrent = false;
|
2006-06-16 22:23:45 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2020-06-10 22:58:46 +02:00
|
|
|
| DROP OPERATOR CLASS IF_P EXISTS any_name USING name opt_drop_behavior
|
2006-06-16 22:23:45 +02:00
|
|
|
{
|
2011-11-18 03:31:29 +01:00
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2015-03-16 16:06:34 +01:00
|
|
|
n->objects = list_make1(lcons(makeString($8), $6));
|
2011-11-18 03:31:29 +01:00
|
|
|
n->removeType = OBJECT_OPCLASS;
|
2006-06-16 22:23:45 +02:00
|
|
|
n->behavior = $9;
|
|
|
|
|
n->missing_ok = true;
|
2012-04-06 11:21:40 +02:00
|
|
|
n->concurrent = false;
|
2002-07-30 00:14:11 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2007-01-23 06:07:18 +01:00
|
|
|
DropOpFamilyStmt:
|
2020-06-10 22:58:46 +02:00
|
|
|
DROP OPERATOR FAMILY any_name USING name opt_drop_behavior
|
2007-01-23 06:07:18 +01:00
|
|
|
{
|
2011-11-18 03:31:29 +01:00
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2015-03-16 16:06:34 +01:00
|
|
|
n->objects = list_make1(lcons(makeString($6), $4));
|
2011-11-18 03:31:29 +01:00
|
|
|
n->removeType = OBJECT_OPFAMILY;
|
2007-01-23 06:07:18 +01:00
|
|
|
n->behavior = $7;
|
|
|
|
|
n->missing_ok = false;
|
2012-04-06 11:21:40 +02:00
|
|
|
n->concurrent = false;
|
2007-01-23 06:07:18 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2020-06-10 22:58:46 +02:00
|
|
|
| DROP OPERATOR FAMILY IF_P EXISTS any_name USING name opt_drop_behavior
|
2007-01-23 06:07:18 +01:00
|
|
|
{
|
2011-11-18 03:31:29 +01:00
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2015-03-16 16:06:34 +01:00
|
|
|
n->objects = list_make1(lcons(makeString($8), $6));
|
2011-11-18 03:31:29 +01:00
|
|
|
n->removeType = OBJECT_OPFAMILY;
|
2007-01-23 06:07:18 +01:00
|
|
|
n->behavior = $9;
|
|
|
|
|
n->missing_ok = true;
|
2012-04-06 11:21:40 +02:00
|
|
|
n->concurrent = false;
|
2007-01-23 06:07:18 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
2005-11-21 13:49:33 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* QUERY:
|
|
|
|
|
*
|
|
|
|
|
* DROP OWNED BY username [, username ...] [ RESTRICT | CASCADE ]
|
|
|
|
|
* REASSIGN OWNED BY username [, username ...] TO username
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
DropOwnedStmt:
|
2014-01-22 04:49:22 +01:00
|
|
|
DROP OWNED BY role_list opt_drop_behavior
|
2011-11-01 20:50:00 +01:00
|
|
|
{
|
2005-11-21 13:49:33 +01:00
|
|
|
DropOwnedStmt *n = makeNode(DropOwnedStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-11-21 13:49:33 +01:00
|
|
|
n->roles = $4;
|
|
|
|
|
n->behavior = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-11-21 13:49:33 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
ReassignOwnedStmt:
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
REASSIGN OWNED BY role_list TO RoleSpec
|
2005-11-21 13:49:33 +01:00
|
|
|
{
|
|
|
|
|
ReassignOwnedStmt *n = makeNode(ReassignOwnedStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-11-21 13:49:33 +01:00
|
|
|
n->roles = $4;
|
|
|
|
|
n->newrole = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-11-21 13:49:33 +01:00
|
|
|
}
|
|
|
|
|
;
|
2002-07-30 00:14:11 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* QUERY:
|
2000-10-23 01:32:48 +02:00
|
|
|
*
|
2006-12-30 22:21:56 +01:00
|
|
|
* DROP itemtype [ IF EXISTS ] itemname [, itemname ...]
|
2005-11-19 18:39:45 +01:00
|
|
|
* [ RESTRICT | CASCADE ]
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2020-06-13 09:03:28 +02:00
|
|
|
DropStmt: DROP object_type_any_name IF_P EXISTS any_name_list opt_drop_behavior
|
2000-10-18 18:16:18 +02:00
|
|
|
{
|
|
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2000-10-23 01:32:48 +02:00
|
|
|
n->removeType = $2;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = true;
|
2005-11-19 18:39:45 +01:00
|
|
|
n->objects = $5;
|
|
|
|
|
n->behavior = $6;
|
2012-04-06 11:21:40 +02:00
|
|
|
n->concurrent = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-11-19 18:39:45 +01:00
|
|
|
}
|
2020-06-13 09:03:28 +02:00
|
|
|
| DROP object_type_any_name any_name_list opt_drop_behavior
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
{
|
|
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->removeType = $2;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = false;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->objects = $3;
|
|
|
|
|
n->behavior = $4;
|
|
|
|
|
n->concurrent = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
}
|
|
|
|
|
| DROP drop_type_name IF_P EXISTS name_list opt_drop_behavior
|
|
|
|
|
{
|
|
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->removeType = $2;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = true;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->objects = $5;
|
|
|
|
|
n->behavior = $6;
|
|
|
|
|
n->concurrent = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
}
|
|
|
|
|
| DROP drop_type_name name_list opt_drop_behavior
|
2005-11-19 18:39:45 +01:00
|
|
|
{
|
|
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-11-19 18:39:45 +01:00
|
|
|
n->removeType = $2;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = false;
|
2002-03-21 17:02:16 +01:00
|
|
|
n->objects = $3;
|
2002-03-19 03:18:25 +01:00
|
|
|
n->behavior = $4;
|
2012-04-06 11:21:40 +02:00
|
|
|
n->concurrent = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-04-06 11:21:40 +02:00
|
|
|
}
|
2020-06-13 09:03:28 +02:00
|
|
|
| DROP object_type_name_on_any_name name ON any_name opt_drop_behavior
|
2017-02-22 05:10:07 +01:00
|
|
|
{
|
|
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-02-22 05:10:07 +01:00
|
|
|
n->removeType = $2;
|
|
|
|
|
n->objects = list_make1(lappend($5, makeString($3)));
|
|
|
|
|
n->behavior = $6;
|
|
|
|
|
n->missing_ok = false;
|
|
|
|
|
n->concurrent = false;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2020-06-13 09:03:28 +02:00
|
|
|
| DROP object_type_name_on_any_name IF_P EXISTS name ON any_name opt_drop_behavior
|
2017-02-22 05:10:07 +01:00
|
|
|
{
|
|
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-02-22 05:10:07 +01:00
|
|
|
n->removeType = $2;
|
|
|
|
|
n->objects = list_make1(lappend($7, makeString($5)));
|
|
|
|
|
n->behavior = $8;
|
|
|
|
|
n->missing_ok = true;
|
|
|
|
|
n->concurrent = false;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2014-12-30 17:57:23 +01:00
|
|
|
| DROP TYPE_P type_name_list opt_drop_behavior
|
|
|
|
|
{
|
|
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-12-30 17:57:23 +01:00
|
|
|
n->removeType = OBJECT_TYPE;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = false;
|
2014-12-30 17:57:23 +01:00
|
|
|
n->objects = $3;
|
|
|
|
|
n->behavior = $4;
|
|
|
|
|
n->concurrent = false;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| DROP TYPE_P IF_P EXISTS type_name_list opt_drop_behavior
|
|
|
|
|
{
|
|
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-12-30 17:57:23 +01:00
|
|
|
n->removeType = OBJECT_TYPE;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = true;
|
2014-12-30 17:57:23 +01:00
|
|
|
n->objects = $5;
|
|
|
|
|
n->behavior = $6;
|
|
|
|
|
n->concurrent = false;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| DROP DOMAIN_P type_name_list opt_drop_behavior
|
|
|
|
|
{
|
|
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-12-30 17:57:23 +01:00
|
|
|
n->removeType = OBJECT_DOMAIN;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = false;
|
2014-12-30 17:57:23 +01:00
|
|
|
n->objects = $3;
|
|
|
|
|
n->behavior = $4;
|
|
|
|
|
n->concurrent = false;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| DROP DOMAIN_P IF_P EXISTS type_name_list opt_drop_behavior
|
|
|
|
|
{
|
|
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-12-30 17:57:23 +01:00
|
|
|
n->removeType = OBJECT_DOMAIN;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = true;
|
2014-12-30 17:57:23 +01:00
|
|
|
n->objects = $5;
|
|
|
|
|
n->behavior = $6;
|
|
|
|
|
n->concurrent = false;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2012-04-06 11:21:40 +02:00
|
|
|
| DROP INDEX CONCURRENTLY any_name_list opt_drop_behavior
|
|
|
|
|
{
|
|
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-04-06 11:21:40 +02:00
|
|
|
n->removeType = OBJECT_INDEX;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = false;
|
2012-04-06 11:21:40 +02:00
|
|
|
n->objects = $4;
|
|
|
|
|
n->behavior = $5;
|
|
|
|
|
n->concurrent = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-04-06 11:21:40 +02:00
|
|
|
}
|
|
|
|
|
| DROP INDEX CONCURRENTLY IF_P EXISTS any_name_list opt_drop_behavior
|
|
|
|
|
{
|
|
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-04-06 11:21:40 +02:00
|
|
|
n->removeType = OBJECT_INDEX;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = true;
|
2012-04-06 11:21:40 +02:00
|
|
|
n->objects = $6;
|
|
|
|
|
n->behavior = $7;
|
|
|
|
|
n->concurrent = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
|
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2020-06-13 09:03:28 +02:00
|
|
|
/* object types taking any_name/any_name_list */
|
|
|
|
|
object_type_any_name:
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
TABLE { $$ = OBJECT_TABLE; }
|
2003-06-27 16:45:32 +02:00
|
|
|
| SEQUENCE { $$ = OBJECT_SEQUENCE; }
|
|
|
|
|
| VIEW { $$ = OBJECT_VIEW; }
|
2013-03-04 01:23:31 +01:00
|
|
|
| MATERIALIZED VIEW { $$ = OBJECT_MATVIEW; }
|
2003-06-27 16:45:32 +02:00
|
|
|
| INDEX { $$ = OBJECT_INDEX; }
|
2011-01-02 05:48:11 +01:00
|
|
|
| FOREIGN TABLE { $$ = OBJECT_FOREIGN_TABLE; }
|
2011-02-12 14:54:13 +01:00
|
|
|
| COLLATION { $$ = OBJECT_COLLATION; }
|
2003-06-27 16:45:32 +02:00
|
|
|
| CONVERSION_P { $$ = OBJECT_CONVERSION; }
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
| STATISTICS { $$ = OBJECT_STATISTIC_EXT; }
|
2007-08-21 17:13:42 +02:00
|
|
|
| TEXT_P SEARCH PARSER { $$ = OBJECT_TSPARSER; }
|
|
|
|
|
| TEXT_P SEARCH DICTIONARY { $$ = OBJECT_TSDICTIONARY; }
|
|
|
|
|
| TEXT_P SEARCH TEMPLATE { $$ = OBJECT_TSTEMPLATE; }
|
|
|
|
|
| TEXT_P SEARCH CONFIGURATION { $$ = OBJECT_TSCONFIGURATION; }
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
;
|
|
|
|
|
|
2020-06-13 09:03:28 +02:00
|
|
|
/*
|
|
|
|
|
* object types taking name/name_list
|
|
|
|
|
*
|
|
|
|
|
* DROP handles some of them separately
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
object_type_name:
|
|
|
|
|
drop_type_name { $$ = $1; }
|
|
|
|
|
| DATABASE { $$ = OBJECT_DATABASE; }
|
|
|
|
|
| ROLE { $$ = OBJECT_ROLE; }
|
|
|
|
|
| SUBSCRIPTION { $$ = OBJECT_SUBSCRIPTION; }
|
|
|
|
|
| TABLESPACE { $$ = OBJECT_TABLESPACE; }
|
|
|
|
|
;
|
|
|
|
|
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
drop_type_name:
|
|
|
|
|
ACCESS METHOD { $$ = OBJECT_ACCESS_METHOD; }
|
|
|
|
|
| EVENT TRIGGER { $$ = OBJECT_EVENT_TRIGGER; }
|
|
|
|
|
| EXTENSION { $$ = OBJECT_EXTENSION; }
|
2017-02-22 05:10:07 +01:00
|
|
|
| FOREIGN DATA_P WRAPPER { $$ = OBJECT_FDW; }
|
2020-06-11 11:18:15 +02:00
|
|
|
| opt_procedural LANGUAGE { $$ = OBJECT_LANGUAGE; }
|
2017-01-19 18:00:00 +01:00
|
|
|
| PUBLICATION { $$ = OBJECT_PUBLICATION; }
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
| SCHEMA { $$ = OBJECT_SCHEMA; }
|
2017-02-22 05:10:07 +01:00
|
|
|
| SERVER { $$ = OBJECT_FOREIGN_SERVER; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/* object types attached to a table */
|
2020-06-13 09:03:28 +02:00
|
|
|
object_type_name_on_any_name:
|
2017-02-22 05:10:07 +01:00
|
|
|
POLICY { $$ = OBJECT_POLICY; }
|
|
|
|
|
| RULE { $$ = OBJECT_RULE; }
|
|
|
|
|
| TRIGGER { $$ = OBJECT_TRIGGER; }
|
2000-10-23 01:32:48 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
any_name_list:
|
2004-05-31 01:40:41 +02:00
|
|
|
any_name { $$ = list_make1($1); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| any_name_list ',' any_name { $$ = lappend($1, $3); }
|
2002-03-29 20:06:29 +01:00
|
|
|
;
|
|
|
|
|
|
2004-05-31 01:40:41 +02:00
|
|
|
any_name: ColId { $$ = list_make1(makeString($1)); }
|
2004-06-09 21:08:20 +02:00
|
|
|
| ColId attrs { $$ = lcons(makeString($1), $2); }
|
2002-03-29 20:06:29 +01:00
|
|
|
;
|
|
|
|
|
|
2004-06-09 21:08:20 +02:00
|
|
|
attrs: '.' attr_name
|
|
|
|
|
{ $$ = list_make1(makeString($2)); }
|
2004-11-08 05:02:20 +01:00
|
|
|
| attrs '.' attr_name
|
|
|
|
|
{ $$ = lappend($1, makeString($3)); }
|
2004-06-09 21:08:20 +02:00
|
|
|
;
|
|
|
|
|
|
2014-12-30 17:57:23 +01:00
|
|
|
type_name_list:
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
Typename { $$ = list_make1($1); }
|
|
|
|
|
| type_name_list ',' Typename { $$ = lappend($1, $3); }
|
2019-02-24 18:51:50 +01:00
|
|
|
;
|
2004-06-09 21:08:20 +02:00
|
|
|
|
1999-09-23 19:03:39 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* QUERY:
|
2005-01-27 04:19:37 +01:00
|
|
|
* truncate table relname1, relname2, ...
|
1999-09-23 19:03:39 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
TruncateStmt:
|
2009-01-12 09:54:27 +01:00
|
|
|
TRUNCATE opt_table relation_expr_list opt_restart_seqs opt_drop_behavior
|
1999-09-23 19:03:39 +02:00
|
|
|
{
|
|
|
|
|
TruncateStmt *n = makeNode(TruncateStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-01-27 04:19:37 +01:00
|
|
|
n->relations = $3;
|
2008-05-17 01:36:05 +02:00
|
|
|
n->restart_seqs = $4;
|
|
|
|
|
n->behavior = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1999-09-23 19:03:39 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2008-05-17 01:36:05 +02:00
|
|
|
opt_restart_seqs:
|
|
|
|
|
CONTINUE_P IDENTITY_P { $$ = false; }
|
|
|
|
|
| RESTART IDENTITY_P { $$ = true; }
|
|
|
|
|
| /* EMPTY */ { $$ = false; }
|
|
|
|
|
;
|
|
|
|
|
|
This patch implements ORACLE's COMMENT SQL command.
>From the ORACLE 7 SQL Language Reference Manual:
-----------------------------------------------------
COMMENT
Purpose:
To add a comment about a table, view, snapshot, or
column into the data dictionary.
Prerequisites:
The table, view, or snapshot must be in your own
schema
or you must have COMMENT ANY TABLE system privilege.
Syntax:
COMMENT ON [ TABLE table ] |
[ COLUMN table.column] IS 'text'
You can effectively drop a comment from the database
by setting it to the empty string ''.
-----------------------------------------------------
Example:
COMMENT ON TABLE workorders IS
'Maintains base records for workorder information';
COMMENT ON COLUMN workorders.hours IS
'Number of hours the engineer worked on the task';
to drop a comment:
COMMENT ON COLUMN workorders.hours IS '';
The current patch will simply perform the insert into
pg_description, as per the TODO. And, of course, when
the table is dropped, any comments relating to it
or any of its attributes are also dropped. I haven't
looked at the ODBC source yet, but I do know from
an ODBC client standpoint that the standard does
support the notion of table and column comments.
Hopefully the ODBC driver is already fetching these
values from pg_description, but if not, it should be
trivial.
Hope this makes the grade,
Mike Mascari
(mascarim@yahoo.com)
1999-10-15 03:49:49 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2020-06-13 09:03:28 +02:00
|
|
|
* COMMENT ON <object> IS <text>
|
This patch implements ORACLE's COMMENT SQL command.
>From the ORACLE 7 SQL Language Reference Manual:
-----------------------------------------------------
COMMENT
Purpose:
To add a comment about a table, view, snapshot, or
column into the data dictionary.
Prerequisites:
The table, view, or snapshot must be in your own
schema
or you must have COMMENT ANY TABLE system privilege.
Syntax:
COMMENT ON [ TABLE table ] |
[ COLUMN table.column] IS 'text'
You can effectively drop a comment from the database
by setting it to the empty string ''.
-----------------------------------------------------
Example:
COMMENT ON TABLE workorders IS
'Maintains base records for workorder information';
COMMENT ON COLUMN workorders.hours IS
'Number of hours the engineer worked on the task';
to drop a comment:
COMMENT ON COLUMN workorders.hours IS '';
The current patch will simply perform the insert into
pg_description, as per the TODO. And, of course, when
the table is dropped, any comments relating to it
or any of its attributes are also dropped. I haven't
looked at the ODBC source yet, but I do know from
an ODBC client standpoint that the standard does
support the notion of table and column comments.
Hopefully the ODBC driver is already fetching these
values from pg_description, but if not, it should be
trivial.
Hope this makes the grade,
Mike Mascari
(mascarim@yahoo.com)
1999-10-15 03:49:49 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
2002-06-17 07:40:32 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
CommentStmt:
|
2020-06-13 09:03:28 +02:00
|
|
|
COMMENT ON object_type_any_name any_name IS comment_text
|
2002-06-17 22:27:43 +02:00
|
|
|
{
|
|
|
|
|
CommentStmt *n = makeNode(CommentStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
n->objtype = $3;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $4;
|
|
|
|
|
n->comment = $6;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2020-06-13 09:03:28 +02:00
|
|
|
| COMMENT ON COLUMN any_name IS comment_text
|
|
|
|
|
{
|
|
|
|
|
CommentStmt *n = makeNode(CommentStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2020-06-13 09:03:28 +02:00
|
|
|
n->objtype = OBJECT_COLUMN;
|
|
|
|
|
n->object = (Node *) $4;
|
|
|
|
|
n->comment = $6;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| COMMENT ON object_type_name name IS comment_text
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
{
|
|
|
|
|
CommentStmt *n = makeNode(CommentStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->objtype = $3;
|
|
|
|
|
n->object = (Node *) makeString($4);
|
2002-06-17 22:27:43 +02:00
|
|
|
n->comment = $6;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2014-12-30 17:57:23 +01:00
|
|
|
| COMMENT ON TYPE_P Typename IS comment_text
|
|
|
|
|
{
|
|
|
|
|
CommentStmt *n = makeNode(CommentStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-12-30 17:57:23 +01:00
|
|
|
n->objtype = OBJECT_TYPE;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $4;
|
2014-12-30 17:57:23 +01:00
|
|
|
n->comment = $6;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| COMMENT ON DOMAIN_P Typename IS comment_text
|
|
|
|
|
{
|
|
|
|
|
CommentStmt *n = makeNode(CommentStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-12-30 17:57:23 +01:00
|
|
|
n->objtype = OBJECT_DOMAIN;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $4;
|
2014-12-30 17:57:23 +01:00
|
|
|
n->comment = $6;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2016-09-15 19:00:00 +02:00
|
|
|
| COMMENT ON AGGREGATE aggregate_with_argtypes IS comment_text
|
2002-06-17 22:27:43 +02:00
|
|
|
{
|
|
|
|
|
CommentStmt *n = makeNode(CommentStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-06-27 16:45:32 +02:00
|
|
|
n->objtype = OBJECT_AGGREGATE;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $4;
|
2016-09-15 19:00:00 +02:00
|
|
|
n->comment = $6;
|
2002-06-17 22:27:43 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2016-09-15 19:00:00 +02:00
|
|
|
| COMMENT ON FUNCTION function_with_argtypes IS comment_text
|
2002-06-17 22:27:43 +02:00
|
|
|
{
|
|
|
|
|
CommentStmt *n = makeNode(CommentStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-06-27 16:45:32 +02:00
|
|
|
n->objtype = OBJECT_FUNCTION;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $4;
|
2016-09-15 19:00:00 +02:00
|
|
|
n->comment = $6;
|
2002-06-17 22:27:43 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2016-12-28 18:00:00 +01:00
|
|
|
| COMMENT ON OPERATOR operator_with_argtypes IS comment_text
|
2002-06-17 22:27:43 +02:00
|
|
|
{
|
|
|
|
|
CommentStmt *n = makeNode(CommentStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-06-27 16:45:32 +02:00
|
|
|
n->objtype = OBJECT_OPERATOR;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $4;
|
2016-12-28 18:00:00 +01:00
|
|
|
n->comment = $6;
|
2002-06-17 22:27:43 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2002-07-15 01:38:13 +02:00
|
|
|
| COMMENT ON CONSTRAINT name ON any_name IS comment_text
|
2002-06-17 22:27:43 +02:00
|
|
|
{
|
|
|
|
|
CommentStmt *n = makeNode(CommentStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-12-23 13:06:44 +01:00
|
|
|
n->objtype = OBJECT_TABCONSTRAINT;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) lappend($6, makeString($4));
|
2002-06-17 22:27:43 +02:00
|
|
|
n->comment = $8;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2014-12-23 13:06:44 +01:00
|
|
|
| COMMENT ON CONSTRAINT name ON DOMAIN_P any_name IS comment_text
|
|
|
|
|
{
|
|
|
|
|
CommentStmt *n = makeNode(CommentStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-12-23 13:06:44 +01:00
|
|
|
n->objtype = OBJECT_DOMCONSTRAINT;
|
2014-12-30 17:57:23 +01:00
|
|
|
/*
|
|
|
|
|
* should use Typename not any_name in the production, but
|
|
|
|
|
* there's a shift/reduce conflict if we do that, so fix it
|
|
|
|
|
* up here.
|
|
|
|
|
*/
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) list_make2(makeTypeNameFromNameList($7), makeString($4));
|
2014-12-23 13:06:44 +01:00
|
|
|
n->comment = $9;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2020-06-13 09:03:28 +02:00
|
|
|
| COMMENT ON object_type_name_on_any_name name ON any_name IS comment_text
|
Rename pg_rowsecurity -> pg_policy and other fixes
As pointed out by Robert, we should really have named pg_rowsecurity
pg_policy, as the objects stored in that catalog are policies. This
patch fixes that and updates the column names to start with 'pol' to
match the new catalog name.
The security consideration for COPY with row level security, also
pointed out by Robert, has also been addressed by remembering and
re-checking the OID of the relation initially referenced during COPY
processing, to make sure it hasn't changed under us by the time we
finish planning out the query which has been built.
Robert and Alvaro also commented on missing OCLASS and OBJECT entries
for POLICY (formerly ROWSECURITY or POLICY, depending) in various
places. This patch fixes that too, which also happens to add the
ability to COMMENT on policies.
In passing, attempt to improve the consistency of messages, comments,
and documentation as well. This removes various incarnations of
'row-security', 'row-level security', 'Row-security', etc, in favor
of 'policy', 'row level security' or 'row_security' as appropriate.
Happy Thanksgiving!
2014-11-27 07:06:36 +01:00
|
|
|
{
|
|
|
|
|
CommentStmt *n = makeNode(CommentStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2020-06-13 09:03:28 +02:00
|
|
|
n->objtype = $3;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) lappend($6, makeString($4));
|
Rename pg_rowsecurity -> pg_policy and other fixes
As pointed out by Robert, we should really have named pg_rowsecurity
pg_policy, as the objects stored in that catalog are policies. This
patch fixes that and updates the column names to start with 'pol' to
match the new catalog name.
The security consideration for COPY with row level security, also
pointed out by Robert, has also been addressed by remembering and
re-checking the OID of the relation initially referenced during COPY
processing, to make sure it hasn't changed under us by the time we
finish planning out the query which has been built.
Robert and Alvaro also commented on missing OCLASS and OBJECT entries
for POLICY (formerly ROWSECURITY or POLICY, depending) in various
places. This patch fixes that too, which also happens to add the
ability to COMMENT on policies.
In passing, attempt to improve the consistency of messages, comments,
and documentation as well. This removes various incarnations of
'row-security', 'row-level security', 'Row-security', etc, in favor
of 'policy', 'row level security' or 'row_security' as appropriate.
Happy Thanksgiving!
2014-11-27 07:06:36 +01:00
|
|
|
n->comment = $8;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| COMMENT ON PROCEDURE function_with_argtypes IS comment_text
|
2017-11-30 14:46:13 +01:00
|
|
|
{
|
|
|
|
|
CommentStmt *n = makeNode(CommentStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->objtype = OBJECT_PROCEDURE;
|
|
|
|
|
n->object = (Node *) $4;
|
|
|
|
|
n->comment = $6;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| COMMENT ON ROUTINE function_with_argtypes IS comment_text
|
2017-11-30 14:46:13 +01:00
|
|
|
{
|
|
|
|
|
CommentStmt *n = makeNode(CommentStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->objtype = OBJECT_ROUTINE;
|
|
|
|
|
n->object = (Node *) $4;
|
|
|
|
|
n->comment = $6;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2015-04-26 16:33:14 +02:00
|
|
|
| COMMENT ON TRANSFORM FOR Typename LANGUAGE name IS comment_text
|
|
|
|
|
{
|
|
|
|
|
CommentStmt *n = makeNode(CommentStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2015-04-26 16:33:14 +02:00
|
|
|
n->objtype = OBJECT_TRANSFORM;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) list_make2($5, makeString($7));
|
2015-04-26 16:33:14 +02:00
|
|
|
n->comment = $9;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2020-06-10 22:58:46 +02:00
|
|
|
| COMMENT ON OPERATOR CLASS any_name USING name IS comment_text
|
2003-11-21 23:32:49 +01:00
|
|
|
{
|
|
|
|
|
CommentStmt *n = makeNode(CommentStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-11-21 23:32:49 +01:00
|
|
|
n->objtype = OBJECT_OPCLASS;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) lcons(makeString($7), $5);
|
2003-11-21 23:32:49 +01:00
|
|
|
n->comment = $9;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2020-06-10 22:58:46 +02:00
|
|
|
| COMMENT ON OPERATOR FAMILY any_name USING name IS comment_text
|
2007-01-23 06:07:18 +01:00
|
|
|
{
|
|
|
|
|
CommentStmt *n = makeNode(CommentStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-01-23 06:07:18 +01:00
|
|
|
n->objtype = OBJECT_OPFAMILY;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) lcons(makeString($7), $5);
|
2007-01-23 06:07:18 +01:00
|
|
|
n->comment = $9;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2003-11-21 23:32:49 +01:00
|
|
|
| COMMENT ON LARGE_P OBJECT_P NumericOnly IS comment_text
|
|
|
|
|
{
|
|
|
|
|
CommentStmt *n = makeNode(CommentStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-11-21 23:32:49 +01:00
|
|
|
n->objtype = OBJECT_LARGEOBJECT;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $5;
|
2003-11-21 23:32:49 +01:00
|
|
|
n->comment = $7;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| COMMENT ON CAST '(' Typename AS Typename ')' IS comment_text
|
|
|
|
|
{
|
|
|
|
|
CommentStmt *n = makeNode(CommentStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-11-21 23:32:49 +01:00
|
|
|
n->objtype = OBJECT_CAST;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) list_make2($5, $7);
|
2003-11-21 23:32:49 +01:00
|
|
|
n->comment = $10;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
1999-10-26 05:12:39 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
comment_text:
|
2002-07-15 01:38:13 +02:00
|
|
|
Sconst { $$ = $1; }
|
|
|
|
|
| NULL_P { $$ = NULL; }
|
1999-10-26 18:32:46 +02:00
|
|
|
;
|
2002-06-17 07:40:32 +02:00
|
|
|
|
2010-09-28 02:55:27 +02:00
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* SECURITY LABEL [FOR <provider>] ON <object> IS <label>
|
|
|
|
|
*
|
|
|
|
|
* As with COMMENT ON, <object> can refer to various types of database
|
|
|
|
|
* objects (e.g. TABLE, COLUMN, etc.).
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
SecLabelStmt:
|
2020-06-13 09:03:28 +02:00
|
|
|
SECURITY LABEL opt_provider ON object_type_any_name any_name
|
2010-09-28 02:55:27 +02:00
|
|
|
IS security_label
|
|
|
|
|
{
|
|
|
|
|
SecLabelStmt *n = makeNode(SecLabelStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-09-28 02:55:27 +02:00
|
|
|
n->provider = $3;
|
|
|
|
|
n->objtype = $5;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $6;
|
|
|
|
|
n->label = $8;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2020-06-13 09:03:28 +02:00
|
|
|
| SECURITY LABEL opt_provider ON COLUMN any_name
|
|
|
|
|
IS security_label
|
|
|
|
|
{
|
|
|
|
|
SecLabelStmt *n = makeNode(SecLabelStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2020-06-13 09:03:28 +02:00
|
|
|
n->provider = $3;
|
|
|
|
|
n->objtype = OBJECT_COLUMN;
|
|
|
|
|
n->object = (Node *) $6;
|
|
|
|
|
n->label = $8;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| SECURITY LABEL opt_provider ON object_type_name name
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
IS security_label
|
|
|
|
|
{
|
|
|
|
|
SecLabelStmt *n = makeNode(SecLabelStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->provider = $3;
|
|
|
|
|
n->objtype = $5;
|
|
|
|
|
n->object = (Node *) makeString($6);
|
2010-09-28 02:55:27 +02:00
|
|
|
n->label = $8;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2014-12-30 17:57:23 +01:00
|
|
|
| SECURITY LABEL opt_provider ON TYPE_P Typename
|
|
|
|
|
IS security_label
|
|
|
|
|
{
|
|
|
|
|
SecLabelStmt *n = makeNode(SecLabelStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-12-30 17:57:23 +01:00
|
|
|
n->provider = $3;
|
|
|
|
|
n->objtype = OBJECT_TYPE;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $6;
|
2014-12-30 17:57:23 +01:00
|
|
|
n->label = $8;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| SECURITY LABEL opt_provider ON DOMAIN_P Typename
|
|
|
|
|
IS security_label
|
|
|
|
|
{
|
|
|
|
|
SecLabelStmt *n = makeNode(SecLabelStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-12-30 17:57:23 +01:00
|
|
|
n->provider = $3;
|
2017-08-02 16:40:32 +02:00
|
|
|
n->objtype = OBJECT_DOMAIN;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $6;
|
2014-12-30 17:57:23 +01:00
|
|
|
n->label = $8;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2016-09-15 19:00:00 +02:00
|
|
|
| SECURITY LABEL opt_provider ON AGGREGATE aggregate_with_argtypes
|
2010-09-28 02:55:27 +02:00
|
|
|
IS security_label
|
|
|
|
|
{
|
|
|
|
|
SecLabelStmt *n = makeNode(SecLabelStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-09-28 02:55:27 +02:00
|
|
|
n->provider = $3;
|
|
|
|
|
n->objtype = OBJECT_AGGREGATE;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $6;
|
2016-09-15 19:00:00 +02:00
|
|
|
n->label = $8;
|
2010-09-28 02:55:27 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2016-09-15 19:00:00 +02:00
|
|
|
| SECURITY LABEL opt_provider ON FUNCTION function_with_argtypes
|
2010-09-28 02:55:27 +02:00
|
|
|
IS security_label
|
|
|
|
|
{
|
|
|
|
|
SecLabelStmt *n = makeNode(SecLabelStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-09-28 02:55:27 +02:00
|
|
|
n->provider = $3;
|
|
|
|
|
n->objtype = OBJECT_FUNCTION;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $6;
|
2016-09-15 19:00:00 +02:00
|
|
|
n->label = $8;
|
2010-09-28 02:55:27 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| SECURITY LABEL opt_provider ON LARGE_P OBJECT_P NumericOnly
|
|
|
|
|
IS security_label
|
|
|
|
|
{
|
|
|
|
|
SecLabelStmt *n = makeNode(SecLabelStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-09-28 02:55:27 +02:00
|
|
|
n->provider = $3;
|
|
|
|
|
n->objtype = OBJECT_LARGEOBJECT;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $7;
|
2010-09-28 02:55:27 +02:00
|
|
|
n->label = $9;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| SECURITY LABEL opt_provider ON PROCEDURE function_with_argtypes
|
2017-11-30 14:46:13 +01:00
|
|
|
IS security_label
|
|
|
|
|
{
|
|
|
|
|
SecLabelStmt *n = makeNode(SecLabelStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->provider = $3;
|
|
|
|
|
n->objtype = OBJECT_PROCEDURE;
|
|
|
|
|
n->object = (Node *) $6;
|
|
|
|
|
n->label = $8;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| SECURITY LABEL opt_provider ON ROUTINE function_with_argtypes
|
|
|
|
|
IS security_label
|
|
|
|
|
{
|
|
|
|
|
SecLabelStmt *n = makeNode(SecLabelStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->provider = $3;
|
|
|
|
|
n->objtype = OBJECT_ROUTINE;
|
|
|
|
|
n->object = (Node *) $6;
|
|
|
|
|
n->label = $8;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2010-09-28 02:55:27 +02:00
|
|
|
;
|
|
|
|
|
|
2013-06-03 02:09:20 +02:00
|
|
|
opt_provider: FOR NonReservedWord_or_Sconst { $$ = $2; }
|
2020-11-16 11:54:52 +01:00
|
|
|
| /* EMPTY */ { $$ = NULL; }
|
2010-09-28 02:55:27 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
security_label: Sconst { $$ = $1; }
|
|
|
|
|
| NULL_P { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* QUERY:
|
2003-03-11 20:40:24 +01:00
|
|
|
* fetch/move
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2009-11-11 20:25:42 +01:00
|
|
|
FetchStmt: FETCH fetch_args
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2003-03-11 20:40:24 +01:00
|
|
|
FetchStmt *n = (FetchStmt *) $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
n->ismove = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-01-18 20:08:13 +01:00
|
|
|
}
|
2009-11-11 20:25:42 +01:00
|
|
|
| MOVE fetch_args
|
2000-01-18 20:08:13 +01:00
|
|
|
{
|
2003-03-11 20:40:24 +01:00
|
|
|
FetchStmt *n = (FetchStmt *) $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
n->ismove = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-01-18 20:08:13 +01:00
|
|
|
}
|
2009-11-11 20:25:42 +01:00
|
|
|
;
|
|
|
|
|
|
2009-11-11 21:31:26 +01:00
|
|
|
fetch_args: cursor_name
|
2000-01-18 20:08:13 +01:00
|
|
|
{
|
|
|
|
|
FetchStmt *n = makeNode(FetchStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-11-11 20:25:42 +01:00
|
|
|
n->portalname = $1;
|
2003-02-10 05:44:47 +01:00
|
|
|
n->direction = FETCH_FORWARD;
|
2000-01-18 20:08:13 +01:00
|
|
|
n->howMany = 1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-01-18 20:08:13 +01:00
|
|
|
}
|
2009-11-11 21:31:26 +01:00
|
|
|
| from_in cursor_name
|
2000-01-18 20:08:13 +01:00
|
|
|
{
|
|
|
|
|
FetchStmt *n = makeNode(FetchStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-11-11 20:25:42 +01:00
|
|
|
n->portalname = $2;
|
2003-02-10 05:44:47 +01:00
|
|
|
n->direction = FETCH_FORWARD;
|
2000-01-18 20:08:13 +01:00
|
|
|
n->howMany = 1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-01-18 20:08:13 +01:00
|
|
|
}
|
2009-11-11 21:31:26 +01:00
|
|
|
| NEXT opt_from_in cursor_name
|
1997-09-29 07:59:16 +02:00
|
|
|
{
|
|
|
|
|
FetchStmt *n = makeNode(FetchStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-11-11 20:25:42 +01:00
|
|
|
n->portalname = $3;
|
2003-03-11 20:40:24 +01:00
|
|
|
n->direction = FETCH_FORWARD;
|
|
|
|
|
n->howMany = 1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-01-18 20:08:13 +01:00
|
|
|
}
|
2009-11-11 21:31:26 +01:00
|
|
|
| PRIOR opt_from_in cursor_name
|
2000-01-18 20:08:13 +01:00
|
|
|
{
|
|
|
|
|
FetchStmt *n = makeNode(FetchStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-11-11 20:25:42 +01:00
|
|
|
n->portalname = $3;
|
2003-03-11 20:40:24 +01:00
|
|
|
n->direction = FETCH_BACKWARD;
|
|
|
|
|
n->howMany = 1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2009-11-11 21:31:26 +01:00
|
|
|
| FIRST_P opt_from_in cursor_name
|
2000-01-18 20:08:13 +01:00
|
|
|
{
|
|
|
|
|
FetchStmt *n = makeNode(FetchStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-11-11 20:25:42 +01:00
|
|
|
n->portalname = $3;
|
2003-03-11 20:40:24 +01:00
|
|
|
n->direction = FETCH_ABSOLUTE;
|
2000-01-18 20:08:13 +01:00
|
|
|
n->howMany = 1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-01-18 20:08:13 +01:00
|
|
|
}
|
2009-11-11 21:31:26 +01:00
|
|
|
| LAST_P opt_from_in cursor_name
|
2003-03-11 20:40:24 +01:00
|
|
|
{
|
|
|
|
|
FetchStmt *n = makeNode(FetchStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-11-11 20:25:42 +01:00
|
|
|
n->portalname = $3;
|
2003-03-11 20:40:24 +01:00
|
|
|
n->direction = FETCH_ABSOLUTE;
|
|
|
|
|
n->howMany = -1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2003-03-11 20:40:24 +01:00
|
|
|
}
|
2009-11-11 21:31:26 +01:00
|
|
|
| ABSOLUTE_P SignedIconst opt_from_in cursor_name
|
2003-03-11 20:40:24 +01:00
|
|
|
{
|
|
|
|
|
FetchStmt *n = makeNode(FetchStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-11-11 20:25:42 +01:00
|
|
|
n->portalname = $4;
|
2003-03-11 20:40:24 +01:00
|
|
|
n->direction = FETCH_ABSOLUTE;
|
|
|
|
|
n->howMany = $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2003-03-11 20:40:24 +01:00
|
|
|
}
|
2009-11-11 21:31:26 +01:00
|
|
|
| RELATIVE_P SignedIconst opt_from_in cursor_name
|
2003-03-11 20:40:24 +01:00
|
|
|
{
|
|
|
|
|
FetchStmt *n = makeNode(FetchStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-11-11 20:25:42 +01:00
|
|
|
n->portalname = $4;
|
2003-03-11 20:40:24 +01:00
|
|
|
n->direction = FETCH_RELATIVE;
|
|
|
|
|
n->howMany = $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2003-03-11 20:40:24 +01:00
|
|
|
}
|
2009-11-11 21:31:26 +01:00
|
|
|
| SignedIconst opt_from_in cursor_name
|
2003-03-11 20:40:24 +01:00
|
|
|
{
|
|
|
|
|
FetchStmt *n = makeNode(FetchStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-11-11 20:25:42 +01:00
|
|
|
n->portalname = $3;
|
2003-03-11 20:40:24 +01:00
|
|
|
n->direction = FETCH_FORWARD;
|
|
|
|
|
n->howMany = $1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2003-03-11 20:40:24 +01:00
|
|
|
}
|
2009-11-11 21:31:26 +01:00
|
|
|
| ALL opt_from_in cursor_name
|
2003-03-11 20:40:24 +01:00
|
|
|
{
|
|
|
|
|
FetchStmt *n = makeNode(FetchStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-11-11 20:25:42 +01:00
|
|
|
n->portalname = $3;
|
2003-03-11 20:40:24 +01:00
|
|
|
n->direction = FETCH_FORWARD;
|
|
|
|
|
n->howMany = FETCH_ALL;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2003-03-11 20:40:24 +01:00
|
|
|
}
|
2009-11-11 21:31:26 +01:00
|
|
|
| FORWARD opt_from_in cursor_name
|
2000-01-18 20:08:13 +01:00
|
|
|
{
|
|
|
|
|
FetchStmt *n = makeNode(FetchStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-11-11 20:25:42 +01:00
|
|
|
n->portalname = $3;
|
2003-02-10 05:44:47 +01:00
|
|
|
n->direction = FETCH_FORWARD;
|
2000-01-18 20:08:13 +01:00
|
|
|
n->howMany = 1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-01-18 20:08:13 +01:00
|
|
|
}
|
2009-11-11 21:31:26 +01:00
|
|
|
| FORWARD SignedIconst opt_from_in cursor_name
|
2000-01-18 20:08:13 +01:00
|
|
|
{
|
|
|
|
|
FetchStmt *n = makeNode(FetchStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-11-11 20:25:42 +01:00
|
|
|
n->portalname = $4;
|
2003-02-10 05:44:47 +01:00
|
|
|
n->direction = FETCH_FORWARD;
|
2003-03-11 20:40:24 +01:00
|
|
|
n->howMany = $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2003-03-11 20:40:24 +01:00
|
|
|
}
|
2009-11-11 21:31:26 +01:00
|
|
|
| FORWARD ALL opt_from_in cursor_name
|
2003-03-11 20:40:24 +01:00
|
|
|
{
|
|
|
|
|
FetchStmt *n = makeNode(FetchStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-11-11 20:25:42 +01:00
|
|
|
n->portalname = $4;
|
2003-03-11 20:40:24 +01:00
|
|
|
n->direction = FETCH_FORWARD;
|
|
|
|
|
n->howMany = FETCH_ALL;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2003-03-11 20:40:24 +01:00
|
|
|
}
|
2009-11-11 21:31:26 +01:00
|
|
|
| BACKWARD opt_from_in cursor_name
|
2003-03-11 20:40:24 +01:00
|
|
|
{
|
|
|
|
|
FetchStmt *n = makeNode(FetchStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-11-11 20:25:42 +01:00
|
|
|
n->portalname = $3;
|
2003-03-11 20:40:24 +01:00
|
|
|
n->direction = FETCH_BACKWARD;
|
2000-01-18 20:08:13 +01:00
|
|
|
n->howMany = 1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-01-18 20:08:13 +01:00
|
|
|
}
|
2009-11-11 21:31:26 +01:00
|
|
|
| BACKWARD SignedIconst opt_from_in cursor_name
|
2003-03-11 20:40:24 +01:00
|
|
|
{
|
|
|
|
|
FetchStmt *n = makeNode(FetchStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-11-11 20:25:42 +01:00
|
|
|
n->portalname = $4;
|
2003-03-11 20:40:24 +01:00
|
|
|
n->direction = FETCH_BACKWARD;
|
|
|
|
|
n->howMany = $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2003-03-11 20:40:24 +01:00
|
|
|
}
|
2009-11-11 21:31:26 +01:00
|
|
|
| BACKWARD ALL opt_from_in cursor_name
|
2002-06-17 22:27:43 +02:00
|
|
|
{
|
2003-03-11 20:40:24 +01:00
|
|
|
FetchStmt *n = makeNode(FetchStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-11-11 20:25:42 +01:00
|
|
|
n->portalname = $4;
|
2003-03-11 20:40:24 +01:00
|
|
|
n->direction = FETCH_BACKWARD;
|
|
|
|
|
n->howMany = FETCH_ALL;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-06-17 22:27:43 +02:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2020-11-12 07:48:36 +01:00
|
|
|
from_in: FROM
|
|
|
|
|
| IN_P
|
2002-06-17 22:27:43 +02:00
|
|
|
;
|
1997-09-29 07:59:16 +02:00
|
|
|
|
2020-11-12 07:48:36 +01:00
|
|
|
opt_from_in: from_in
|
|
|
|
|
| /* EMPTY */
|
2009-11-11 20:25:42 +01:00
|
|
|
;
|
|
|
|
|
|
1997-10-25 07:56:41 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2002-02-19 00:11:58 +01:00
|
|
|
* GRANT and REVOKE statements
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-18 19:56:41 +02:00
|
|
|
GrantStmt: GRANT privileges ON privilege_target TO grantee_list
|
2021-01-30 09:41:44 +01:00
|
|
|
opt_grant_grant_option opt_granted_by
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2001-06-10 01:21:55 +02:00
|
|
|
GrantStmt *n = makeNode(GrantStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2001-06-10 01:21:55 +02:00
|
|
|
n->is_grant = true;
|
|
|
|
|
n->privileges = $2;
|
2009-10-12 22:39:42 +02:00
|
|
|
n->targtype = ($4)->targtype;
|
2002-02-19 00:11:58 +01:00
|
|
|
n->objtype = ($4)->objtype;
|
|
|
|
|
n->objects = ($4)->objs;
|
|
|
|
|
n->grantees = $6;
|
2003-01-24 00:39:07 +01:00
|
|
|
n->grant_option = $7;
|
2021-01-30 09:41:44 +01:00
|
|
|
n->grantor = $8;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
|
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2005-06-28 21:51:26 +02:00
|
|
|
RevokeStmt:
|
|
|
|
|
REVOKE privileges ON privilege_target
|
2021-01-30 09:41:44 +01:00
|
|
|
FROM grantee_list opt_granted_by opt_drop_behavior
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2002-02-19 00:11:58 +01:00
|
|
|
GrantStmt *n = makeNode(GrantStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-02-19 00:11:58 +01:00
|
|
|
n->is_grant = false;
|
2005-06-28 21:51:26 +02:00
|
|
|
n->grant_option = false;
|
|
|
|
|
n->privileges = $2;
|
2009-10-12 22:39:42 +02:00
|
|
|
n->targtype = ($4)->targtype;
|
2005-06-28 21:51:26 +02:00
|
|
|
n->objtype = ($4)->objtype;
|
|
|
|
|
n->objects = ($4)->objs;
|
|
|
|
|
n->grantees = $6;
|
2021-01-30 09:41:44 +01:00
|
|
|
n->grantor = $7;
|
|
|
|
|
n->behavior = $8;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-06-28 21:51:26 +02:00
|
|
|
}
|
|
|
|
|
| REVOKE GRANT OPTION FOR privileges ON privilege_target
|
2021-01-30 09:41:44 +01:00
|
|
|
FROM grantee_list opt_granted_by opt_drop_behavior
|
2005-06-28 21:51:26 +02:00
|
|
|
{
|
|
|
|
|
GrantStmt *n = makeNode(GrantStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-06-28 21:51:26 +02:00
|
|
|
n->is_grant = false;
|
|
|
|
|
n->grant_option = true;
|
|
|
|
|
n->privileges = $5;
|
2009-10-12 22:39:42 +02:00
|
|
|
n->targtype = ($7)->targtype;
|
2005-06-28 21:51:26 +02:00
|
|
|
n->objtype = ($7)->objtype;
|
|
|
|
|
n->objects = ($7)->objs;
|
|
|
|
|
n->grantees = $9;
|
2021-01-30 09:41:44 +01:00
|
|
|
n->grantor = $10;
|
|
|
|
|
n->behavior = $11;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2002-02-19 00:11:58 +01:00
|
|
|
|
2005-06-28 21:51:26 +02:00
|
|
|
/*
|
2009-01-22 21:16:10 +01:00
|
|
|
* Privilege names are represented as strings; the validity of the privilege
|
|
|
|
|
* names gets checked at execution. This is a bit annoying but we have little
|
|
|
|
|
* choice because of the syntactic conflict with lists of role names in
|
|
|
|
|
* GRANT/REVOKE. What's more, we have to call out in the "privilege"
|
|
|
|
|
* production any reserved keywords that need to be usable as privilege names.
|
2005-06-28 21:51:26 +02:00
|
|
|
*/
|
|
|
|
|
|
2002-02-19 00:11:58 +01:00
|
|
|
/* either ALL [PRIVILEGES] or a list of individual privileges */
|
2005-06-28 21:51:26 +02:00
|
|
|
privileges: privilege_list
|
|
|
|
|
{ $$ = $1; }
|
|
|
|
|
| ALL
|
|
|
|
|
{ $$ = NIL; }
|
|
|
|
|
| ALL PRIVILEGES
|
|
|
|
|
{ $$ = NIL; }
|
2009-01-22 21:16:10 +01:00
|
|
|
| ALL '(' columnList ')'
|
|
|
|
|
{
|
|
|
|
|
AccessPriv *n = makeNode(AccessPriv);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-01-22 21:16:10 +01:00
|
|
|
n->priv_name = NULL;
|
|
|
|
|
n->cols = $3;
|
|
|
|
|
$$ = list_make1(n);
|
|
|
|
|
}
|
|
|
|
|
| ALL PRIVILEGES '(' columnList ')'
|
|
|
|
|
{
|
|
|
|
|
AccessPriv *n = makeNode(AccessPriv);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-01-22 21:16:10 +01:00
|
|
|
n->priv_name = NULL;
|
|
|
|
|
n->cols = $4;
|
|
|
|
|
$$ = list_make1(n);
|
|
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
2009-01-22 21:16:10 +01:00
|
|
|
privilege_list: privilege { $$ = list_make1($1); }
|
|
|
|
|
| privilege_list ',' privilege { $$ = lappend($1, $3); }
|
2002-02-19 00:11:58 +01:00
|
|
|
;
|
|
|
|
|
|
2009-01-22 21:16:10 +01:00
|
|
|
privilege: SELECT opt_column_list
|
|
|
|
|
{
|
|
|
|
|
AccessPriv *n = makeNode(AccessPriv);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-01-22 21:16:10 +01:00
|
|
|
n->priv_name = pstrdup($1);
|
|
|
|
|
n->cols = $2;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| REFERENCES opt_column_list
|
|
|
|
|
{
|
|
|
|
|
AccessPriv *n = makeNode(AccessPriv);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-01-22 21:16:10 +01:00
|
|
|
n->priv_name = pstrdup($1);
|
|
|
|
|
n->cols = $2;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| CREATE opt_column_list
|
|
|
|
|
{
|
|
|
|
|
AccessPriv *n = makeNode(AccessPriv);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-01-22 21:16:10 +01:00
|
|
|
n->priv_name = pstrdup($1);
|
|
|
|
|
n->cols = $2;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2022-04-06 19:24:33 +02:00
|
|
|
| ALTER SYSTEM_P
|
|
|
|
|
{
|
|
|
|
|
AccessPriv *n = makeNode(AccessPriv);
|
|
|
|
|
n->priv_name = pstrdup("alter system");
|
|
|
|
|
n->cols = NIL;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2009-01-22 21:16:10 +01:00
|
|
|
| ColId opt_column_list
|
|
|
|
|
{
|
|
|
|
|
AccessPriv *n = makeNode(AccessPriv);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-01-22 21:16:10 +01:00
|
|
|
n->priv_name = $1;
|
|
|
|
|
n->cols = $2;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2002-02-19 00:11:58 +01:00
|
|
|
;
|
|
|
|
|
|
2022-04-06 19:24:33 +02:00
|
|
|
parameter_name_list:
|
|
|
|
|
parameter_name
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make1(makeString($1));
|
|
|
|
|
}
|
|
|
|
|
| parameter_name_list ',' parameter_name
|
|
|
|
|
{
|
|
|
|
|
$$ = lappend($1, makeString($3));
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
parameter_name:
|
|
|
|
|
ColId
|
|
|
|
|
{
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
|
|
|
|
| parameter_name '.' ColId
|
|
|
|
|
{
|
|
|
|
|
$$ = psprintf("%s.%s", $1, $3);
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2002-02-19 00:11:58 +01:00
|
|
|
|
|
|
|
|
/* Don't bother trying to fold the first two rules into one using
|
2005-06-28 21:51:26 +02:00
|
|
|
* opt_table. You're going to get conflicts.
|
|
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
privilege_target:
|
|
|
|
|
qualified_name_list
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2009-01-22 21:16:10 +01:00
|
|
|
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-10-12 22:39:42 +02:00
|
|
|
n->targtype = ACL_TARGET_OBJECT;
|
2017-10-12 00:35:19 +02:00
|
|
|
n->objtype = OBJECT_TABLE;
|
2002-02-19 00:11:58 +01:00
|
|
|
n->objs = $1;
|
|
|
|
|
$$ = n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2002-03-21 17:02:16 +01:00
|
|
|
| TABLE qualified_name_list
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2009-01-22 21:16:10 +01:00
|
|
|
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-10-12 22:39:42 +02:00
|
|
|
n->targtype = ACL_TARGET_OBJECT;
|
2017-10-12 00:35:19 +02:00
|
|
|
n->objtype = OBJECT_TABLE;
|
2002-02-19 00:11:58 +01:00
|
|
|
n->objs = $2;
|
|
|
|
|
$$ = n;
|
2001-05-27 11:59:30 +02:00
|
|
|
}
|
2006-01-21 03:16:21 +01:00
|
|
|
| SEQUENCE qualified_name_list
|
|
|
|
|
{
|
2009-01-22 21:16:10 +01:00
|
|
|
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-10-12 22:39:42 +02:00
|
|
|
n->targtype = ACL_TARGET_OBJECT;
|
2017-10-12 00:35:19 +02:00
|
|
|
n->objtype = OBJECT_SEQUENCE;
|
2006-01-21 03:16:21 +01:00
|
|
|
n->objs = $2;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2008-12-19 17:25:19 +01:00
|
|
|
| FOREIGN DATA_P WRAPPER name_list
|
|
|
|
|
{
|
2009-01-22 21:16:10 +01:00
|
|
|
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-10-12 22:39:42 +02:00
|
|
|
n->targtype = ACL_TARGET_OBJECT;
|
2017-10-12 00:35:19 +02:00
|
|
|
n->objtype = OBJECT_FDW;
|
2008-12-19 17:25:19 +01:00
|
|
|
n->objs = $4;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| FOREIGN SERVER name_list
|
|
|
|
|
{
|
2009-01-22 21:16:10 +01:00
|
|
|
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-10-12 22:39:42 +02:00
|
|
|
n->targtype = ACL_TARGET_OBJECT;
|
2017-10-12 00:35:19 +02:00
|
|
|
n->objtype = OBJECT_FOREIGN_SERVER;
|
2008-12-19 17:25:19 +01:00
|
|
|
n->objs = $3;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2002-02-19 00:11:58 +01:00
|
|
|
| FUNCTION function_with_argtypes_list
|
2001-05-27 11:59:30 +02:00
|
|
|
{
|
2009-01-22 21:16:10 +01:00
|
|
|
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-10-12 22:39:42 +02:00
|
|
|
n->targtype = ACL_TARGET_OBJECT;
|
2017-10-12 00:35:19 +02:00
|
|
|
n->objtype = OBJECT_FUNCTION;
|
2002-04-21 02:26:44 +02:00
|
|
|
n->objs = $2;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| PROCEDURE function_with_argtypes_list
|
2017-11-30 14:46:13 +01:00
|
|
|
{
|
|
|
|
|
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->targtype = ACL_TARGET_OBJECT;
|
2017-10-12 00:35:19 +02:00
|
|
|
n->objtype = OBJECT_PROCEDURE;
|
2017-11-30 14:46:13 +01:00
|
|
|
n->objs = $2;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| ROUTINE function_with_argtypes_list
|
2017-11-30 14:46:13 +01:00
|
|
|
{
|
|
|
|
|
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->targtype = ACL_TARGET_OBJECT;
|
2017-10-12 00:35:19 +02:00
|
|
|
n->objtype = OBJECT_ROUTINE;
|
2017-11-30 14:46:13 +01:00
|
|
|
n->objs = $2;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2002-04-21 02:26:44 +02:00
|
|
|
| DATABASE name_list
|
|
|
|
|
{
|
2009-01-22 21:16:10 +01:00
|
|
|
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-10-12 22:39:42 +02:00
|
|
|
n->targtype = ACL_TARGET_OBJECT;
|
2017-10-12 00:35:19 +02:00
|
|
|
n->objtype = OBJECT_DATABASE;
|
2002-02-19 00:11:58 +01:00
|
|
|
n->objs = $2;
|
|
|
|
|
$$ = n;
|
2001-05-27 11:59:30 +02:00
|
|
|
}
|
2011-12-19 23:05:19 +01:00
|
|
|
| DOMAIN_P any_name_list
|
|
|
|
|
{
|
|
|
|
|
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-12-19 23:05:19 +01:00
|
|
|
n->targtype = ACL_TARGET_OBJECT;
|
2017-10-12 00:35:19 +02:00
|
|
|
n->objtype = OBJECT_DOMAIN;
|
2011-12-19 23:05:19 +01:00
|
|
|
n->objs = $2;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2002-02-19 00:11:58 +01:00
|
|
|
| LANGUAGE name_list
|
2001-05-27 11:59:30 +02:00
|
|
|
{
|
2009-01-22 21:16:10 +01:00
|
|
|
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-10-12 22:39:42 +02:00
|
|
|
n->targtype = ACL_TARGET_OBJECT;
|
2017-10-12 00:35:19 +02:00
|
|
|
n->objtype = OBJECT_LANGUAGE;
|
2002-04-21 02:26:44 +02:00
|
|
|
n->objs = $2;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2010-06-13 19:43:13 +02:00
|
|
|
| LARGE_P OBJECT_P NumericOnly_list
|
2009-12-11 04:34:57 +01:00
|
|
|
{
|
|
|
|
|
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-12-11 04:34:57 +01:00
|
|
|
n->targtype = ACL_TARGET_OBJECT;
|
2017-10-12 00:35:19 +02:00
|
|
|
n->objtype = OBJECT_LARGEOBJECT;
|
2009-12-11 04:34:57 +01:00
|
|
|
n->objs = $3;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2022-04-06 19:24:33 +02:00
|
|
|
| PARAMETER parameter_name_list
|
|
|
|
|
{
|
|
|
|
|
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
|
|
|
|
|
n->targtype = ACL_TARGET_OBJECT;
|
|
|
|
|
n->objtype = OBJECT_PARAMETER_ACL;
|
|
|
|
|
n->objs = $2;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2002-04-21 02:26:44 +02:00
|
|
|
| SCHEMA name_list
|
|
|
|
|
{
|
2009-01-22 21:16:10 +01:00
|
|
|
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-10-12 22:39:42 +02:00
|
|
|
n->targtype = ACL_TARGET_OBJECT;
|
2017-10-12 00:35:19 +02:00
|
|
|
n->objtype = OBJECT_SCHEMA;
|
2002-02-19 00:11:58 +01:00
|
|
|
n->objs = $2;
|
|
|
|
|
$$ = n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2004-06-18 08:14:31 +02:00
|
|
|
| TABLESPACE name_list
|
|
|
|
|
{
|
2009-01-22 21:16:10 +01:00
|
|
|
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-10-12 22:39:42 +02:00
|
|
|
n->targtype = ACL_TARGET_OBJECT;
|
2017-10-12 00:35:19 +02:00
|
|
|
n->objtype = OBJECT_TABLESPACE;
|
2004-06-18 08:14:31 +02:00
|
|
|
n->objs = $2;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2011-12-19 23:05:19 +01:00
|
|
|
| TYPE_P any_name_list
|
|
|
|
|
{
|
|
|
|
|
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-12-19 23:05:19 +01:00
|
|
|
n->targtype = ACL_TARGET_OBJECT;
|
2017-10-12 00:35:19 +02:00
|
|
|
n->objtype = OBJECT_TYPE;
|
2011-12-19 23:05:19 +01:00
|
|
|
n->objs = $2;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2009-10-12 22:39:42 +02:00
|
|
|
| ALL TABLES IN_P SCHEMA name_list
|
|
|
|
|
{
|
|
|
|
|
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-10-12 22:39:42 +02:00
|
|
|
n->targtype = ACL_TARGET_ALL_IN_SCHEMA;
|
2017-10-12 00:35:19 +02:00
|
|
|
n->objtype = OBJECT_TABLE;
|
2009-10-12 22:39:42 +02:00
|
|
|
n->objs = $5;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| ALL SEQUENCES IN_P SCHEMA name_list
|
|
|
|
|
{
|
|
|
|
|
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-10-12 22:39:42 +02:00
|
|
|
n->targtype = ACL_TARGET_ALL_IN_SCHEMA;
|
2017-10-12 00:35:19 +02:00
|
|
|
n->objtype = OBJECT_SEQUENCE;
|
2009-10-12 22:39:42 +02:00
|
|
|
n->objs = $5;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| ALL FUNCTIONS IN_P SCHEMA name_list
|
|
|
|
|
{
|
|
|
|
|
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-10-12 22:39:42 +02:00
|
|
|
n->targtype = ACL_TARGET_ALL_IN_SCHEMA;
|
2017-10-12 00:35:19 +02:00
|
|
|
n->objtype = OBJECT_FUNCTION;
|
2009-10-12 22:39:42 +02:00
|
|
|
n->objs = $5;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2017-11-30 14:46:13 +01:00
|
|
|
| ALL PROCEDURES IN_P SCHEMA name_list
|
|
|
|
|
{
|
|
|
|
|
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->targtype = ACL_TARGET_ALL_IN_SCHEMA;
|
2017-10-12 00:35:19 +02:00
|
|
|
n->objtype = OBJECT_PROCEDURE;
|
2017-11-30 14:46:13 +01:00
|
|
|
n->objs = $5;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| ALL ROUTINES IN_P SCHEMA name_list
|
|
|
|
|
{
|
|
|
|
|
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->targtype = ACL_TARGET_ALL_IN_SCHEMA;
|
2017-10-12 00:35:19 +02:00
|
|
|
n->objtype = OBJECT_ROUTINE;
|
2017-11-30 14:46:13 +01:00
|
|
|
n->objs = $5;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
2002-02-19 00:11:58 +01:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
grantee_list:
|
2004-05-31 01:40:41 +02:00
|
|
|
grantee { $$ = list_make1($1); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| grantee_list ',' grantee { $$ = lappend($1, $3); }
|
2002-02-19 00:11:58 +01:00
|
|
|
;
|
|
|
|
|
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
grantee:
|
|
|
|
|
RoleSpec { $$ = $1; }
|
|
|
|
|
| GROUP_P RoleSpec { $$ = $2; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2001-06-10 01:21:55 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
opt_grant_grant_option:
|
2017-08-16 06:22:32 +02:00
|
|
|
WITH GRANT OPTION { $$ = true; }
|
|
|
|
|
| /*EMPTY*/ { $$ = false; }
|
2002-02-19 00:11:58 +01:00
|
|
|
;
|
2001-06-10 01:21:55 +02:00
|
|
|
|
2005-06-28 21:51:26 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* GRANT and REVOKE ROLE statements
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
GrantRoleStmt:
|
2022-08-25 16:06:02 +02:00
|
|
|
GRANT privilege_list TO role_list opt_granted_by
|
2005-06-28 21:51:26 +02:00
|
|
|
{
|
|
|
|
|
GrantRoleStmt *n = makeNode(GrantRoleStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-06-28 21:51:26 +02:00
|
|
|
n->is_grant = true;
|
|
|
|
|
n->granted_roles = $2;
|
|
|
|
|
n->grantee_roles = $4;
|
2022-08-25 16:06:02 +02:00
|
|
|
n->opt = NIL;
|
|
|
|
|
n->grantor = $5;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| GRANT privilege_list TO role_list WITH grant_role_opt_list opt_granted_by
|
|
|
|
|
{
|
|
|
|
|
GrantRoleStmt *n = makeNode(GrantRoleStmt);
|
|
|
|
|
|
|
|
|
|
n->is_grant = true;
|
|
|
|
|
n->granted_roles = $2;
|
|
|
|
|
n->grantee_roles = $4;
|
|
|
|
|
n->opt = $6;
|
|
|
|
|
n->grantor = $7;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-06-28 21:51:26 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
RevokeRoleStmt:
|
2014-01-22 04:49:22 +01:00
|
|
|
REVOKE privilege_list FROM role_list opt_granted_by opt_drop_behavior
|
2005-06-28 21:51:26 +02:00
|
|
|
{
|
|
|
|
|
GrantRoleStmt *n = makeNode(GrantRoleStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-06-28 21:51:26 +02:00
|
|
|
n->is_grant = false;
|
2022-08-25 16:06:02 +02:00
|
|
|
n->opt = NIL;
|
2005-06-28 21:51:26 +02:00
|
|
|
n->granted_roles = $2;
|
|
|
|
|
n->grantee_roles = $4;
|
Make role grant system more consistent with other privileges.
Previously, membership of role A in role B could be recorded in the
catalog tables only once. This meant that a new grant of role A to
role B would overwrite the previous grant. For other object types, a
new grant of permission on an object - in this case role A - exists
along side the existing grant provided that the grantor is different.
Either grant can be revoked independently of the other, and
permissions remain so long as at least one grant remains. Make role
grants work similarly.
Previously, when granting membership in a role, the superuser could
specify any role whatsoever as the grantor, but for other object types,
the grantor of record must be either the owner of the object, or a
role that currently has privileges to perform a similar GRANT.
Implement the same scheme for role grants, treating the bootstrap
superuser as the role owner since roles do not have owners. This means
that attempting to revoke a grant, or admin option on a grant, can now
fail if there are dependent privileges, and that CASCADE can be used
to revoke these. It also means that you can't grant ADMIN OPTION on
a role back to a user who granted it directly or indirectly to you,
similar to how you can't give WITH GRANT OPTION on a privilege back
to a role which granted it directly or indirectly to you.
Previously, only the superuser could specify GRANTED BY with a user
other than the current user. Relax that rule to allow the grantor
to be any role whose privileges the current user posseses. This
doesn't improve compatibility with what we do for other object types,
where support for GRANTED BY is entirely vestigial, but it makes this
feature more usable and seems to make sense to change at the same time
we're changing related behaviors.
Along the way, fix "ALTER GROUP group_name ADD USER user_name" to
require the same privileges as "GRANT group_name TO user_name".
Previously, CREATEROLE privileges were sufficient for either, but
only the former form was permissible with ADMIN OPTION on the role.
Now, either CREATEROLE or ADMIN OPTION on the role suffices for
either spelling.
Patch by me, reviewed by Stephen Frost.
Discussion: http://postgr.es/m/CA+TgmoaFr-RZeQ+WoQ5nKPv97oT9+aDgK_a5+qWHSgbDsMp1Vg@mail.gmail.com
2022-08-22 17:35:17 +02:00
|
|
|
n->grantor = $5;
|
2005-06-28 21:51:26 +02:00
|
|
|
n->behavior = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-06-28 21:51:26 +02:00
|
|
|
}
|
2022-08-25 16:06:02 +02:00
|
|
|
| REVOKE ColId OPTION FOR privilege_list FROM role_list opt_granted_by opt_drop_behavior
|
2005-06-28 21:51:26 +02:00
|
|
|
{
|
|
|
|
|
GrantRoleStmt *n = makeNode(GrantRoleStmt);
|
2022-08-25 16:06:02 +02:00
|
|
|
DefElem *opt;
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2022-08-25 16:06:02 +02:00
|
|
|
opt = makeDefElem(pstrdup($2),
|
|
|
|
|
(Node *) makeBoolean(false), @2);
|
2005-06-28 21:51:26 +02:00
|
|
|
n->is_grant = false;
|
2022-08-25 16:06:02 +02:00
|
|
|
n->opt = list_make1(opt);
|
2005-06-28 21:51:26 +02:00
|
|
|
n->granted_roles = $5;
|
|
|
|
|
n->grantee_roles = $7;
|
Make role grant system more consistent with other privileges.
Previously, membership of role A in role B could be recorded in the
catalog tables only once. This meant that a new grant of role A to
role B would overwrite the previous grant. For other object types, a
new grant of permission on an object - in this case role A - exists
along side the existing grant provided that the grantor is different.
Either grant can be revoked independently of the other, and
permissions remain so long as at least one grant remains. Make role
grants work similarly.
Previously, when granting membership in a role, the superuser could
specify any role whatsoever as the grantor, but for other object types,
the grantor of record must be either the owner of the object, or a
role that currently has privileges to perform a similar GRANT.
Implement the same scheme for role grants, treating the bootstrap
superuser as the role owner since roles do not have owners. This means
that attempting to revoke a grant, or admin option on a grant, can now
fail if there are dependent privileges, and that CASCADE can be used
to revoke these. It also means that you can't grant ADMIN OPTION on
a role back to a user who granted it directly or indirectly to you,
similar to how you can't give WITH GRANT OPTION on a privilege back
to a role which granted it directly or indirectly to you.
Previously, only the superuser could specify GRANTED BY with a user
other than the current user. Relax that rule to allow the grantor
to be any role whose privileges the current user posseses. This
doesn't improve compatibility with what we do for other object types,
where support for GRANTED BY is entirely vestigial, but it makes this
feature more usable and seems to make sense to change at the same time
we're changing related behaviors.
Along the way, fix "ALTER GROUP group_name ADD USER user_name" to
require the same privileges as "GRANT group_name TO user_name".
Previously, CREATEROLE privileges were sufficient for either, but
only the former form was permissible with ADMIN OPTION on the role.
Now, either CREATEROLE or ADMIN OPTION on the role suffices for
either spelling.
Patch by me, reviewed by Stephen Frost.
Discussion: http://postgr.es/m/CA+TgmoaFr-RZeQ+WoQ5nKPv97oT9+aDgK_a5+qWHSgbDsMp1Vg@mail.gmail.com
2022-08-22 17:35:17 +02:00
|
|
|
n->grantor = $8;
|
2005-06-28 21:51:26 +02:00
|
|
|
n->behavior = $9;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-06-28 21:51:26 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2022-08-25 16:06:02 +02:00
|
|
|
grant_role_opt_list:
|
|
|
|
|
grant_role_opt_list ',' grant_role_opt { $$ = lappend($1, $3); }
|
|
|
|
|
| grant_role_opt { $$ = list_make1($1); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
grant_role_opt:
|
|
|
|
|
ColLabel grant_role_opt_value
|
|
|
|
|
{
|
|
|
|
|
$$ = makeDefElem(pstrdup($1), $2, @1);
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
grant_role_opt_value:
|
|
|
|
|
OPTION { $$ = (Node *) makeBoolean(true); }
|
|
|
|
|
| TRUE_P { $$ = (Node *) makeBoolean(true); }
|
|
|
|
|
| FALSE_P { $$ = (Node *) makeBoolean(false); }
|
2005-06-28 21:51:26 +02:00
|
|
|
;
|
|
|
|
|
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
opt_granted_by: GRANTED BY RoleSpec { $$ = $3; }
|
2005-06-28 21:51:26 +02:00
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
2009-10-05 21:24:49 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* ALTER DEFAULT PRIVILEGES statement
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
AlterDefaultPrivilegesStmt:
|
|
|
|
|
ALTER DEFAULT PRIVILEGES DefACLOptionList DefACLAction
|
|
|
|
|
{
|
|
|
|
|
AlterDefaultPrivilegesStmt *n = makeNode(AlterDefaultPrivilegesStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-10-05 21:24:49 +02:00
|
|
|
n->options = $4;
|
|
|
|
|
n->action = (GrantStmt *) $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2009-10-05 21:24:49 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
DefACLOptionList:
|
|
|
|
|
DefACLOptionList DefACLOption { $$ = lappend($1, $2); }
|
|
|
|
|
| /* EMPTY */ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
DefACLOption:
|
|
|
|
|
IN_P SCHEMA name_list
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("schemas", (Node *) $3, @1);
|
2009-10-05 21:24:49 +02:00
|
|
|
}
|
2014-01-22 04:49:22 +01:00
|
|
|
| FOR ROLE role_list
|
2009-10-05 21:24:49 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("roles", (Node *) $3, @1);
|
2009-10-05 21:24:49 +02:00
|
|
|
}
|
2014-01-22 04:49:22 +01:00
|
|
|
| FOR USER role_list
|
2009-10-05 21:24:49 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("roles", (Node *) $3, @1);
|
2009-10-05 21:24:49 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/*
|
2009-10-13 01:41:45 +02:00
|
|
|
* This should match GRANT/REVOKE, except that individual target objects
|
|
|
|
|
* are not mentioned and we only allow a subset of object types.
|
2009-10-05 21:24:49 +02:00
|
|
|
*/
|
|
|
|
|
DefACLAction:
|
|
|
|
|
GRANT privileges ON defacl_privilege_target TO grantee_list
|
|
|
|
|
opt_grant_grant_option
|
|
|
|
|
{
|
|
|
|
|
GrantStmt *n = makeNode(GrantStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-10-05 21:24:49 +02:00
|
|
|
n->is_grant = true;
|
|
|
|
|
n->privileges = $2;
|
2009-10-12 22:39:42 +02:00
|
|
|
n->targtype = ACL_TARGET_DEFAULTS;
|
2009-10-05 21:24:49 +02:00
|
|
|
n->objtype = $4;
|
|
|
|
|
n->objects = NIL;
|
|
|
|
|
n->grantees = $6;
|
|
|
|
|
n->grant_option = $7;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2009-10-05 21:24:49 +02:00
|
|
|
}
|
|
|
|
|
| REVOKE privileges ON defacl_privilege_target
|
|
|
|
|
FROM grantee_list opt_drop_behavior
|
|
|
|
|
{
|
|
|
|
|
GrantStmt *n = makeNode(GrantStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-10-05 21:24:49 +02:00
|
|
|
n->is_grant = false;
|
|
|
|
|
n->grant_option = false;
|
|
|
|
|
n->privileges = $2;
|
2009-10-12 22:39:42 +02:00
|
|
|
n->targtype = ACL_TARGET_DEFAULTS;
|
2009-10-05 21:24:49 +02:00
|
|
|
n->objtype = $4;
|
|
|
|
|
n->objects = NIL;
|
|
|
|
|
n->grantees = $6;
|
|
|
|
|
n->behavior = $7;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2009-10-05 21:24:49 +02:00
|
|
|
}
|
|
|
|
|
| REVOKE GRANT OPTION FOR privileges ON defacl_privilege_target
|
|
|
|
|
FROM grantee_list opt_drop_behavior
|
|
|
|
|
{
|
|
|
|
|
GrantStmt *n = makeNode(GrantStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-10-05 21:24:49 +02:00
|
|
|
n->is_grant = false;
|
|
|
|
|
n->grant_option = true;
|
|
|
|
|
n->privileges = $5;
|
2009-10-12 22:39:42 +02:00
|
|
|
n->targtype = ACL_TARGET_DEFAULTS;
|
2009-10-05 21:24:49 +02:00
|
|
|
n->objtype = $7;
|
|
|
|
|
n->objects = NIL;
|
|
|
|
|
n->grantees = $9;
|
|
|
|
|
n->behavior = $10;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2009-10-05 21:24:49 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
defacl_privilege_target:
|
2017-10-12 00:35:19 +02:00
|
|
|
TABLES { $$ = OBJECT_TABLE; }
|
|
|
|
|
| FUNCTIONS { $$ = OBJECT_FUNCTION; }
|
|
|
|
|
| ROUTINES { $$ = OBJECT_FUNCTION; }
|
|
|
|
|
| SEQUENCES { $$ = OBJECT_SEQUENCE; }
|
|
|
|
|
| TYPES_P { $$ = OBJECT_TYPE; }
|
|
|
|
|
| SCHEMAS { $$ = OBJECT_SCHEMA; }
|
2009-10-05 21:24:49 +02:00
|
|
|
;
|
|
|
|
|
|
1997-10-25 07:56:41 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2006-08-25 06:06:58 +02:00
|
|
|
* QUERY: CREATE INDEX
|
|
|
|
|
*
|
2004-06-18 08:14:31 +02:00
|
|
|
* Note: we cannot put TABLESPACE clause after WHERE clause unless we are
|
|
|
|
|
* willing to make TABLESPACE a fully reserved word.
|
1996-07-09 08:22:35 +02:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2022-07-22 12:57:01 +02:00
|
|
|
IndexStmt: CREATE opt_unique INDEX opt_concurrently opt_single_name
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
ON relation_expr access_method_clause '(' index_params ')'
|
2022-02-03 11:29:54 +01:00
|
|
|
opt_include opt_unique_null_treatment opt_reloptions OptTableSpace where_clause
|
2006-08-25 06:06:58 +02:00
|
|
|
{
|
|
|
|
|
IndexStmt *n = makeNode(IndexStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2006-08-25 06:06:58 +02:00
|
|
|
n->unique = $2;
|
2009-12-23 18:41:45 +01:00
|
|
|
n->concurrent = $4;
|
2006-08-25 06:06:58 +02:00
|
|
|
n->idxname = $5;
|
|
|
|
|
n->relation = $7;
|
|
|
|
|
n->accessMethod = $8;
|
|
|
|
|
n->indexParams = $10;
|
2018-04-07 22:00:39 +02:00
|
|
|
n->indexIncludingParams = $12;
|
2022-02-03 11:29:54 +01:00
|
|
|
n->nulls_not_distinct = !$13;
|
|
|
|
|
n->options = $14;
|
|
|
|
|
n->tableSpace = $15;
|
|
|
|
|
n->whereClause = $16;
|
Avoid pre-determining index names during CREATE TABLE LIKE parsing.
Formerly, when trying to copy both indexes and comments, CREATE TABLE LIKE
had to pre-assign names to indexes that had comments, because it made up an
explicit CommentStmt command to apply the comment and so it had to know the
name for the index. This creates bad interactions with other indexes, as
shown in bug #6734 from Daniele Varrazzo: the preassignment logic couldn't
take any other indexes into account so it could choose a conflicting name.
To fix, add a field to IndexStmt that allows it to carry a comment to be
assigned to the new index. (This isn't a user-exposed feature of CREATE
INDEX, only an internal option.) Now we don't need preassignment of index
names in any situation.
I also took the opportunity to refactor DefineIndex to accept the IndexStmt
as such, rather than passing all its fields individually in a mile-long
parameter list.
Back-patch to 9.2, but no further, because it seems too dangerous to change
IndexStmt or DefineIndex's API in released branches. The bug exists back
to 9.0 where CREATE TABLE LIKE grew the ability to copy comments, but given
the lack of prior complaints we'll just let it go unfixed before 9.2.
2012-07-16 19:25:18 +02:00
|
|
|
n->excludeOpNames = NIL;
|
|
|
|
|
n->idxcomment = NULL;
|
2011-01-25 21:42:03 +01:00
|
|
|
n->indexOid = InvalidOid;
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
n->oldNumber = InvalidRelFileNumber;
|
Skip WAL for new relfilenodes, under wal_level=minimal.
Until now, only selected bulk operations (e.g. COPY) did this. If a
given relfilenode received both a WAL-skipping COPY and a WAL-logged
operation (e.g. INSERT), recovery could lose tuples from the COPY. See
src/backend/access/transam/README section "Skipping WAL for New
RelFileNode" for the new coding rules. Maintainers of table access
methods should examine that section.
To maintain data durability, just before commit, we choose between an
fsync of the relfilenode and copying its contents to WAL. A new GUC,
wal_skip_threshold, guides that choice. If this change slows a workload
that creates small, permanent relfilenodes under wal_level=minimal, try
adjusting wal_skip_threshold. Users setting a timeout on COMMIT may
need to adjust that timeout, and log_min_duration_statement analysis
will reflect time consumption moving to COMMIT from commands like COPY.
Internally, this requires a reliable determination of whether
RollbackAndReleaseCurrentSubTransaction() would unlink a relation's
current relfilenode. Introduce rd_firstRelfilenodeSubid. Amend the
specification of rd_createSubid such that the field is zero when a new
rel has an old rd_node. Make relcache.c retain entries for certain
dropped relations until end of transaction.
Bump XLOG_PAGE_MAGIC, since this introduces XLOG_GIST_ASSIGN_LSN.
Future servers accept older WAL, so this bump is discretionary.
Kyotaro Horiguchi, reviewed (in earlier, similar versions) by Robert
Haas. Heikki Linnakangas and Michael Paquier implemented earlier
designs that materially clarified the problem. Reviewed, in earlier
designs, by Andrew Dunstan, Andres Freund, Alvaro Herrera, Tom Lane,
Fujii Masao, and Simon Riggs. Reported by Martijn van Oosterhout.
Discussion: https://postgr.es/m/20150702220524.GA9392@svana.org
2020-04-04 21:25:34 +02:00
|
|
|
n->oldCreateSubid = InvalidSubTransactionId;
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
n->oldFirstRelfilelocatorSubid = InvalidSubTransactionId;
|
Avoid pre-determining index names during CREATE TABLE LIKE parsing.
Formerly, when trying to copy both indexes and comments, CREATE TABLE LIKE
had to pre-assign names to indexes that had comments, because it made up an
explicit CommentStmt command to apply the comment and so it had to know the
name for the index. This creates bad interactions with other indexes, as
shown in bug #6734 from Daniele Varrazzo: the preassignment logic couldn't
take any other indexes into account so it could choose a conflicting name.
To fix, add a field to IndexStmt that allows it to carry a comment to be
assigned to the new index. (This isn't a user-exposed feature of CREATE
INDEX, only an internal option.) Now we don't need preassignment of index
names in any situation.
I also took the opportunity to refactor DefineIndex to accept the IndexStmt
as such, rather than passing all its fields individually in a mile-long
parameter list.
Back-patch to 9.2, but no further, because it seems too dangerous to change
IndexStmt or DefineIndex's API in released branches. The bug exists back
to 9.0 where CREATE TABLE LIKE grew the ability to copy comments, but given
the lack of prior complaints we'll just let it go unfixed before 9.2.
2012-07-16 19:25:18 +02:00
|
|
|
n->primary = false;
|
|
|
|
|
n->isconstraint = false;
|
|
|
|
|
n->deferrable = false;
|
|
|
|
|
n->initdeferred = false;
|
Get rid of multiple applications of transformExpr() to the same tree.
transformExpr() has for many years had provisions to do nothing when
applied to an already-transformed expression tree. However, this was
always ugly and of dubious reliability, so we'd be much better off without
it. The primary historical reason for it was that gram.y sometimes
returned multiple links to the same subexpression, which is no longer true
as of my BETWEEN fixes. We'd also grown some lazy hacks in CREATE TABLE
LIKE (failing to distinguish between raw and already-transformed index
specifications) and one or two other places.
This patch removes the need for and support for re-transforming already
transformed expressions. The index case is dealt with by adding a flag
to struct IndexStmt to indicate that it's already been transformed;
which has some benefit anyway in that tablecmds.c can now Assert that
transformation has happened rather than just assuming. The other main
reason was some rather sloppy code for array type coercion, which can
be fixed (and its performance improved too) by refactoring.
I did leave transformJoinUsingClause() still constructing expressions
containing untransformed operator nodes being applied to Vars, so that
transformExpr() still has to allow Var inputs. But that's a much narrower,
and safer, special case than before, since Vars will never appear in a raw
parse tree, and they don't have any substructure to worry about.
In passing fix some oversights in the patch that added CREATE INDEX
IF NOT EXISTS (missing processing of IndexStmt.if_not_exists). These
appear relatively harmless, but still sloppy coding practice.
2015-02-22 19:59:09 +01:00
|
|
|
n->transformed = false;
|
2014-11-06 10:48:33 +01:00
|
|
|
n->if_not_exists = false;
|
Fix tablespace inheritance for partitioned rels
Commit ca4103025dfe left a few loose ends. The most important one
(broken pg_dump output) is already fixed by virtue of commit
3b23552ad8bb, but some things remained:
* When ALTER TABLE rewrites tables, the indexes must remain in the
tablespace they were originally in. This didn't work because
index recreation during ALTER TABLE runs manufactured SQL (yuck),
which runs afoul of default_tablespace in competition with the parent
relation tablespace. To fix, reset default_tablespace to the empty
string temporarily, and add the TABLESPACE clause as appropriate.
* Setting a partitioned rel's tablespace to the database default is
confusing; if it worked, it would direct the partitions to that
tablespace regardless of default_tablespace. But in reality it does
not work, and making it work is a larger project. Therefore, throw
an error when this condition is detected, to alert the unwary.
Add some docs and tests, too.
Author: Álvaro Herrera
Discussion: https://postgr.es/m/CAKJS1f_1c260nOt_vBJ067AZ3JXptXVRohDVMLEBmudX1YEx-A@mail.gmail.com
2019-04-25 16:20:23 +02:00
|
|
|
n->reset_default_tblspc = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2014-11-06 10:48:33 +01:00
|
|
|
}
|
2020-06-10 22:58:46 +02:00
|
|
|
| CREATE opt_unique INDEX opt_concurrently IF_P NOT EXISTS name
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
ON relation_expr access_method_clause '(' index_params ')'
|
2022-02-03 11:29:54 +01:00
|
|
|
opt_include opt_unique_null_treatment opt_reloptions OptTableSpace where_clause
|
2014-11-06 10:48:33 +01:00
|
|
|
{
|
|
|
|
|
IndexStmt *n = makeNode(IndexStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-11-06 10:48:33 +01:00
|
|
|
n->unique = $2;
|
|
|
|
|
n->concurrent = $4;
|
|
|
|
|
n->idxname = $8;
|
|
|
|
|
n->relation = $10;
|
|
|
|
|
n->accessMethod = $11;
|
|
|
|
|
n->indexParams = $13;
|
2018-04-07 22:00:39 +02:00
|
|
|
n->indexIncludingParams = $15;
|
2022-02-03 11:29:54 +01:00
|
|
|
n->nulls_not_distinct = !$16;
|
|
|
|
|
n->options = $17;
|
|
|
|
|
n->tableSpace = $18;
|
|
|
|
|
n->whereClause = $19;
|
2014-11-06 10:48:33 +01:00
|
|
|
n->excludeOpNames = NIL;
|
|
|
|
|
n->idxcomment = NULL;
|
|
|
|
|
n->indexOid = InvalidOid;
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
n->oldNumber = InvalidRelFileNumber;
|
Skip WAL for new relfilenodes, under wal_level=minimal.
Until now, only selected bulk operations (e.g. COPY) did this. If a
given relfilenode received both a WAL-skipping COPY and a WAL-logged
operation (e.g. INSERT), recovery could lose tuples from the COPY. See
src/backend/access/transam/README section "Skipping WAL for New
RelFileNode" for the new coding rules. Maintainers of table access
methods should examine that section.
To maintain data durability, just before commit, we choose between an
fsync of the relfilenode and copying its contents to WAL. A new GUC,
wal_skip_threshold, guides that choice. If this change slows a workload
that creates small, permanent relfilenodes under wal_level=minimal, try
adjusting wal_skip_threshold. Users setting a timeout on COMMIT may
need to adjust that timeout, and log_min_duration_statement analysis
will reflect time consumption moving to COMMIT from commands like COPY.
Internally, this requires a reliable determination of whether
RollbackAndReleaseCurrentSubTransaction() would unlink a relation's
current relfilenode. Introduce rd_firstRelfilenodeSubid. Amend the
specification of rd_createSubid such that the field is zero when a new
rel has an old rd_node. Make relcache.c retain entries for certain
dropped relations until end of transaction.
Bump XLOG_PAGE_MAGIC, since this introduces XLOG_GIST_ASSIGN_LSN.
Future servers accept older WAL, so this bump is discretionary.
Kyotaro Horiguchi, reviewed (in earlier, similar versions) by Robert
Haas. Heikki Linnakangas and Michael Paquier implemented earlier
designs that materially clarified the problem. Reviewed, in earlier
designs, by Andrew Dunstan, Andres Freund, Alvaro Herrera, Tom Lane,
Fujii Masao, and Simon Riggs. Reported by Martijn van Oosterhout.
Discussion: https://postgr.es/m/20150702220524.GA9392@svana.org
2020-04-04 21:25:34 +02:00
|
|
|
n->oldCreateSubid = InvalidSubTransactionId;
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
n->oldFirstRelfilelocatorSubid = InvalidSubTransactionId;
|
2014-11-06 10:48:33 +01:00
|
|
|
n->primary = false;
|
|
|
|
|
n->isconstraint = false;
|
|
|
|
|
n->deferrable = false;
|
|
|
|
|
n->initdeferred = false;
|
Get rid of multiple applications of transformExpr() to the same tree.
transformExpr() has for many years had provisions to do nothing when
applied to an already-transformed expression tree. However, this was
always ugly and of dubious reliability, so we'd be much better off without
it. The primary historical reason for it was that gram.y sometimes
returned multiple links to the same subexpression, which is no longer true
as of my BETWEEN fixes. We'd also grown some lazy hacks in CREATE TABLE
LIKE (failing to distinguish between raw and already-transformed index
specifications) and one or two other places.
This patch removes the need for and support for re-transforming already
transformed expressions. The index case is dealt with by adding a flag
to struct IndexStmt to indicate that it's already been transformed;
which has some benefit anyway in that tablecmds.c can now Assert that
transformation has happened rather than just assuming. The other main
reason was some rather sloppy code for array type coercion, which can
be fixed (and its performance improved too) by refactoring.
I did leave transformJoinUsingClause() still constructing expressions
containing untransformed operator nodes being applied to Vars, so that
transformExpr() still has to allow Var inputs. But that's a much narrower,
and safer, special case than before, since Vars will never appear in a raw
parse tree, and they don't have any substructure to worry about.
In passing fix some oversights in the patch that added CREATE INDEX
IF NOT EXISTS (missing processing of IndexStmt.if_not_exists). These
appear relatively harmless, but still sloppy coding practice.
2015-02-22 19:59:09 +01:00
|
|
|
n->transformed = false;
|
2014-11-06 10:48:33 +01:00
|
|
|
n->if_not_exists = true;
|
Fix tablespace inheritance for partitioned rels
Commit ca4103025dfe left a few loose ends. The most important one
(broken pg_dump output) is already fixed by virtue of commit
3b23552ad8bb, but some things remained:
* When ALTER TABLE rewrites tables, the indexes must remain in the
tablespace they were originally in. This didn't work because
index recreation during ALTER TABLE runs manufactured SQL (yuck),
which runs afoul of default_tablespace in competition with the parent
relation tablespace. To fix, reset default_tablespace to the empty
string temporarily, and add the TABLESPACE clause as appropriate.
* Setting a partitioned rel's tablespace to the database default is
confusing; if it worked, it would direct the partitions to that
tablespace regardless of default_tablespace. But in reality it does
not work, and making it work is a larger project. Therefore, throw
an error when this condition is detected, to alert the unwary.
Add some docs and tests, too.
Author: Álvaro Herrera
Discussion: https://postgr.es/m/CAKJS1f_1c260nOt_vBJ067AZ3JXptXVRohDVMLEBmudX1YEx-A@mail.gmail.com
2019-04-25 16:20:23 +02:00
|
|
|
n->reset_default_tblspc = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2006-08-25 06:06:58 +02:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
2009-12-23 18:41:45 +01:00
|
|
|
opt_unique:
|
2017-08-16 06:22:32 +02:00
|
|
|
UNIQUE { $$ = true; }
|
|
|
|
|
| /*EMPTY*/ { $$ = false; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
access_method_clause:
|
2020-06-10 22:58:46 +02:00
|
|
|
USING name { $$ = $2; }
|
2002-06-18 02:28:11 +02:00
|
|
|
| /*EMPTY*/ { $$ = DEFAULT_INDEX_TYPE; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-08-15 09:42:52 +02:00
|
|
|
|
2004-05-31 01:40:41 +02:00
|
|
|
index_params: index_elem { $$ = list_make1($1); }
|
2003-05-28 18:04:02 +02:00
|
|
|
| index_params ',' index_elem { $$ = lappend($1, $3); }
|
1997-10-25 07:56:41 +02:00
|
|
|
;
|
|
|
|
|
|
Implement operator class parameters
PostgreSQL provides set of template index access methods, where opclasses have
much freedom in the semantics of indexing. These index AMs are GiST, GIN,
SP-GiST and BRIN. There opclasses define representation of keys, operations on
them and supported search strategies. So, it's natural that opclasses may be
faced some tradeoffs, which require user-side decision. This commit implements
opclass parameters allowing users to set some values, which tell opclass how to
index the particular dataset.
This commit doesn't introduce new storage in system catalog. Instead it uses
pg_attribute.attoptions, which is used for table column storage options but
unused for index attributes.
In order to evade changing signature of each opclass support function, we
implement unified way to pass options to opclass support functions. Options
are set to fn_expr as the constant bytea expression. It's possible due to the
fact that opclass support functions are executed outside of expressions, so
fn_expr is unused for them.
This commit comes with some examples of opclass options usage. We parametrize
signature length in GiST. That applies to multiple opclasses: tsvector_ops,
gist__intbig_ops, gist_ltree_ops, gist__ltree_ops, gist_trgm_ops and
gist_hstore_ops. Also we parametrize maximum number of integer ranges for
gist__int_ops. However, the main future usage of this feature is expected
to be json, where users would be able to specify which way to index particular
json parts.
Catversion is bumped.
Discussion: https://postgr.es/m/d22c3a18-31c7-1879-fc11-4c1ce2f5e5af%40postgrespro.ru
Author: Nikita Glukhov, revised by me
Reviwed-by: Nikolay Shaplov, Robert Haas, Tom Lane, Tomas Vondra, Alvaro Herrera
2020-03-30 18:17:11 +02:00
|
|
|
|
|
|
|
|
index_elem_options:
|
2022-07-22 12:57:01 +02:00
|
|
|
opt_collate opt_qualified_name opt_asc_desc opt_nulls_order
|
Implement operator class parameters
PostgreSQL provides set of template index access methods, where opclasses have
much freedom in the semantics of indexing. These index AMs are GiST, GIN,
SP-GiST and BRIN. There opclasses define representation of keys, operations on
them and supported search strategies. So, it's natural that opclasses may be
faced some tradeoffs, which require user-side decision. This commit implements
opclass parameters allowing users to set some values, which tell opclass how to
index the particular dataset.
This commit doesn't introduce new storage in system catalog. Instead it uses
pg_attribute.attoptions, which is used for table column storage options but
unused for index attributes.
In order to evade changing signature of each opclass support function, we
implement unified way to pass options to opclass support functions. Options
are set to fn_expr as the constant bytea expression. It's possible due to the
fact that opclass support functions are executed outside of expressions, so
fn_expr is unused for them.
This commit comes with some examples of opclass options usage. We parametrize
signature length in GiST. That applies to multiple opclasses: tsvector_ops,
gist__intbig_ops, gist_ltree_ops, gist__ltree_ops, gist_trgm_ops and
gist_hstore_ops. Also we parametrize maximum number of integer ranges for
gist__int_ops. However, the main future usage of this feature is expected
to be json, where users would be able to specify which way to index particular
json parts.
Catversion is bumped.
Discussion: https://postgr.es/m/d22c3a18-31c7-1879-fc11-4c1ce2f5e5af%40postgrespro.ru
Author: Nikita Glukhov, revised by me
Reviwed-by: Nikolay Shaplov, Robert Haas, Tom Lane, Tomas Vondra, Alvaro Herrera
2020-03-30 18:17:11 +02:00
|
|
|
{
|
|
|
|
|
$$ = makeNode(IndexElem);
|
|
|
|
|
$$->name = NULL;
|
|
|
|
|
$$->expr = NULL;
|
|
|
|
|
$$->indexcolname = NULL;
|
|
|
|
|
$$->collation = $1;
|
|
|
|
|
$$->opclass = $2;
|
|
|
|
|
$$->opclassopts = NIL;
|
|
|
|
|
$$->ordering = $3;
|
|
|
|
|
$$->nulls_ordering = $4;
|
|
|
|
|
}
|
|
|
|
|
| opt_collate any_name reloptions opt_asc_desc opt_nulls_order
|
|
|
|
|
{
|
|
|
|
|
$$ = makeNode(IndexElem);
|
|
|
|
|
$$->name = NULL;
|
|
|
|
|
$$->expr = NULL;
|
|
|
|
|
$$->indexcolname = NULL;
|
|
|
|
|
$$->collation = $1;
|
|
|
|
|
$$->opclass = $2;
|
|
|
|
|
$$->opclassopts = $3;
|
|
|
|
|
$$->ordering = $4;
|
|
|
|
|
$$->nulls_ordering = $5;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2003-05-28 18:04:02 +02:00
|
|
|
/*
|
|
|
|
|
* Index attributes can be either simple column references, or arbitrary
|
|
|
|
|
* expressions in parens. For backwards-compatibility reasons, we allow
|
|
|
|
|
* an expression that's just a function call to be written without parens.
|
|
|
|
|
*/
|
Implement operator class parameters
PostgreSQL provides set of template index access methods, where opclasses have
much freedom in the semantics of indexing. These index AMs are GiST, GIN,
SP-GiST and BRIN. There opclasses define representation of keys, operations on
them and supported search strategies. So, it's natural that opclasses may be
faced some tradeoffs, which require user-side decision. This commit implements
opclass parameters allowing users to set some values, which tell opclass how to
index the particular dataset.
This commit doesn't introduce new storage in system catalog. Instead it uses
pg_attribute.attoptions, which is used for table column storage options but
unused for index attributes.
In order to evade changing signature of each opclass support function, we
implement unified way to pass options to opclass support functions. Options
are set to fn_expr as the constant bytea expression. It's possible due to the
fact that opclass support functions are executed outside of expressions, so
fn_expr is unused for them.
This commit comes with some examples of opclass options usage. We parametrize
signature length in GiST. That applies to multiple opclasses: tsvector_ops,
gist__intbig_ops, gist_ltree_ops, gist__ltree_ops, gist_trgm_ops and
gist_hstore_ops. Also we parametrize maximum number of integer ranges for
gist__int_ops. However, the main future usage of this feature is expected
to be json, where users would be able to specify which way to index particular
json parts.
Catversion is bumped.
Discussion: https://postgr.es/m/d22c3a18-31c7-1879-fc11-4c1ce2f5e5af%40postgrespro.ru
Author: Nikita Glukhov, revised by me
Reviwed-by: Nikolay Shaplov, Robert Haas, Tom Lane, Tomas Vondra, Alvaro Herrera
2020-03-30 18:17:11 +02:00
|
|
|
index_elem: ColId index_elem_options
|
2003-05-28 18:04:02 +02:00
|
|
|
{
|
Implement operator class parameters
PostgreSQL provides set of template index access methods, where opclasses have
much freedom in the semantics of indexing. These index AMs are GiST, GIN,
SP-GiST and BRIN. There opclasses define representation of keys, operations on
them and supported search strategies. So, it's natural that opclasses may be
faced some tradeoffs, which require user-side decision. This commit implements
opclass parameters allowing users to set some values, which tell opclass how to
index the particular dataset.
This commit doesn't introduce new storage in system catalog. Instead it uses
pg_attribute.attoptions, which is used for table column storage options but
unused for index attributes.
In order to evade changing signature of each opclass support function, we
implement unified way to pass options to opclass support functions. Options
are set to fn_expr as the constant bytea expression. It's possible due to the
fact that opclass support functions are executed outside of expressions, so
fn_expr is unused for them.
This commit comes with some examples of opclass options usage. We parametrize
signature length in GiST. That applies to multiple opclasses: tsvector_ops,
gist__intbig_ops, gist_ltree_ops, gist__ltree_ops, gist_trgm_ops and
gist_hstore_ops. Also we parametrize maximum number of integer ranges for
gist__int_ops. However, the main future usage of this feature is expected
to be json, where users would be able to specify which way to index particular
json parts.
Catversion is bumped.
Discussion: https://postgr.es/m/d22c3a18-31c7-1879-fc11-4c1ce2f5e5af%40postgrespro.ru
Author: Nikita Glukhov, revised by me
Reviwed-by: Nikolay Shaplov, Robert Haas, Tom Lane, Tomas Vondra, Alvaro Herrera
2020-03-30 18:17:11 +02:00
|
|
|
$$ = $2;
|
2003-05-28 18:04:02 +02:00
|
|
|
$$->name = $1;
|
|
|
|
|
}
|
Implement operator class parameters
PostgreSQL provides set of template index access methods, where opclasses have
much freedom in the semantics of indexing. These index AMs are GiST, GIN,
SP-GiST and BRIN. There opclasses define representation of keys, operations on
them and supported search strategies. So, it's natural that opclasses may be
faced some tradeoffs, which require user-side decision. This commit implements
opclass parameters allowing users to set some values, which tell opclass how to
index the particular dataset.
This commit doesn't introduce new storage in system catalog. Instead it uses
pg_attribute.attoptions, which is used for table column storage options but
unused for index attributes.
In order to evade changing signature of each opclass support function, we
implement unified way to pass options to opclass support functions. Options
are set to fn_expr as the constant bytea expression. It's possible due to the
fact that opclass support functions are executed outside of expressions, so
fn_expr is unused for them.
This commit comes with some examples of opclass options usage. We parametrize
signature length in GiST. That applies to multiple opclasses: tsvector_ops,
gist__intbig_ops, gist_ltree_ops, gist__ltree_ops, gist_trgm_ops and
gist_hstore_ops. Also we parametrize maximum number of integer ranges for
gist__int_ops. However, the main future usage of this feature is expected
to be json, where users would be able to specify which way to index particular
json parts.
Catversion is bumped.
Discussion: https://postgr.es/m/d22c3a18-31c7-1879-fc11-4c1ce2f5e5af%40postgrespro.ru
Author: Nikita Glukhov, revised by me
Reviwed-by: Nikolay Shaplov, Robert Haas, Tom Lane, Tomas Vondra, Alvaro Herrera
2020-03-30 18:17:11 +02:00
|
|
|
| func_expr_windowless index_elem_options
|
1997-10-25 07:56:41 +02:00
|
|
|
{
|
Implement operator class parameters
PostgreSQL provides set of template index access methods, where opclasses have
much freedom in the semantics of indexing. These index AMs are GiST, GIN,
SP-GiST and BRIN. There opclasses define representation of keys, operations on
them and supported search strategies. So, it's natural that opclasses may be
faced some tradeoffs, which require user-side decision. This commit implements
opclass parameters allowing users to set some values, which tell opclass how to
index the particular dataset.
This commit doesn't introduce new storage in system catalog. Instead it uses
pg_attribute.attoptions, which is used for table column storage options but
unused for index attributes.
In order to evade changing signature of each opclass support function, we
implement unified way to pass options to opclass support functions. Options
are set to fn_expr as the constant bytea expression. It's possible due to the
fact that opclass support functions are executed outside of expressions, so
fn_expr is unused for them.
This commit comes with some examples of opclass options usage. We parametrize
signature length in GiST. That applies to multiple opclasses: tsvector_ops,
gist__intbig_ops, gist_ltree_ops, gist__ltree_ops, gist_trgm_ops and
gist_hstore_ops. Also we parametrize maximum number of integer ranges for
gist__int_ops. However, the main future usage of this feature is expected
to be json, where users would be able to specify which way to index particular
json parts.
Catversion is bumped.
Discussion: https://postgr.es/m/d22c3a18-31c7-1879-fc11-4c1ce2f5e5af%40postgrespro.ru
Author: Nikita Glukhov, revised by me
Reviwed-by: Nikolay Shaplov, Robert Haas, Tom Lane, Tomas Vondra, Alvaro Herrera
2020-03-30 18:17:11 +02:00
|
|
|
$$ = $2;
|
2004-09-30 01:39:20 +02:00
|
|
|
$$->expr = $1;
|
1997-10-25 07:56:41 +02:00
|
|
|
}
|
Implement operator class parameters
PostgreSQL provides set of template index access methods, where opclasses have
much freedom in the semantics of indexing. These index AMs are GiST, GIN,
SP-GiST and BRIN. There opclasses define representation of keys, operations on
them and supported search strategies. So, it's natural that opclasses may be
faced some tradeoffs, which require user-side decision. This commit implements
opclass parameters allowing users to set some values, which tell opclass how to
index the particular dataset.
This commit doesn't introduce new storage in system catalog. Instead it uses
pg_attribute.attoptions, which is used for table column storage options but
unused for index attributes.
In order to evade changing signature of each opclass support function, we
implement unified way to pass options to opclass support functions. Options
are set to fn_expr as the constant bytea expression. It's possible due to the
fact that opclass support functions are executed outside of expressions, so
fn_expr is unused for them.
This commit comes with some examples of opclass options usage. We parametrize
signature length in GiST. That applies to multiple opclasses: tsvector_ops,
gist__intbig_ops, gist_ltree_ops, gist__ltree_ops, gist_trgm_ops and
gist_hstore_ops. Also we parametrize maximum number of integer ranges for
gist__int_ops. However, the main future usage of this feature is expected
to be json, where users would be able to specify which way to index particular
json parts.
Catversion is bumped.
Discussion: https://postgr.es/m/d22c3a18-31c7-1879-fc11-4c1ce2f5e5af%40postgrespro.ru
Author: Nikita Glukhov, revised by me
Reviwed-by: Nikolay Shaplov, Robert Haas, Tom Lane, Tomas Vondra, Alvaro Herrera
2020-03-30 18:17:11 +02:00
|
|
|
| '(' a_expr ')' index_elem_options
|
1997-10-25 07:56:41 +02:00
|
|
|
{
|
Implement operator class parameters
PostgreSQL provides set of template index access methods, where opclasses have
much freedom in the semantics of indexing. These index AMs are GiST, GIN,
SP-GiST and BRIN. There opclasses define representation of keys, operations on
them and supported search strategies. So, it's natural that opclasses may be
faced some tradeoffs, which require user-side decision. This commit implements
opclass parameters allowing users to set some values, which tell opclass how to
index the particular dataset.
This commit doesn't introduce new storage in system catalog. Instead it uses
pg_attribute.attoptions, which is used for table column storage options but
unused for index attributes.
In order to evade changing signature of each opclass support function, we
implement unified way to pass options to opclass support functions. Options
are set to fn_expr as the constant bytea expression. It's possible due to the
fact that opclass support functions are executed outside of expressions, so
fn_expr is unused for them.
This commit comes with some examples of opclass options usage. We parametrize
signature length in GiST. That applies to multiple opclasses: tsvector_ops,
gist__intbig_ops, gist_ltree_ops, gist__ltree_ops, gist_trgm_ops and
gist_hstore_ops. Also we parametrize maximum number of integer ranges for
gist__int_ops. However, the main future usage of this feature is expected
to be json, where users would be able to specify which way to index particular
json parts.
Catversion is bumped.
Discussion: https://postgr.es/m/d22c3a18-31c7-1879-fc11-4c1ce2f5e5af%40postgrespro.ru
Author: Nikita Glukhov, revised by me
Reviwed-by: Nikolay Shaplov, Robert Haas, Tom Lane, Tomas Vondra, Alvaro Herrera
2020-03-30 18:17:11 +02:00
|
|
|
$$ = $4;
|
2003-05-28 18:04:02 +02:00
|
|
|
$$->expr = $2;
|
1997-10-25 07:56:41 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2018-04-07 22:00:39 +02:00
|
|
|
opt_include: INCLUDE '(' index_including_params ')' { $$ = $3; }
|
|
|
|
|
| /* EMPTY */ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
index_including_params: index_elem { $$ = list_make1($1); }
|
|
|
|
|
| index_including_params ',' index_elem { $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
2011-02-08 22:04:18 +01:00
|
|
|
opt_collate: COLLATE any_name { $$ = $2; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
1997-10-25 07:56:41 +02:00
|
|
|
|
2007-01-09 03:14:16 +01:00
|
|
|
opt_asc_desc: ASC { $$ = SORTBY_ASC; }
|
2008-09-01 22:42:46 +02:00
|
|
|
| DESC { $$ = SORTBY_DESC; }
|
|
|
|
|
| /*EMPTY*/ { $$ = SORTBY_DEFAULT; }
|
2007-01-09 03:14:16 +01:00
|
|
|
;
|
|
|
|
|
|
Improve parser's one-extra-token lookahead mechanism.
There are a couple of places in our grammar that fail to be strict LALR(1),
by requiring more than a single token of lookahead to decide what to do.
Up to now we've dealt with that by using a filter between the lexer and
parser that merges adjacent tokens into one in the places where two tokens
of lookahead are necessary. But that creates a number of user-visible
anomalies, for instance that you can't name a CTE "ordinality" because
"WITH ordinality AS ..." triggers folding of WITH and ORDINALITY into one
token. I realized that there's a better way.
In this patch, we still do the lookahead basically as before, but we never
merge the second token into the first; we replace just the first token by
a special lookahead symbol when one of the lookahead pairs is seen.
This requires a couple extra productions in the grammar, but it involves
fewer special tokens, so that the grammar tables come out a bit smaller
than before. The filter logic is no slower than before, perhaps a bit
faster.
I also fixed the filter logic so that when backing up after a lookahead,
the current token's terminator is correctly restored; this eliminates some
weird behavior in error message issuance, as is shown by the one change in
existing regression test outputs.
I believe that this patch entirely eliminates odd behaviors caused by
lookahead for WITH. It doesn't really improve the situation for NULLS
followed by FIRST/LAST unfortunately: those sequences still act like a
reserved word, even though there are cases where they should be seen as two
ordinary identifiers, eg "SELECT nulls first FROM ...". I experimented
with additional grammar hacks but couldn't find any simple solution for
that. Still, this is better than before, and it seems much more likely
that we *could* somehow solve the NULLS case on the basis of this filter
behavior than the previous one.
2015-02-24 23:53:42 +01:00
|
|
|
opt_nulls_order: NULLS_LA FIRST_P { $$ = SORTBY_NULLS_FIRST; }
|
|
|
|
|
| NULLS_LA LAST_P { $$ = SORTBY_NULLS_LAST; }
|
2007-01-09 03:14:16 +01:00
|
|
|
| /*EMPTY*/ { $$ = SORTBY_NULLS_DEFAULT; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* QUERY:
|
2001-10-02 23:39:36 +02:00
|
|
|
* create [or replace] function <fname>
|
2000-03-27 19:12:06 +02:00
|
|
|
* [(<type-1> { , <type-n>})]
|
|
|
|
|
* returns <type-r>
|
|
|
|
|
* as <filename or code in language as appropriate>
|
2001-10-02 23:39:36 +02:00
|
|
|
* language <lang> [with parameters]
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
CreateFunctionStmt:
|
2008-12-04 18:51:28 +01:00
|
|
|
CREATE opt_or_replace FUNCTION func_name func_args_with_defaults
|
2021-04-07 21:30:08 +02:00
|
|
|
RETURNS func_return opt_createfunc_opt_list opt_routine_body
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2002-05-17 20:32:52 +02:00
|
|
|
CreateFunctionStmt *n = makeNode(CreateFunctionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2018-01-26 18:25:44 +01:00
|
|
|
n->is_procedure = false;
|
2001-10-02 23:39:36 +02:00
|
|
|
n->replace = $2;
|
2002-04-09 22:35:55 +02:00
|
|
|
n->funcname = $4;
|
2004-01-07 00:55:19 +01:00
|
|
|
n->parameters = $5;
|
2002-03-29 20:06:29 +01:00
|
|
|
n->returnType = $7;
|
2002-05-17 20:32:52 +02:00
|
|
|
n->options = $8;
|
2021-04-07 21:30:08 +02:00
|
|
|
n->sql_body = $9;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-06-17 22:27:43 +02:00
|
|
|
}
|
2008-12-04 18:51:28 +01:00
|
|
|
| CREATE opt_or_replace FUNCTION func_name func_args_with_defaults
|
2021-04-07 21:30:08 +02:00
|
|
|
RETURNS TABLE '(' table_func_column_list ')' opt_createfunc_opt_list opt_routine_body
|
2008-07-18 05:32:53 +02:00
|
|
|
{
|
|
|
|
|
CreateFunctionStmt *n = makeNode(CreateFunctionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2018-01-26 18:25:44 +01:00
|
|
|
n->is_procedure = false;
|
2008-07-18 05:32:53 +02:00
|
|
|
n->replace = $2;
|
|
|
|
|
n->funcname = $4;
|
|
|
|
|
n->parameters = mergeTableFuncParameters($5, $9);
|
|
|
|
|
n->returnType = TableFuncTypeName($9);
|
|
|
|
|
n->returnType->location = @7;
|
|
|
|
|
n->options = $11;
|
2021-04-07 21:30:08 +02:00
|
|
|
n->sql_body = $12;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2008-07-18 05:32:53 +02:00
|
|
|
}
|
2008-12-04 18:51:28 +01:00
|
|
|
| CREATE opt_or_replace FUNCTION func_name func_args_with_defaults
|
2021-04-07 21:30:08 +02:00
|
|
|
opt_createfunc_opt_list opt_routine_body
|
2005-04-01 00:46:33 +02:00
|
|
|
{
|
|
|
|
|
CreateFunctionStmt *n = makeNode(CreateFunctionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2018-01-26 18:25:44 +01:00
|
|
|
n->is_procedure = false;
|
2005-04-01 00:46:33 +02:00
|
|
|
n->replace = $2;
|
|
|
|
|
n->funcname = $4;
|
|
|
|
|
n->parameters = $5;
|
|
|
|
|
n->returnType = NULL;
|
|
|
|
|
n->options = $6;
|
2021-04-07 21:30:08 +02:00
|
|
|
n->sql_body = $7;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-04-01 00:46:33 +02:00
|
|
|
}
|
2017-11-30 14:46:13 +01:00
|
|
|
| CREATE opt_or_replace PROCEDURE func_name func_args_with_defaults
|
2021-04-07 21:30:08 +02:00
|
|
|
opt_createfunc_opt_list opt_routine_body
|
2017-11-30 14:46:13 +01:00
|
|
|
{
|
|
|
|
|
CreateFunctionStmt *n = makeNode(CreateFunctionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2018-01-26 18:25:44 +01:00
|
|
|
n->is_procedure = true;
|
2017-11-30 14:46:13 +01:00
|
|
|
n->replace = $2;
|
|
|
|
|
n->funcname = $4;
|
|
|
|
|
n->parameters = $5;
|
|
|
|
|
n->returnType = NULL;
|
|
|
|
|
n->options = $6;
|
2021-04-07 21:30:08 +02:00
|
|
|
n->sql_body = $7;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-11-30 14:46:13 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
;
|
1997-09-08 05:20:18 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
opt_or_replace:
|
2017-08-16 06:22:32 +02:00
|
|
|
OR REPLACE { $$ = true; }
|
|
|
|
|
| /*EMPTY*/ { $$ = false; }
|
2001-10-02 23:39:36 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
func_args: '(' func_args_list ')' { $$ = $2; }
|
|
|
|
|
| '(' ')' { $$ = NIL; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
func_args_list:
|
2004-05-31 01:40:41 +02:00
|
|
|
func_arg { $$ = list_make1($1); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| func_args_list ',' func_arg { $$ = lappend($1, $3); }
|
2000-03-27 19:12:06 +02:00
|
|
|
;
|
|
|
|
|
|
2016-09-15 19:00:00 +02:00
|
|
|
function_with_argtypes_list:
|
|
|
|
|
function_with_argtypes { $$ = list_make1($1); }
|
|
|
|
|
| function_with_argtypes_list ',' function_with_argtypes
|
|
|
|
|
{ $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
function_with_argtypes:
|
|
|
|
|
func_name func_args
|
|
|
|
|
{
|
2016-12-28 18:00:00 +01:00
|
|
|
ObjectWithArgs *n = makeNode(ObjectWithArgs);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2016-12-28 18:00:00 +01:00
|
|
|
n->objname = $1;
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
n->objargs = extractArgTypes($2);
|
|
|
|
|
n->objfuncargs = $2;
|
2016-09-15 19:00:00 +02:00
|
|
|
$$ = n;
|
|
|
|
|
}
|
2017-03-10 05:58:48 +01:00
|
|
|
/*
|
|
|
|
|
* Because of reduce/reduce conflicts, we can't use func_name
|
|
|
|
|
* below, but we can write it out the long way, which actually
|
|
|
|
|
* allows more cases.
|
|
|
|
|
*/
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| type_func_name_keyword
|
2017-03-10 05:58:48 +01:00
|
|
|
{
|
|
|
|
|
ObjectWithArgs *n = makeNode(ObjectWithArgs);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-03-10 05:58:48 +01:00
|
|
|
n->objname = list_make1(makeString(pstrdup($1)));
|
|
|
|
|
n->args_unspecified = true;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| ColId
|
|
|
|
|
{
|
|
|
|
|
ObjectWithArgs *n = makeNode(ObjectWithArgs);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-03-10 05:58:48 +01:00
|
|
|
n->objname = list_make1(makeString($1));
|
|
|
|
|
n->args_unspecified = true;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| ColId indirection
|
|
|
|
|
{
|
|
|
|
|
ObjectWithArgs *n = makeNode(ObjectWithArgs);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-03-10 05:58:48 +01:00
|
|
|
n->objname = check_func_name(lcons(makeString($1), $2),
|
|
|
|
|
yyscanner);
|
|
|
|
|
n->args_unspecified = true;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2016-09-15 19:00:00 +02:00
|
|
|
;
|
|
|
|
|
|
2008-12-04 18:51:28 +01:00
|
|
|
/*
|
|
|
|
|
* func_args_with_defaults is separate because we only want to accept
|
|
|
|
|
* defaults in CREATE FUNCTION, not in ALTER etc.
|
|
|
|
|
*/
|
|
|
|
|
func_args_with_defaults:
|
|
|
|
|
'(' func_args_with_defaults_list ')' { $$ = $2; }
|
2008-12-18 19:20:35 +01:00
|
|
|
| '(' ')' { $$ = NIL; }
|
2008-12-04 18:51:28 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
func_args_with_defaults_list:
|
2008-12-18 19:20:35 +01:00
|
|
|
func_arg_with_default { $$ = list_make1($1); }
|
|
|
|
|
| func_args_with_defaults_list ',' func_arg_with_default
|
|
|
|
|
{ $$ = lappend($1, $3); }
|
2008-12-04 18:51:28 +01:00
|
|
|
;
|
|
|
|
|
|
2005-03-29 19:58:51 +02:00
|
|
|
/*
|
|
|
|
|
* The style with arg_class first is SQL99 standard, but Oracle puts
|
|
|
|
|
* param_name first; accept both since it's likely people will try both
|
|
|
|
|
* anyway. Don't bother trying to save productions by letting arg_class
|
|
|
|
|
* have an empty alternative ... you'll get shift/reduce conflicts.
|
|
|
|
|
*
|
|
|
|
|
* We can catch over-specified arguments here if we want to,
|
2004-01-07 00:55:19 +01:00
|
|
|
* but for now better to silently swallow typmod, etc.
|
|
|
|
|
* - thomas 2000-03-22
|
|
|
|
|
*/
|
|
|
|
|
func_arg:
|
|
|
|
|
arg_class param_name func_type
|
2000-07-14 17:43:57 +02:00
|
|
|
{
|
2004-01-07 00:55:19 +01:00
|
|
|
FunctionParameter *n = makeNode(FunctionParameter);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-01-07 00:55:19 +01:00
|
|
|
n->name = $2;
|
|
|
|
|
n->argType = $3;
|
2005-03-29 19:58:51 +02:00
|
|
|
n->mode = $1;
|
2008-12-04 18:51:28 +01:00
|
|
|
n->defexpr = NULL;
|
2004-01-07 00:55:19 +01:00
|
|
|
$$ = n;
|
|
|
|
|
}
|
2005-03-29 19:58:51 +02:00
|
|
|
| param_name arg_class func_type
|
2004-01-07 00:55:19 +01:00
|
|
|
{
|
|
|
|
|
FunctionParameter *n = makeNode(FunctionParameter);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-03-29 19:58:51 +02:00
|
|
|
n->name = $1;
|
|
|
|
|
n->argType = $3;
|
|
|
|
|
n->mode = $2;
|
2008-12-04 18:51:28 +01:00
|
|
|
n->defexpr = NULL;
|
2005-03-29 19:58:51 +02:00
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| param_name func_type
|
|
|
|
|
{
|
|
|
|
|
FunctionParameter *n = makeNode(FunctionParameter);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-03-29 19:58:51 +02:00
|
|
|
n->name = $1;
|
2004-01-07 00:55:19 +01:00
|
|
|
n->argType = $2;
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
n->mode = FUNC_PARAM_DEFAULT;
|
2008-12-04 18:51:28 +01:00
|
|
|
n->defexpr = NULL;
|
2004-01-07 00:55:19 +01:00
|
|
|
$$ = n;
|
2000-07-14 17:43:57 +02:00
|
|
|
}
|
2005-03-29 19:58:51 +02:00
|
|
|
| arg_class func_type
|
2000-07-14 17:43:57 +02:00
|
|
|
{
|
2005-03-29 19:58:51 +02:00
|
|
|
FunctionParameter *n = makeNode(FunctionParameter);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-03-29 19:58:51 +02:00
|
|
|
n->name = NULL;
|
|
|
|
|
n->argType = $2;
|
|
|
|
|
n->mode = $1;
|
2008-12-04 18:51:28 +01:00
|
|
|
n->defexpr = NULL;
|
2005-03-29 19:58:51 +02:00
|
|
|
$$ = n;
|
2000-07-14 17:43:57 +02:00
|
|
|
}
|
2005-03-29 19:58:51 +02:00
|
|
|
| func_type
|
2000-07-14 17:43:57 +02:00
|
|
|
{
|
2005-03-29 19:58:51 +02:00
|
|
|
FunctionParameter *n = makeNode(FunctionParameter);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-03-29 19:58:51 +02:00
|
|
|
n->name = NULL;
|
|
|
|
|
n->argType = $1;
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
n->mode = FUNC_PARAM_DEFAULT;
|
2008-12-04 18:51:28 +01:00
|
|
|
n->defexpr = NULL;
|
2005-03-29 19:58:51 +02:00
|
|
|
$$ = n;
|
2000-07-14 17:43:57 +02:00
|
|
|
}
|
2005-03-29 19:58:51 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/* INOUT is SQL99 standard, IN OUT is for Oracle compatibility */
|
2008-07-16 03:30:23 +02:00
|
|
|
arg_class: IN_P { $$ = FUNC_PARAM_IN; }
|
|
|
|
|
| OUT_P { $$ = FUNC_PARAM_OUT; }
|
|
|
|
|
| INOUT { $$ = FUNC_PARAM_INOUT; }
|
|
|
|
|
| IN_P OUT_P { $$ = FUNC_PARAM_INOUT; }
|
|
|
|
|
| VARIADIC { $$ = FUNC_PARAM_VARIADIC; }
|
2004-01-07 00:55:19 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Ideally param_name should be ColId, but that causes too many conflicts.
|
|
|
|
|
*/
|
2006-12-30 22:21:56 +01:00
|
|
|
param_name: type_function_name
|
2000-07-14 17:43:57 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
func_return:
|
|
|
|
|
func_type
|
1998-02-11 05:09:54 +01:00
|
|
|
{
|
2005-04-01 00:46:33 +02:00
|
|
|
/* We can catch over-specified results here if we want to,
|
2000-03-27 19:12:06 +02:00
|
|
|
* but for now better to silently swallow typmod, etc.
|
|
|
|
|
* - thomas 2000-03-22
|
|
|
|
|
*/
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
1998-02-11 05:09:54 +01:00
|
|
|
;
|
|
|
|
|
|
2001-11-10 23:31:49 +01:00
|
|
|
/*
|
2006-01-31 23:40:03 +01:00
|
|
|
* We would like to make the %TYPE productions here be ColId attrs etc,
|
2006-12-30 22:21:56 +01:00
|
|
|
* but that causes reduce/reduce conflicts. type_function_name
|
|
|
|
|
* is next best choice.
|
2001-11-10 23:31:49 +01:00
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
func_type: Typename { $$ = $1; }
|
2006-12-30 22:21:56 +01:00
|
|
|
| type_function_name attrs '%' TYPE_P
|
2001-06-05 01:27:23 +02:00
|
|
|
{
|
2006-12-30 22:21:56 +01:00
|
|
|
$$ = makeTypeNameFromNameList(lcons(makeString($1), $2));
|
2002-03-29 20:06:29 +01:00
|
|
|
$$->pct_type = true;
|
2006-03-14 23:48:25 +01:00
|
|
|
$$->location = @1;
|
2001-06-05 01:27:23 +02:00
|
|
|
}
|
2006-12-30 22:21:56 +01:00
|
|
|
| SETOF type_function_name attrs '%' TYPE_P
|
2006-01-31 23:40:03 +01:00
|
|
|
{
|
2006-12-30 22:21:56 +01:00
|
|
|
$$ = makeTypeNameFromNameList(lcons(makeString($2), $3));
|
2006-01-31 23:40:03 +01:00
|
|
|
$$->pct_type = true;
|
2017-08-16 06:22:32 +02:00
|
|
|
$$->setof = true;
|
2006-03-14 23:48:25 +01:00
|
|
|
$$->location = @2;
|
2006-01-31 23:40:03 +01:00
|
|
|
}
|
2001-06-05 01:27:23 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2008-12-04 18:51:28 +01:00
|
|
|
func_arg_with_default:
|
|
|
|
|
func_arg
|
2011-11-01 20:50:00 +01:00
|
|
|
{
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
2008-12-04 18:51:28 +01:00
|
|
|
| func_arg DEFAULT a_expr
|
2011-11-01 20:50:00 +01:00
|
|
|
{
|
|
|
|
|
$$ = $1;
|
|
|
|
|
$$->defexpr = $3;
|
|
|
|
|
}
|
2008-12-04 18:51:28 +01:00
|
|
|
| func_arg '=' a_expr
|
2011-11-01 20:50:00 +01:00
|
|
|
{
|
|
|
|
|
$$ = $1;
|
|
|
|
|
$$->defexpr = $3;
|
|
|
|
|
}
|
2008-12-04 18:51:28 +01:00
|
|
|
;
|
|
|
|
|
|
Allow aggregate functions to be VARIADIC.
There's no inherent reason why an aggregate function can't be variadic
(even VARIADIC ANY) if its transition function can handle the case.
Indeed, this patch to add the feature touches none of the planner or
executor, and little of the parser; the main missing stuff was DDL and
pg_dump support.
It is true that variadic aggregates can create the same sort of ambiguity
about parameters versus ORDER BY keys that was complained of when we
(briefly) had both one- and two-argument forms of string_agg(). However,
the policy formed in response to that discussion only said that we'd not
create any built-in aggregates with varying numbers of arguments, not that
we shouldn't allow users to do it. So the logical extension of that is
we can allow users to make variadic aggregates as long as we're wary about
shipping any such in core.
In passing, this patch allows aggregate function arguments to be named, to
the extent of remembering the names in pg_proc and dumping them in pg_dump.
You can't yet call an aggregate using named-parameter notation. That seems
like a likely future extension, but it'll take some work, and it's not what
this patch is really about. Likewise, there's still some work needed to
make window functions handle VARIADIC fully, but I left that for another
day.
initdb forced because of new aggvariadic field in Aggref parse nodes.
2013-09-03 23:08:38 +02:00
|
|
|
/* Aggregate args can be most things that function args can be */
|
|
|
|
|
aggr_arg: func_arg
|
|
|
|
|
{
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
if (!($1->mode == FUNC_PARAM_DEFAULT ||
|
|
|
|
|
$1->mode == FUNC_PARAM_IN ||
|
Allow aggregate functions to be VARIADIC.
There's no inherent reason why an aggregate function can't be variadic
(even VARIADIC ANY) if its transition function can handle the case.
Indeed, this patch to add the feature touches none of the planner or
executor, and little of the parser; the main missing stuff was DDL and
pg_dump support.
It is true that variadic aggregates can create the same sort of ambiguity
about parameters versus ORDER BY keys that was complained of when we
(briefly) had both one- and two-argument forms of string_agg(). However,
the policy formed in response to that discussion only said that we'd not
create any built-in aggregates with varying numbers of arguments, not that
we shouldn't allow users to do it. So the logical extension of that is
we can allow users to make variadic aggregates as long as we're wary about
shipping any such in core.
In passing, this patch allows aggregate function arguments to be named, to
the extent of remembering the names in pg_proc and dumping them in pg_dump.
You can't yet call an aggregate using named-parameter notation. That seems
like a likely future extension, but it'll take some work, and it's not what
this patch is really about. Likewise, there's still some work needed to
make window functions handle VARIADIC fully, but I left that for another
day.
initdb forced because of new aggvariadic field in Aggref parse nodes.
2013-09-03 23:08:38 +02:00
|
|
|
$1->mode == FUNC_PARAM_VARIADIC))
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
|
errmsg("aggregates cannot have output arguments"),
|
|
|
|
|
parser_errposition(@1)));
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
/*
|
|
|
|
|
* The SQL standard offers no guidance on how to declare aggregate argument
|
|
|
|
|
* lists, since it doesn't have CREATE AGGREGATE etc. We accept these cases:
|
|
|
|
|
*
|
|
|
|
|
* (*) - normal agg with no args
|
|
|
|
|
* (aggr_arg,...) - normal agg with args
|
|
|
|
|
* (ORDER BY aggr_arg,...) - ordered-set agg with no direct args
|
|
|
|
|
* (aggr_arg,... ORDER BY aggr_arg,...) - ordered-set agg with direct args
|
|
|
|
|
*
|
|
|
|
|
* The zero-argument case is spelled with '*' for consistency with COUNT(*).
|
|
|
|
|
*
|
|
|
|
|
* An additional restriction is that if the direct-args list ends in a
|
|
|
|
|
* VARIADIC item, the ordered-args list must contain exactly one item that
|
|
|
|
|
* is also VARIADIC with the same type. This allows us to collapse the two
|
|
|
|
|
* VARIADIC items into one, which is necessary to represent the aggregate in
|
|
|
|
|
* pg_proc. We check this at the grammar stage so that we can return a list
|
|
|
|
|
* in which the second VARIADIC item is already discarded, avoiding extra work
|
|
|
|
|
* in cases such as DROP AGGREGATE.
|
|
|
|
|
*
|
|
|
|
|
* The return value of this production is a two-element list, in which the
|
|
|
|
|
* first item is a sublist of FunctionParameter nodes (with any duplicate
|
Remove Value node struct
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and the node
type don't match most of the time, and so it has to be treated
specially a lot. There doesn't seem to be any value in the special
construct. There is very little code that wants to accept all Value
variants but nothing else (and even if it did, this doesn't provide
any convenient way to check it), and most code wants either just one
particular node type (usually String), or it accepts a broader set of
node types besides just Value.
This change removes the Value struct and node type and replaces them
by separate Integer, Float, String, and BitString node types that are
proper node types and structs of their own and behave mostly like
normal node types.
Also, this removes the T_Null node tag, which was previously also a
possible variant of Value but wasn't actually used outside of the
Value contained in A_Const. Replace that by an isnull field in
A_Const.
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/5ba6bc5b-3f95-04f2-2419-f8ddb4c046fb@enterprisedb.com
2021-09-09 07:58:12 +02:00
|
|
|
* VARIADIC item already dropped, as per above) and the second is an Integer
|
|
|
|
|
* node, containing -1 if there was no ORDER BY and otherwise the number
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
* of argument declarations before the ORDER BY. (If this number is equal
|
|
|
|
|
* to the first sublist's length, then we dropped a duplicate VARIADIC item.)
|
|
|
|
|
* This representation is passed as-is to CREATE AGGREGATE; for operations
|
|
|
|
|
* on existing aggregates, we can just apply extractArgTypes to the first
|
|
|
|
|
* sublist.
|
|
|
|
|
*/
|
|
|
|
|
aggr_args: '(' '*' ')'
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make2(NIL, makeInteger(-1));
|
|
|
|
|
}
|
|
|
|
|
| '(' aggr_args_list ')'
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make2($2, makeInteger(-1));
|
|
|
|
|
}
|
|
|
|
|
| '(' ORDER BY aggr_args_list ')'
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make2($4, makeInteger(0));
|
|
|
|
|
}
|
|
|
|
|
| '(' aggr_args_list ORDER BY aggr_args_list ')'
|
|
|
|
|
{
|
|
|
|
|
/* this is the only case requiring consistency checking */
|
|
|
|
|
$$ = makeOrderedSetArgs($2, $5, yyscanner);
|
|
|
|
|
}
|
Allow aggregate functions to be VARIADIC.
There's no inherent reason why an aggregate function can't be variadic
(even VARIADIC ANY) if its transition function can handle the case.
Indeed, this patch to add the feature touches none of the planner or
executor, and little of the parser; the main missing stuff was DDL and
pg_dump support.
It is true that variadic aggregates can create the same sort of ambiguity
about parameters versus ORDER BY keys that was complained of when we
(briefly) had both one- and two-argument forms of string_agg(). However,
the policy formed in response to that discussion only said that we'd not
create any built-in aggregates with varying numbers of arguments, not that
we shouldn't allow users to do it. So the logical extension of that is
we can allow users to make variadic aggregates as long as we're wary about
shipping any such in core.
In passing, this patch allows aggregate function arguments to be named, to
the extent of remembering the names in pg_proc and dumping them in pg_dump.
You can't yet call an aggregate using named-parameter notation. That seems
like a likely future extension, but it'll take some work, and it's not what
this patch is really about. Likewise, there's still some work needed to
make window functions handle VARIADIC fully, but I left that for another
day.
initdb forced because of new aggvariadic field in Aggref parse nodes.
2013-09-03 23:08:38 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
aggr_args_list:
|
|
|
|
|
aggr_arg { $$ = list_make1($1); }
|
|
|
|
|
| aggr_args_list ',' aggr_arg { $$ = lappend($1, $3); }
|
|
|
|
|
;
|
2002-05-17 20:32:52 +02:00
|
|
|
|
2016-09-15 19:00:00 +02:00
|
|
|
aggregate_with_argtypes:
|
|
|
|
|
func_name aggr_args
|
|
|
|
|
{
|
2016-12-28 18:00:00 +01:00
|
|
|
ObjectWithArgs *n = makeNode(ObjectWithArgs);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2016-12-28 18:00:00 +01:00
|
|
|
n->objname = $1;
|
|
|
|
|
n->objargs = extractAggrArgTypes($2);
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
n->objfuncargs = (List *) linitial($2);
|
2016-09-15 19:00:00 +02:00
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2016-12-28 18:00:00 +01:00
|
|
|
aggregate_with_argtypes_list:
|
|
|
|
|
aggregate_with_argtypes { $$ = list_make1($1); }
|
|
|
|
|
| aggregate_with_argtypes_list ',' aggregate_with_argtypes
|
|
|
|
|
{ $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
2021-04-07 21:30:08 +02:00
|
|
|
opt_createfunc_opt_list:
|
|
|
|
|
createfunc_opt_list
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
createfunc_opt_list:
|
2002-06-18 02:28:11 +02:00
|
|
|
/* Must be at least one to prevent conflict */
|
2011-11-01 20:50:00 +01:00
|
|
|
createfunc_opt_item { $$ = list_make1($1); }
|
2002-06-18 02:28:11 +02:00
|
|
|
| createfunc_opt_list createfunc_opt_item { $$ = lappend($1, $2); }
|
|
|
|
|
;
|
2002-05-17 20:32:52 +02:00
|
|
|
|
2005-03-14 01:19:37 +01:00
|
|
|
/*
|
|
|
|
|
* Options common to both CREATE FUNCTION and ALTER FUNCTION
|
|
|
|
|
*/
|
|
|
|
|
common_func_opt_item:
|
|
|
|
|
CALLED ON NULL_P INPUT_P
|
2002-05-17 20:32:52 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("strict", (Node *) makeBoolean(false), @1);
|
2002-05-17 20:32:52 +02:00
|
|
|
}
|
2005-03-14 01:19:37 +01:00
|
|
|
| RETURNS NULL_P ON NULL_P INPUT_P
|
2002-05-17 20:32:52 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("strict", (Node *) makeBoolean(true), @1);
|
2005-03-14 01:19:37 +01:00
|
|
|
}
|
|
|
|
|
| STRICT_P
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("strict", (Node *) makeBoolean(true), @1);
|
2002-05-17 20:32:52 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| IMMUTABLE
|
2002-05-17 20:32:52 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("volatility", (Node *) makeString("immutable"), @1);
|
2002-05-17 20:32:52 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| STABLE
|
2002-05-17 20:32:52 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("volatility", (Node *) makeString("stable"), @1);
|
2002-05-17 20:32:52 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| VOLATILE
|
2002-05-17 20:32:52 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("volatility", (Node *) makeString("volatile"), @1);
|
2002-05-17 20:32:52 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| EXTERNAL SECURITY DEFINER
|
2002-05-17 20:32:52 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("security", (Node *) makeBoolean(true), @1);
|
2002-05-17 20:32:52 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| EXTERNAL SECURITY INVOKER
|
2002-05-17 20:32:52 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("security", (Node *) makeBoolean(false), @1);
|
2002-05-17 20:32:52 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| SECURITY DEFINER
|
2002-05-17 20:32:52 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("security", (Node *) makeBoolean(true), @1);
|
2002-05-17 20:32:52 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| SECURITY INVOKER
|
2002-05-17 20:32:52 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("security", (Node *) makeBoolean(false), @1);
|
2002-05-17 20:32:52 +02:00
|
|
|
}
|
2012-02-14 04:20:27 +01:00
|
|
|
| LEAKPROOF
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("leakproof", (Node *) makeBoolean(true), @1);
|
2012-02-14 04:20:27 +01:00
|
|
|
}
|
2012-02-15 16:45:08 +01:00
|
|
|
| NOT LEAKPROOF
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("leakproof", (Node *) makeBoolean(false), @1);
|
2012-02-15 16:45:08 +01:00
|
|
|
}
|
2007-01-22 02:35:23 +01:00
|
|
|
| COST NumericOnly
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("cost", (Node *) $2, @1);
|
2007-01-22 02:35:23 +01:00
|
|
|
}
|
|
|
|
|
| ROWS NumericOnly
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("rows", (Node *) $2, @1);
|
2007-01-22 02:35:23 +01:00
|
|
|
}
|
2019-02-10 00:08:48 +01:00
|
|
|
| SUPPORT any_name
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("support", (Node *) $2, @1);
|
2019-02-10 00:08:48 +01:00
|
|
|
}
|
2012-02-15 16:45:08 +01:00
|
|
|
| FunctionSetResetClause
|
2007-09-03 02:39:26 +02:00
|
|
|
{
|
|
|
|
|
/* we abuse the normal content of a DefElem here */
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("set", (Node *) $1, @1);
|
2007-09-03 02:39:26 +02:00
|
|
|
}
|
2015-09-16 21:38:47 +02:00
|
|
|
| PARALLEL ColId
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("parallel", (Node *) makeString($2), @1);
|
2015-09-16 21:38:47 +02:00
|
|
|
}
|
2002-05-17 20:32:52 +02:00
|
|
|
;
|
|
|
|
|
|
2005-03-14 01:19:37 +01:00
|
|
|
createfunc_opt_item:
|
|
|
|
|
AS func_as
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("as", (Node *) $2, @1);
|
2005-03-14 01:19:37 +01:00
|
|
|
}
|
2013-06-03 02:09:20 +02:00
|
|
|
| LANGUAGE NonReservedWord_or_Sconst
|
2005-03-14 01:19:37 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("language", (Node *) makeString($2), @1);
|
2005-03-14 01:19:37 +01:00
|
|
|
}
|
2015-04-26 16:33:14 +02:00
|
|
|
| TRANSFORM transform_type_list
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("transform", (Node *) $2, @1);
|
2015-04-26 16:33:14 +02:00
|
|
|
}
|
2008-12-31 03:25:06 +01:00
|
|
|
| WINDOW
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("window", (Node *) makeBoolean(true), @1);
|
2008-12-31 03:25:06 +01:00
|
|
|
}
|
2005-03-14 01:19:37 +01:00
|
|
|
| common_func_opt_item
|
|
|
|
|
{
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2004-05-31 01:40:41 +02:00
|
|
|
func_as: Sconst { $$ = list_make1(makeString($1)); }
|
2002-06-18 19:56:41 +02:00
|
|
|
| Sconst ',' Sconst
|
|
|
|
|
{
|
2004-05-31 01:40:41 +02:00
|
|
|
$$ = list_make2(makeString($1), makeString($3));
|
2002-06-18 19:56:41 +02:00
|
|
|
}
|
2002-05-17 20:32:52 +02:00
|
|
|
;
|
|
|
|
|
|
2021-04-07 21:30:08 +02:00
|
|
|
ReturnStmt: RETURN a_expr
|
|
|
|
|
{
|
|
|
|
|
ReturnStmt *r = makeNode(ReturnStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-04-07 21:30:08 +02:00
|
|
|
r->returnval = (Node *) $2;
|
|
|
|
|
$$ = (Node *) r;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_routine_body:
|
|
|
|
|
ReturnStmt
|
|
|
|
|
{
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
|
|
|
|
| BEGIN_P ATOMIC routine_body_stmt_list END_P
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* A compound statement is stored as a single-item list
|
|
|
|
|
* containing the list of statements as its member. That
|
|
|
|
|
* way, the parse analysis code can tell apart an empty
|
|
|
|
|
* body from no body at all.
|
|
|
|
|
*/
|
|
|
|
|
$$ = (Node *) list_make1($3);
|
|
|
|
|
}
|
|
|
|
|
| /*EMPTY*/
|
|
|
|
|
{
|
|
|
|
|
$$ = NULL;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
routine_body_stmt_list:
|
|
|
|
|
routine_body_stmt_list routine_body_stmt ';'
|
|
|
|
|
{
|
2021-06-08 17:59:34 +02:00
|
|
|
/* As in stmtmulti, discard empty statements */
|
|
|
|
|
if ($2 != NULL)
|
|
|
|
|
$$ = lappend($1, $2);
|
|
|
|
|
else
|
|
|
|
|
$$ = $1;
|
2021-04-07 21:30:08 +02:00
|
|
|
}
|
|
|
|
|
| /*EMPTY*/
|
|
|
|
|
{
|
|
|
|
|
$$ = NIL;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
routine_body_stmt:
|
|
|
|
|
stmt
|
|
|
|
|
| ReturnStmt
|
|
|
|
|
;
|
|
|
|
|
|
2015-04-26 16:33:14 +02:00
|
|
|
transform_type_list:
|
|
|
|
|
FOR TYPE_P Typename { $$ = list_make1($3); }
|
|
|
|
|
| transform_type_list ',' FOR TYPE_P Typename { $$ = lappend($1, $5); }
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
opt_definition:
|
|
|
|
|
WITH definition { $$ = $2; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
2002-05-17 20:32:52 +02:00
|
|
|
;
|
|
|
|
|
|
2008-07-18 05:32:53 +02:00
|
|
|
table_func_column: param_name func_type
|
|
|
|
|
{
|
|
|
|
|
FunctionParameter *n = makeNode(FunctionParameter);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-07-18 05:32:53 +02:00
|
|
|
n->name = $1;
|
|
|
|
|
n->argType = $2;
|
|
|
|
|
n->mode = FUNC_PARAM_TABLE;
|
2008-12-18 19:20:35 +01:00
|
|
|
n->defexpr = NULL;
|
2008-07-18 05:32:53 +02:00
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
table_func_column_list:
|
|
|
|
|
table_func_column
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make1($1);
|
|
|
|
|
}
|
|
|
|
|
| table_func_column_list ',' table_func_column
|
|
|
|
|
{
|
|
|
|
|
$$ = lappend($1, $3);
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2005-03-14 01:19:37 +01:00
|
|
|
/*****************************************************************************
|
2017-11-30 14:46:13 +01:00
|
|
|
* ALTER FUNCTION / ALTER PROCEDURE / ALTER ROUTINE
|
2005-03-14 01:19:37 +01:00
|
|
|
*
|
|
|
|
|
* RENAME and OWNER subcommands are already provided by the generic
|
|
|
|
|
* ALTER infrastructure, here we just specify alterations that can
|
|
|
|
|
* only be applied to functions.
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
AlterFunctionStmt:
|
|
|
|
|
ALTER FUNCTION function_with_argtypes alterfunc_opt_list opt_restrict
|
|
|
|
|
{
|
|
|
|
|
AlterFunctionStmt *n = makeNode(AlterFunctionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->objtype = OBJECT_FUNCTION;
|
|
|
|
|
n->func = $3;
|
|
|
|
|
n->actions = $4;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| ALTER PROCEDURE function_with_argtypes alterfunc_opt_list opt_restrict
|
2017-11-30 14:46:13 +01:00
|
|
|
{
|
|
|
|
|
AlterFunctionStmt *n = makeNode(AlterFunctionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->objtype = OBJECT_PROCEDURE;
|
|
|
|
|
n->func = $3;
|
|
|
|
|
n->actions = $4;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| ALTER ROUTINE function_with_argtypes alterfunc_opt_list opt_restrict
|
2017-11-30 14:46:13 +01:00
|
|
|
{
|
|
|
|
|
AlterFunctionStmt *n = makeNode(AlterFunctionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->objtype = OBJECT_ROUTINE;
|
2005-03-29 19:58:51 +02:00
|
|
|
n->func = $3;
|
2005-03-14 01:19:37 +01:00
|
|
|
n->actions = $4;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
alterfunc_opt_list:
|
|
|
|
|
/* At least one option must be specified */
|
|
|
|
|
common_func_opt_item { $$ = list_make1($1); }
|
|
|
|
|
| alterfunc_opt_list common_func_opt_item { $$ = lappend($1, $2); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/* Ignored, merely for SQL compliance */
|
|
|
|
|
opt_restrict:
|
|
|
|
|
RESTRICT
|
|
|
|
|
| /* EMPTY */
|
|
|
|
|
;
|
|
|
|
|
|
2002-05-17 20:32:52 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* QUERY:
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2002-07-01 17:27:56 +02:00
|
|
|
* DROP FUNCTION funcname (arg1, arg2, ...) [ RESTRICT | CASCADE ]
|
2017-11-30 14:46:13 +01:00
|
|
|
* DROP PROCEDURE procname (arg1, arg2, ...) [ RESTRICT | CASCADE ]
|
|
|
|
|
* DROP ROUTINE routname (arg1, arg2, ...) [ RESTRICT | CASCADE ]
|
2006-04-15 19:45:46 +02:00
|
|
|
* DROP AGGREGATE aggname (arg1, ...) [ RESTRICT | CASCADE ]
|
2002-07-01 17:27:56 +02:00
|
|
|
* DROP OPERATOR opname (leftoperand_typ, rightoperand_typ) [ RESTRICT | CASCADE ]
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
RemoveFuncStmt:
|
2016-12-28 18:00:00 +01:00
|
|
|
DROP FUNCTION function_with_argtypes_list opt_drop_behavior
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2011-11-18 03:31:29 +01:00
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-11-18 03:31:29 +01:00
|
|
|
n->removeType = OBJECT_FUNCTION;
|
2016-12-28 18:00:00 +01:00
|
|
|
n->objects = $3;
|
2016-09-15 19:00:00 +02:00
|
|
|
n->behavior = $4;
|
2006-06-16 22:23:45 +02:00
|
|
|
n->missing_ok = false;
|
2012-04-06 11:21:40 +02:00
|
|
|
n->concurrent = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2006-06-16 22:23:45 +02:00
|
|
|
}
|
2016-12-28 18:00:00 +01:00
|
|
|
| DROP FUNCTION IF_P EXISTS function_with_argtypes_list opt_drop_behavior
|
2006-06-16 22:23:45 +02:00
|
|
|
{
|
2011-11-18 03:31:29 +01:00
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-11-18 03:31:29 +01:00
|
|
|
n->removeType = OBJECT_FUNCTION;
|
2016-12-28 18:00:00 +01:00
|
|
|
n->objects = $5;
|
2016-09-15 19:00:00 +02:00
|
|
|
n->behavior = $6;
|
2006-06-16 22:23:45 +02:00
|
|
|
n->missing_ok = true;
|
2012-04-06 11:21:40 +02:00
|
|
|
n->concurrent = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-06-22 04:04:55 +02:00
|
|
|
}
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| DROP PROCEDURE function_with_argtypes_list opt_drop_behavior
|
2017-11-30 14:46:13 +01:00
|
|
|
{
|
|
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->removeType = OBJECT_PROCEDURE;
|
|
|
|
|
n->objects = $3;
|
|
|
|
|
n->behavior = $4;
|
|
|
|
|
n->missing_ok = false;
|
|
|
|
|
n->concurrent = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-11-30 14:46:13 +01:00
|
|
|
}
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| DROP PROCEDURE IF_P EXISTS function_with_argtypes_list opt_drop_behavior
|
2017-11-30 14:46:13 +01:00
|
|
|
{
|
|
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->removeType = OBJECT_PROCEDURE;
|
|
|
|
|
n->objects = $5;
|
|
|
|
|
n->behavior = $6;
|
|
|
|
|
n->missing_ok = true;
|
|
|
|
|
n->concurrent = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-11-30 14:46:13 +01:00
|
|
|
}
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| DROP ROUTINE function_with_argtypes_list opt_drop_behavior
|
2017-11-30 14:46:13 +01:00
|
|
|
{
|
|
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->removeType = OBJECT_ROUTINE;
|
|
|
|
|
n->objects = $3;
|
|
|
|
|
n->behavior = $4;
|
|
|
|
|
n->missing_ok = false;
|
|
|
|
|
n->concurrent = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-11-30 14:46:13 +01:00
|
|
|
}
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| DROP ROUTINE IF_P EXISTS function_with_argtypes_list opt_drop_behavior
|
2017-11-30 14:46:13 +01:00
|
|
|
{
|
|
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->removeType = OBJECT_ROUTINE;
|
|
|
|
|
n->objects = $5;
|
|
|
|
|
n->behavior = $6;
|
|
|
|
|
n->missing_ok = true;
|
|
|
|
|
n->concurrent = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-11-30 14:46:13 +01:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
RemoveAggrStmt:
|
2016-12-28 18:00:00 +01:00
|
|
|
DROP AGGREGATE aggregate_with_argtypes_list opt_drop_behavior
|
2001-10-03 22:54:22 +02:00
|
|
|
{
|
2011-11-18 03:31:29 +01:00
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-11-18 03:31:29 +01:00
|
|
|
n->removeType = OBJECT_AGGREGATE;
|
2016-12-28 18:00:00 +01:00
|
|
|
n->objects = $3;
|
2016-09-15 19:00:00 +02:00
|
|
|
n->behavior = $4;
|
2006-06-16 22:23:45 +02:00
|
|
|
n->missing_ok = false;
|
2012-04-06 11:21:40 +02:00
|
|
|
n->concurrent = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2006-06-16 22:23:45 +02:00
|
|
|
}
|
2016-12-28 18:00:00 +01:00
|
|
|
| DROP AGGREGATE IF_P EXISTS aggregate_with_argtypes_list opt_drop_behavior
|
2006-06-16 22:23:45 +02:00
|
|
|
{
|
2011-11-18 03:31:29 +01:00
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-11-18 03:31:29 +01:00
|
|
|
n->removeType = OBJECT_AGGREGATE;
|
2016-12-28 18:00:00 +01:00
|
|
|
n->objects = $5;
|
2016-09-15 19:00:00 +02:00
|
|
|
n->behavior = $6;
|
2006-06-16 22:23:45 +02:00
|
|
|
n->missing_ok = true;
|
2012-04-06 11:21:40 +02:00
|
|
|
n->concurrent = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
RemoveOperStmt:
|
2016-12-28 18:00:00 +01:00
|
|
|
DROP OPERATOR operator_with_argtypes_list opt_drop_behavior
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2011-11-18 03:31:29 +01:00
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-11-18 03:31:29 +01:00
|
|
|
n->removeType = OBJECT_OPERATOR;
|
2016-12-28 18:00:00 +01:00
|
|
|
n->objects = $3;
|
2016-12-28 18:00:00 +01:00
|
|
|
n->behavior = $4;
|
2006-06-16 22:23:45 +02:00
|
|
|
n->missing_ok = false;
|
2012-04-06 11:21:40 +02:00
|
|
|
n->concurrent = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2006-06-16 22:23:45 +02:00
|
|
|
}
|
2016-12-28 18:00:00 +01:00
|
|
|
| DROP OPERATOR IF_P EXISTS operator_with_argtypes_list opt_drop_behavior
|
2006-06-16 22:23:45 +02:00
|
|
|
{
|
2011-11-18 03:31:29 +01:00
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-11-18 03:31:29 +01:00
|
|
|
n->removeType = OBJECT_OPERATOR;
|
2016-12-28 18:00:00 +01:00
|
|
|
n->objects = $5;
|
2016-12-28 18:00:00 +01:00
|
|
|
n->behavior = $6;
|
2006-06-16 22:23:45 +02:00
|
|
|
n->missing_ok = true;
|
2012-04-06 11:21:40 +02:00
|
|
|
n->concurrent = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
|
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
oper_argtypes:
|
2008-09-01 22:42:46 +02:00
|
|
|
'(' Typename ')'
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2003-07-19 22:20:53 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
2003-09-16 00:28:58 +02:00
|
|
|
errmsg("missing argument"),
|
2008-09-01 22:42:46 +02:00
|
|
|
errhint("Use NONE to denote the missing argument of a unary operator."),
|
2009-07-13 04:02:20 +02:00
|
|
|
parser_errposition(@3)));
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2008-09-01 22:42:46 +02:00
|
|
|
| '(' Typename ',' Typename ')'
|
|
|
|
|
{ $$ = list_make2($2, $4); }
|
|
|
|
|
| '(' NONE ',' Typename ')' /* left unary */
|
|
|
|
|
{ $$ = list_make2(NULL, $4); }
|
|
|
|
|
| '(' Typename ',' NONE ')' /* right unary */
|
|
|
|
|
{ $$ = list_make2($2, NULL); }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
any_operator:
|
2002-06-18 19:56:41 +02:00
|
|
|
all_Op
|
2004-05-31 01:40:41 +02:00
|
|
|
{ $$ = list_make1(makeString($1)); }
|
2002-06-18 19:56:41 +02:00
|
|
|
| ColId '.' any_operator
|
|
|
|
|
{ $$ = lcons(makeString($1), $3); }
|
2002-04-17 01:08:12 +02:00
|
|
|
;
|
|
|
|
|
|
2016-12-28 18:00:00 +01:00
|
|
|
operator_with_argtypes_list:
|
|
|
|
|
operator_with_argtypes { $$ = list_make1($1); }
|
|
|
|
|
| operator_with_argtypes_list ',' operator_with_argtypes
|
|
|
|
|
{ $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
2016-12-28 18:00:00 +01:00
|
|
|
operator_with_argtypes:
|
|
|
|
|
any_operator oper_argtypes
|
|
|
|
|
{
|
|
|
|
|
ObjectWithArgs *n = makeNode(ObjectWithArgs);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2016-12-28 18:00:00 +01:00
|
|
|
n->objname = $1;
|
|
|
|
|
n->objargs = $2;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2009-09-23 01:43:43 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* DO <anonymous code block> [ LANGUAGE language ]
|
|
|
|
|
*
|
|
|
|
|
* We use a DefElem list for future extensibility, and to allow flexibility
|
|
|
|
|
* in the clause order.
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
DoStmt: DO dostmt_opt_list
|
|
|
|
|
{
|
|
|
|
|
DoStmt *n = makeNode(DoStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-09-23 01:43:43 +02:00
|
|
|
n->args = $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2009-09-23 01:43:43 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
dostmt_opt_list:
|
|
|
|
|
dostmt_opt_item { $$ = list_make1($1); }
|
|
|
|
|
| dostmt_opt_list dostmt_opt_item { $$ = lappend($1, $2); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
dostmt_opt_item:
|
|
|
|
|
Sconst
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("as", (Node *) makeString($1), @1);
|
2009-09-23 01:43:43 +02:00
|
|
|
}
|
2013-06-03 02:09:20 +02:00
|
|
|
| LANGUAGE NonReservedWord_or_Sconst
|
2009-09-23 01:43:43 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem("language", (Node *) makeString($2), @1);
|
2009-09-23 01:43:43 +02:00
|
|
|
}
|
|
|
|
|
;
|
1997-10-25 07:56:41 +02:00
|
|
|
|
2002-07-19 01:11:32 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* CREATE CAST / DROP CAST
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2003-02-05 21:16:42 +01:00
|
|
|
CreateCastStmt: CREATE CAST '(' Typename AS Typename ')'
|
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
2002-09-18 23:35:25 +02:00
|
|
|
WITH FUNCTION function_with_argtypes cast_context
|
2002-07-19 01:11:32 +02:00
|
|
|
{
|
|
|
|
|
CreateCastStmt *n = makeNode(CreateCastStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-07-19 01:11:32 +02:00
|
|
|
n->sourcetype = $4;
|
|
|
|
|
n->targettype = $6;
|
2005-03-29 19:58:51 +02:00
|
|
|
n->func = $10;
|
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
2002-09-18 23:35:25 +02:00
|
|
|
n->context = (CoercionContext) $11;
|
2008-10-31 09:39:22 +01:00
|
|
|
n->inout = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-07-19 01:11:32 +02:00
|
|
|
}
|
2003-02-05 21:16:42 +01:00
|
|
|
| CREATE CAST '(' Typename AS Typename ')'
|
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
2002-09-18 23:35:25 +02:00
|
|
|
WITHOUT FUNCTION cast_context
|
2002-07-19 01:11:32 +02:00
|
|
|
{
|
|
|
|
|
CreateCastStmt *n = makeNode(CreateCastStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-07-19 01:11:32 +02:00
|
|
|
n->sourcetype = $4;
|
|
|
|
|
n->targettype = $6;
|
|
|
|
|
n->func = NULL;
|
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
2002-09-18 23:35:25 +02:00
|
|
|
n->context = (CoercionContext) $10;
|
2008-10-31 09:39:22 +01:00
|
|
|
n->inout = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2008-10-31 09:39:22 +01:00
|
|
|
}
|
|
|
|
|
| CREATE CAST '(' Typename AS Typename ')'
|
|
|
|
|
WITH INOUT cast_context
|
|
|
|
|
{
|
|
|
|
|
CreateCastStmt *n = makeNode(CreateCastStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-10-31 09:39:22 +01:00
|
|
|
n->sourcetype = $4;
|
|
|
|
|
n->targettype = $6;
|
|
|
|
|
n->func = NULL;
|
|
|
|
|
n->context = (CoercionContext) $10;
|
|
|
|
|
n->inout = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-07-19 01:11:32 +02:00
|
|
|
}
|
2002-07-20 07:58:34 +02:00
|
|
|
;
|
2002-07-19 01:11:32 +02:00
|
|
|
|
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
2002-09-18 23:35:25 +02:00
|
|
|
cast_context: AS IMPLICIT_P { $$ = COERCION_IMPLICIT; }
|
|
|
|
|
| AS ASSIGNMENT { $$ = COERCION_ASSIGNMENT; }
|
|
|
|
|
| /*EMPTY*/ { $$ = COERCION_EXPLICIT; }
|
2002-07-19 01:11:32 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
2006-06-16 22:23:45 +02:00
|
|
|
DropCastStmt: DROP CAST opt_if_exists '(' Typename AS Typename ')' opt_drop_behavior
|
2002-07-19 01:11:32 +02:00
|
|
|
{
|
2011-11-18 03:31:29 +01:00
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-11-18 03:31:29 +01:00
|
|
|
n->removeType = OBJECT_CAST;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->objects = list_make1(list_make2($5, $7));
|
2006-06-16 22:23:45 +02:00
|
|
|
n->behavior = $9;
|
2006-06-17 01:50:48 +02:00
|
|
|
n->missing_ok = $3;
|
2012-04-06 11:21:40 +02:00
|
|
|
n->concurrent = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-07-19 01:11:32 +02:00
|
|
|
}
|
2002-07-20 07:58:34 +02:00
|
|
|
;
|
2002-07-19 01:11:32 +02:00
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
opt_if_exists: IF_P EXISTS { $$ = true; }
|
|
|
|
|
| /*EMPTY*/ { $$ = false; }
|
2006-06-17 01:50:48 +02:00
|
|
|
;
|
2002-07-19 01:11:32 +02:00
|
|
|
|
|
|
|
|
|
2015-04-26 16:33:14 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* CREATE TRANSFORM / DROP TRANSFORM
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
CreateTransformStmt: CREATE opt_or_replace TRANSFORM FOR Typename LANGUAGE name '(' transform_element_list ')'
|
|
|
|
|
{
|
|
|
|
|
CreateTransformStmt *n = makeNode(CreateTransformStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2015-04-26 16:33:14 +02:00
|
|
|
n->replace = $2;
|
|
|
|
|
n->type_name = $5;
|
|
|
|
|
n->lang = $7;
|
|
|
|
|
n->fromsql = linitial($9);
|
|
|
|
|
n->tosql = lsecond($9);
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2015-04-26 16:33:14 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
transform_element_list: FROM SQL_P WITH FUNCTION function_with_argtypes ',' TO SQL_P WITH FUNCTION function_with_argtypes
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make2($5, $11);
|
|
|
|
|
}
|
|
|
|
|
| TO SQL_P WITH FUNCTION function_with_argtypes ',' FROM SQL_P WITH FUNCTION function_with_argtypes
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make2($11, $5);
|
|
|
|
|
}
|
|
|
|
|
| FROM SQL_P WITH FUNCTION function_with_argtypes
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make2($5, NULL);
|
|
|
|
|
}
|
|
|
|
|
| TO SQL_P WITH FUNCTION function_with_argtypes
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make2(NULL, $5);
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
DropTransformStmt: DROP TRANSFORM opt_if_exists FOR Typename LANGUAGE name opt_drop_behavior
|
|
|
|
|
{
|
|
|
|
|
DropStmt *n = makeNode(DropStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2015-04-26 16:33:14 +02:00
|
|
|
n->removeType = OBJECT_TRANSFORM;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->objects = list_make1(list_make2($5, makeString($7)));
|
2015-04-26 16:33:14 +02:00
|
|
|
n->behavior = $8;
|
|
|
|
|
n->missing_ok = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2015-04-26 16:33:14 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
2000-02-18 10:30:20 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* QUERY:
|
|
|
|
|
*
|
Fix a few issues with REINDEX grammar
This addresses a couple of bugs in the REINDEX grammar, introduced by
83011ce:
- A name was never specified for DATABASE/SYSTEM, even if the query
included one. This caused such REINDEX queries to always work with any
object name, but we should complain if the object name specified does
not match the name of the database we are connected to. A test is added
for this case in the main regression test suite, provided by Álvaro.
- REINDEX SYSTEM CONCURRENTLY [name] was getting rejected in the
parser. Concurrent rebuilds are not supported for catalogs but the
error provided at execution time is more helpful for the user, and
allowing this flavor results in a simplification of the parsing logic.
- REINDEX DATABASE CONCURRENTLY was rebuilding the index in a
non-concurrent way, as the option was not being appended correctly in
the list of DefElems in ReindexStmt (REINDEX (CONCURRENTLY) DATABASE was
working fine. A test is added in the TAP tests of reindexdb for this
case, where we already have a REINDEX DATABASE CONCURRENTLY query
running on a small-ish instance. This relies on the work done in
2cbc3c1 for SYSTEM, but here we check if the OIDs of the index relations
match or not after the concurrent rebuild. Note that in order to get
this part to work, I had to tweak the tests so as the index OID and
names are saved separately. This change not affect the reliability or
of the coverage of the existing tests.
While on it, I have implemented a tweak in the grammar to reduce the
parsing by one branch, simplifying things even more.
Author: Michael Paquier, Álvaro Herrera
Discussion: https://postgr.es/m/YttqI6O64wDxGn0K@paquier.xyz
2022-07-26 03:16:26 +02:00
|
|
|
* REINDEX [ (options) ] {INDEX | TABLE | SCHEMA} [CONCURRENTLY] <name>
|
|
|
|
|
* REINDEX [ (options) ] {DATABASE | SYSTEM} [CONCURRENTLY] [<name>]
|
2000-02-18 10:30:20 +01:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
ReindexStmt:
|
Fix a few issues with REINDEX grammar
This addresses a couple of bugs in the REINDEX grammar, introduced by
83011ce:
- A name was never specified for DATABASE/SYSTEM, even if the query
included one. This caused such REINDEX queries to always work with any
object name, but we should complain if the object name specified does
not match the name of the database we are connected to. A test is added
for this case in the main regression test suite, provided by Álvaro.
- REINDEX SYSTEM CONCURRENTLY [name] was getting rejected in the
parser. Concurrent rebuilds are not supported for catalogs but the
error provided at execution time is more helpful for the user, and
allowing this flavor results in a simplification of the parsing logic.
- REINDEX DATABASE CONCURRENTLY was rebuilding the index in a
non-concurrent way, as the option was not being appended correctly in
the list of DefElems in ReindexStmt (REINDEX (CONCURRENTLY) DATABASE was
working fine. A test is added in the TAP tests of reindexdb for this
case, where we already have a REINDEX DATABASE CONCURRENTLY query
running on a small-ish instance. This relies on the work done in
2cbc3c1 for SYSTEM, but here we check if the OIDs of the index relations
match or not after the concurrent rebuild. Note that in order to get
this part to work, I had to tweak the tests so as the index OID and
names are saved separately. This change not affect the reliability or
of the coverage of the existing tests.
While on it, I have implemented a tweak in the grammar to reduce the
parsing by one branch, simplifying things even more.
Author: Michael Paquier, Álvaro Herrera
Discussion: https://postgr.es/m/YttqI6O64wDxGn0K@paquier.xyz
2022-07-26 03:16:26 +02:00
|
|
|
REINDEX opt_reindex_option_list reindex_target_relation opt_concurrently qualified_name
|
2000-02-18 10:30:20 +01:00
|
|
|
{
|
|
|
|
|
ReindexStmt *n = makeNode(ReindexStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2022-07-22 19:23:39 +02:00
|
|
|
n->kind = $3;
|
|
|
|
|
n->relation = $5;
|
2002-03-21 17:02:16 +01:00
|
|
|
n->name = NULL;
|
2022-07-22 19:23:39 +02:00
|
|
|
n->params = $2;
|
|
|
|
|
if ($4)
|
2020-12-03 02:13:21 +01:00
|
|
|
n->params = lappend(n->params,
|
2022-07-22 19:23:39 +02:00
|
|
|
makeDefElem("concurrently", NULL, @4));
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-06-22 23:14:31 +02:00
|
|
|
}
|
2022-07-22 19:23:39 +02:00
|
|
|
| REINDEX opt_reindex_option_list SCHEMA opt_concurrently name
|
2014-12-08 16:28:00 +01:00
|
|
|
{
|
|
|
|
|
ReindexStmt *n = makeNode(ReindexStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2022-07-22 19:23:39 +02:00
|
|
|
n->kind = REINDEX_OBJECT_SCHEMA;
|
2014-12-08 16:28:00 +01:00
|
|
|
n->relation = NULL;
|
Fix a few issues with REINDEX grammar
This addresses a couple of bugs in the REINDEX grammar, introduced by
83011ce:
- A name was never specified for DATABASE/SYSTEM, even if the query
included one. This caused such REINDEX queries to always work with any
object name, but we should complain if the object name specified does
not match the name of the database we are connected to. A test is added
for this case in the main regression test suite, provided by Álvaro.
- REINDEX SYSTEM CONCURRENTLY [name] was getting rejected in the
parser. Concurrent rebuilds are not supported for catalogs but the
error provided at execution time is more helpful for the user, and
allowing this flavor results in a simplification of the parsing logic.
- REINDEX DATABASE CONCURRENTLY was rebuilding the index in a
non-concurrent way, as the option was not being appended correctly in
the list of DefElems in ReindexStmt (REINDEX (CONCURRENTLY) DATABASE was
working fine. A test is added in the TAP tests of reindexdb for this
case, where we already have a REINDEX DATABASE CONCURRENTLY query
running on a small-ish instance. This relies on the work done in
2cbc3c1 for SYSTEM, but here we check if the OIDs of the index relations
match or not after the concurrent rebuild. Note that in order to get
this part to work, I had to tweak the tests so as the index OID and
names are saved separately. This change not affect the reliability or
of the coverage of the existing tests.
While on it, I have implemented a tweak in the grammar to reduce the
parsing by one branch, simplifying things even more.
Author: Michael Paquier, Álvaro Herrera
Discussion: https://postgr.es/m/YttqI6O64wDxGn0K@paquier.xyz
2022-07-26 03:16:26 +02:00
|
|
|
n->name = $5;
|
2022-07-22 19:23:39 +02:00
|
|
|
n->params = $2;
|
|
|
|
|
if ($4)
|
2020-12-03 02:13:21 +01:00
|
|
|
n->params = lappend(n->params,
|
2022-07-22 19:23:39 +02:00
|
|
|
makeDefElem("concurrently", NULL, @4));
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2014-12-08 16:28:00 +01:00
|
|
|
}
|
Fix a few issues with REINDEX grammar
This addresses a couple of bugs in the REINDEX grammar, introduced by
83011ce:
- A name was never specified for DATABASE/SYSTEM, even if the query
included one. This caused such REINDEX queries to always work with any
object name, but we should complain if the object name specified does
not match the name of the database we are connected to. A test is added
for this case in the main regression test suite, provided by Álvaro.
- REINDEX SYSTEM CONCURRENTLY [name] was getting rejected in the
parser. Concurrent rebuilds are not supported for catalogs but the
error provided at execution time is more helpful for the user, and
allowing this flavor results in a simplification of the parsing logic.
- REINDEX DATABASE CONCURRENTLY was rebuilding the index in a
non-concurrent way, as the option was not being appended correctly in
the list of DefElems in ReindexStmt (REINDEX (CONCURRENTLY) DATABASE was
working fine. A test is added in the TAP tests of reindexdb for this
case, where we already have a REINDEX DATABASE CONCURRENTLY query
running on a small-ish instance. This relies on the work done in
2cbc3c1 for SYSTEM, but here we check if the OIDs of the index relations
match or not after the concurrent rebuild. Note that in order to get
this part to work, I had to tweak the tests so as the index OID and
names are saved separately. This change not affect the reliability or
of the coverage of the existing tests.
While on it, I have implemented a tweak in the grammar to reduce the
parsing by one branch, simplifying things even more.
Author: Michael Paquier, Álvaro Herrera
Discussion: https://postgr.es/m/YttqI6O64wDxGn0K@paquier.xyz
2022-07-26 03:16:26 +02:00
|
|
|
| REINDEX opt_reindex_option_list reindex_target_all opt_concurrently opt_single_name
|
2002-03-21 17:02:16 +01:00
|
|
|
{
|
|
|
|
|
ReindexStmt *n = makeNode(ReindexStmt);
|
Fix a few issues with REINDEX grammar
This addresses a couple of bugs in the REINDEX grammar, introduced by
83011ce:
- A name was never specified for DATABASE/SYSTEM, even if the query
included one. This caused such REINDEX queries to always work with any
object name, but we should complain if the object name specified does
not match the name of the database we are connected to. A test is added
for this case in the main regression test suite, provided by Álvaro.
- REINDEX SYSTEM CONCURRENTLY [name] was getting rejected in the
parser. Concurrent rebuilds are not supported for catalogs but the
error provided at execution time is more helpful for the user, and
allowing this flavor results in a simplification of the parsing logic.
- REINDEX DATABASE CONCURRENTLY was rebuilding the index in a
non-concurrent way, as the option was not being appended correctly in
the list of DefElems in ReindexStmt (REINDEX (CONCURRENTLY) DATABASE was
working fine. A test is added in the TAP tests of reindexdb for this
case, where we already have a REINDEX DATABASE CONCURRENTLY query
running on a small-ish instance. This relies on the work done in
2cbc3c1 for SYSTEM, but here we check if the OIDs of the index relations
match or not after the concurrent rebuild. Note that in order to get
this part to work, I had to tweak the tests so as the index OID and
names are saved separately. This change not affect the reliability or
of the coverage of the existing tests.
While on it, I have implemented a tweak in the grammar to reduce the
parsing by one branch, simplifying things even more.
Author: Michael Paquier, Álvaro Herrera
Discussion: https://postgr.es/m/YttqI6O64wDxGn0K@paquier.xyz
2022-07-26 03:16:26 +02:00
|
|
|
|
|
|
|
|
n->kind = $3;
|
2002-03-21 17:02:16 +01:00
|
|
|
n->relation = NULL;
|
Fix a few issues with REINDEX grammar
This addresses a couple of bugs in the REINDEX grammar, introduced by
83011ce:
- A name was never specified for DATABASE/SYSTEM, even if the query
included one. This caused such REINDEX queries to always work with any
object name, but we should complain if the object name specified does
not match the name of the database we are connected to. A test is added
for this case in the main regression test suite, provided by Álvaro.
- REINDEX SYSTEM CONCURRENTLY [name] was getting rejected in the
parser. Concurrent rebuilds are not supported for catalogs but the
error provided at execution time is more helpful for the user, and
allowing this flavor results in a simplification of the parsing logic.
- REINDEX DATABASE CONCURRENTLY was rebuilding the index in a
non-concurrent way, as the option was not being appended correctly in
the list of DefElems in ReindexStmt (REINDEX (CONCURRENTLY) DATABASE was
working fine. A test is added in the TAP tests of reindexdb for this
case, where we already have a REINDEX DATABASE CONCURRENTLY query
running on a small-ish instance. This relies on the work done in
2cbc3c1 for SYSTEM, but here we check if the OIDs of the index relations
match or not after the concurrent rebuild. Note that in order to get
this part to work, I had to tweak the tests so as the index OID and
names are saved separately. This change not affect the reliability or
of the coverage of the existing tests.
While on it, I have implemented a tweak in the grammar to reduce the
parsing by one branch, simplifying things even more.
Author: Michael Paquier, Álvaro Herrera
Discussion: https://postgr.es/m/YttqI6O64wDxGn0K@paquier.xyz
2022-07-26 03:16:26 +02:00
|
|
|
n->name = $5;
|
2022-07-22 19:23:39 +02:00
|
|
|
n->params = $2;
|
Fix a few issues with REINDEX grammar
This addresses a couple of bugs in the REINDEX grammar, introduced by
83011ce:
- A name was never specified for DATABASE/SYSTEM, even if the query
included one. This caused such REINDEX queries to always work with any
object name, but we should complain if the object name specified does
not match the name of the database we are connected to. A test is added
for this case in the main regression test suite, provided by Álvaro.
- REINDEX SYSTEM CONCURRENTLY [name] was getting rejected in the
parser. Concurrent rebuilds are not supported for catalogs but the
error provided at execution time is more helpful for the user, and
allowing this flavor results in a simplification of the parsing logic.
- REINDEX DATABASE CONCURRENTLY was rebuilding the index in a
non-concurrent way, as the option was not being appended correctly in
the list of DefElems in ReindexStmt (REINDEX (CONCURRENTLY) DATABASE was
working fine. A test is added in the TAP tests of reindexdb for this
case, where we already have a REINDEX DATABASE CONCURRENTLY query
running on a small-ish instance. This relies on the work done in
2cbc3c1 for SYSTEM, but here we check if the OIDs of the index relations
match or not after the concurrent rebuild. Note that in order to get
this part to work, I had to tweak the tests so as the index OID and
names are saved separately. This change not affect the reliability or
of the coverage of the existing tests.
While on it, I have implemented a tweak in the grammar to reduce the
parsing by one branch, simplifying things even more.
Author: Michael Paquier, Álvaro Herrera
Discussion: https://postgr.es/m/YttqI6O64wDxGn0K@paquier.xyz
2022-07-26 03:16:26 +02:00
|
|
|
if ($4)
|
|
|
|
|
n->params = lappend(n->params,
|
|
|
|
|
makeDefElem("concurrently", NULL, @4));
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-02-18 10:30:20 +01:00
|
|
|
}
|
|
|
|
|
;
|
Fix a few issues with REINDEX grammar
This addresses a couple of bugs in the REINDEX grammar, introduced by
83011ce:
- A name was never specified for DATABASE/SYSTEM, even if the query
included one. This caused such REINDEX queries to always work with any
object name, but we should complain if the object name specified does
not match the name of the database we are connected to. A test is added
for this case in the main regression test suite, provided by Álvaro.
- REINDEX SYSTEM CONCURRENTLY [name] was getting rejected in the
parser. Concurrent rebuilds are not supported for catalogs but the
error provided at execution time is more helpful for the user, and
allowing this flavor results in a simplification of the parsing logic.
- REINDEX DATABASE CONCURRENTLY was rebuilding the index in a
non-concurrent way, as the option was not being appended correctly in
the list of DefElems in ReindexStmt (REINDEX (CONCURRENTLY) DATABASE was
working fine. A test is added in the TAP tests of reindexdb for this
case, where we already have a REINDEX DATABASE CONCURRENTLY query
running on a small-ish instance. This relies on the work done in
2cbc3c1 for SYSTEM, but here we check if the OIDs of the index relations
match or not after the concurrent rebuild. Note that in order to get
this part to work, I had to tweak the tests so as the index OID and
names are saved separately. This change not affect the reliability or
of the coverage of the existing tests.
While on it, I have implemented a tweak in the grammar to reduce the
parsing by one branch, simplifying things even more.
Author: Michael Paquier, Álvaro Herrera
Discussion: https://postgr.es/m/YttqI6O64wDxGn0K@paquier.xyz
2022-07-26 03:16:26 +02:00
|
|
|
reindex_target_relation:
|
2015-05-15 13:09:57 +02:00
|
|
|
INDEX { $$ = REINDEX_OBJECT_INDEX; }
|
|
|
|
|
| TABLE { $$ = REINDEX_OBJECT_TABLE; }
|
|
|
|
|
;
|
Fix a few issues with REINDEX grammar
This addresses a couple of bugs in the REINDEX grammar, introduced by
83011ce:
- A name was never specified for DATABASE/SYSTEM, even if the query
included one. This caused such REINDEX queries to always work with any
object name, but we should complain if the object name specified does
not match the name of the database we are connected to. A test is added
for this case in the main regression test suite, provided by Álvaro.
- REINDEX SYSTEM CONCURRENTLY [name] was getting rejected in the
parser. Concurrent rebuilds are not supported for catalogs but the
error provided at execution time is more helpful for the user, and
allowing this flavor results in a simplification of the parsing logic.
- REINDEX DATABASE CONCURRENTLY was rebuilding the index in a
non-concurrent way, as the option was not being appended correctly in
the list of DefElems in ReindexStmt (REINDEX (CONCURRENTLY) DATABASE was
working fine. A test is added in the TAP tests of reindexdb for this
case, where we already have a REINDEX DATABASE CONCURRENTLY query
running on a small-ish instance. This relies on the work done in
2cbc3c1 for SYSTEM, but here we check if the OIDs of the index relations
match or not after the concurrent rebuild. Note that in order to get
this part to work, I had to tweak the tests so as the index OID and
names are saved separately. This change not affect the reliability or
of the coverage of the existing tests.
While on it, I have implemented a tweak in the grammar to reduce the
parsing by one branch, simplifying things even more.
Author: Michael Paquier, Álvaro Herrera
Discussion: https://postgr.es/m/YttqI6O64wDxGn0K@paquier.xyz
2022-07-26 03:16:26 +02:00
|
|
|
reindex_target_all:
|
|
|
|
|
SYSTEM_P { $$ = REINDEX_OBJECT_SYSTEM; }
|
|
|
|
|
| DATABASE { $$ = REINDEX_OBJECT_DATABASE; }
|
|
|
|
|
;
|
2022-07-22 19:23:39 +02:00
|
|
|
opt_reindex_option_list:
|
|
|
|
|
'(' utility_option_list ')' { $$ = $2; }
|
|
|
|
|
| /* EMPTY */ { $$ = NULL; }
|
2015-05-15 13:09:57 +02:00
|
|
|
;
|
2000-02-18 10:30:20 +01:00
|
|
|
|
2014-04-13 07:02:44 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* ALTER TABLESPACE
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2014-08-22 01:06:17 +02:00
|
|
|
AlterTblSpcStmt:
|
|
|
|
|
ALTER TABLESPACE name SET reloptions
|
2014-04-13 07:02:44 +02:00
|
|
|
{
|
|
|
|
|
AlterTableSpaceOptionsStmt *n =
|
|
|
|
|
makeNode(AlterTableSpaceOptionsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-04-13 07:02:44 +02:00
|
|
|
n->tablespacename = $3;
|
|
|
|
|
n->options = $5;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->isReset = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2014-04-13 07:02:44 +02:00
|
|
|
}
|
|
|
|
|
| ALTER TABLESPACE name RESET reloptions
|
|
|
|
|
{
|
|
|
|
|
AlterTableSpaceOptionsStmt *n =
|
|
|
|
|
makeNode(AlterTableSpaceOptionsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-04-13 07:02:44 +02:00
|
|
|
n->tablespacename = $3;
|
|
|
|
|
n->options = $5;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->isReset = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2014-04-13 07:02:44 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2003-06-27 16:45:32 +02:00
|
|
|
* ALTER THING name RENAME TO newname
|
1997-09-01 08:00:35 +02:00
|
|
|
*
|
1996-07-09 08:22:35 +02:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2016-09-15 19:00:00 +02:00
|
|
|
RenameStmt: ALTER AGGREGATE aggregate_with_argtypes RENAME TO name
|
2003-06-27 16:45:32 +02:00
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-06-27 16:45:32 +02:00
|
|
|
n->renameType = OBJECT_AGGREGATE;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2016-09-15 19:00:00 +02:00
|
|
|
n->newname = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2003-06-27 16:45:32 +02:00
|
|
|
}
|
2011-02-12 14:54:13 +01:00
|
|
|
| ALTER COLLATION any_name RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-02-12 14:54:13 +01:00
|
|
|
n->renameType = OBJECT_COLLATION;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2011-02-12 14:54:13 +01:00
|
|
|
n->newname = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-02-12 14:54:13 +01:00
|
|
|
}
|
2003-06-27 16:45:32 +02:00
|
|
|
| ALTER CONVERSION_P any_name RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-06-27 16:45:32 +02:00
|
|
|
n->renameType = OBJECT_CONVERSION;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2003-06-27 16:45:32 +02:00
|
|
|
n->newname = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2003-06-27 16:45:32 +02:00
|
|
|
}
|
2020-06-10 22:58:46 +02:00
|
|
|
| ALTER DATABASE name RENAME TO name
|
2003-06-27 16:45:32 +02:00
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-06-27 16:45:32 +02:00
|
|
|
n->renameType = OBJECT_DATABASE;
|
|
|
|
|
n->subname = $3;
|
|
|
|
|
n->newname = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2003-06-27 16:45:32 +02:00
|
|
|
}
|
2011-12-22 21:43:56 +01:00
|
|
|
| ALTER DOMAIN_P any_name RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-12-22 21:43:56 +01:00
|
|
|
n->renameType = OBJECT_DOMAIN;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2011-12-22 21:43:56 +01:00
|
|
|
n->newname = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-12-22 21:43:56 +01:00
|
|
|
}
|
2012-04-03 07:11:51 +02:00
|
|
|
| ALTER DOMAIN_P any_name RENAME CONSTRAINT name TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-12-23 13:06:44 +01:00
|
|
|
n->renameType = OBJECT_DOMCONSTRAINT;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2012-04-03 07:11:51 +02:00
|
|
|
n->subname = $6;
|
|
|
|
|
n->newname = $8;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-04-03 07:11:51 +02:00
|
|
|
}
|
2011-12-09 19:42:30 +01:00
|
|
|
| ALTER FOREIGN DATA_P WRAPPER name RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-12-09 19:42:30 +01:00
|
|
|
n->renameType = OBJECT_FDW;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) makeString($5);
|
2011-12-09 19:42:30 +01:00
|
|
|
n->newname = $8;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-12-09 19:42:30 +01:00
|
|
|
}
|
2007-09-03 02:39:26 +02:00
|
|
|
| ALTER FUNCTION function_with_argtypes RENAME TO name
|
2003-06-27 16:45:32 +02:00
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-06-27 16:45:32 +02:00
|
|
|
n->renameType = OBJECT_FUNCTION;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2007-09-03 02:39:26 +02:00
|
|
|
n->newname = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2003-06-27 16:45:32 +02:00
|
|
|
}
|
2005-06-28 07:09:14 +02:00
|
|
|
| ALTER GROUP_P RoleId RENAME TO RoleId
|
2003-06-27 16:45:32 +02:00
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-06-28 07:09:14 +02:00
|
|
|
n->renameType = OBJECT_ROLE;
|
2003-06-27 16:45:32 +02:00
|
|
|
n->subname = $3;
|
|
|
|
|
n->newname = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2003-06-27 16:45:32 +02:00
|
|
|
}
|
2007-03-26 18:58:41 +02:00
|
|
|
| ALTER opt_procedural LANGUAGE name RENAME TO name
|
2003-06-27 16:45:32 +02:00
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-06-27 16:45:32 +02:00
|
|
|
n->renameType = OBJECT_LANGUAGE;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) makeString($4);
|
2007-03-26 18:58:41 +02:00
|
|
|
n->newname = $7;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2003-06-27 16:45:32 +02:00
|
|
|
}
|
2020-06-10 22:58:46 +02:00
|
|
|
| ALTER OPERATOR CLASS any_name USING name RENAME TO name
|
2003-06-27 16:45:32 +02:00
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-06-27 16:45:32 +02:00
|
|
|
n->renameType = OBJECT_OPCLASS;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) lcons(makeString($6), $4);
|
2003-06-27 16:45:32 +02:00
|
|
|
n->newname = $9;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2003-06-27 16:45:32 +02:00
|
|
|
}
|
2020-06-10 22:58:46 +02:00
|
|
|
| ALTER OPERATOR FAMILY any_name USING name RENAME TO name
|
2007-01-23 06:07:18 +01:00
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-01-23 06:07:18 +01:00
|
|
|
n->renameType = OBJECT_OPFAMILY;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) lcons(makeString($6), $4);
|
2007-01-23 06:07:18 +01:00
|
|
|
n->newname = $9;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-01-23 06:07:18 +01:00
|
|
|
}
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
| ALTER POLICY name ON qualified_name RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
n->renameType = OBJECT_POLICY;
|
|
|
|
|
n->relation = $5;
|
|
|
|
|
n->subname = $3;
|
|
|
|
|
n->newname = $8;
|
|
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
}
|
|
|
|
|
| ALTER POLICY IF_P EXISTS name ON qualified_name RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
n->renameType = OBJECT_POLICY;
|
|
|
|
|
n->relation = $7;
|
|
|
|
|
n->subname = $5;
|
|
|
|
|
n->newname = $10;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
}
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| ALTER PROCEDURE function_with_argtypes RENAME TO name
|
2017-11-30 14:46:13 +01:00
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->renameType = OBJECT_PROCEDURE;
|
|
|
|
|
n->object = (Node *) $3;
|
|
|
|
|
n->newname = $6;
|
|
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-11-30 14:46:13 +01:00
|
|
|
}
|
2017-03-03 16:47:04 +01:00
|
|
|
| ALTER PUBLICATION name RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-03-03 16:47:04 +01:00
|
|
|
n->renameType = OBJECT_PUBLICATION;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) makeString($3);
|
2017-03-03 16:47:04 +01:00
|
|
|
n->newname = $6;
|
|
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-03-03 16:47:04 +01:00
|
|
|
}
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| ALTER ROUTINE function_with_argtypes RENAME TO name
|
2017-11-30 14:46:13 +01:00
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->renameType = OBJECT_ROUTINE;
|
|
|
|
|
n->object = (Node *) $3;
|
|
|
|
|
n->newname = $6;
|
|
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-11-30 14:46:13 +01:00
|
|
|
}
|
2003-06-27 16:45:32 +02:00
|
|
|
| ALTER SCHEMA name RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-06-27 16:45:32 +02:00
|
|
|
n->renameType = OBJECT_SCHEMA;
|
|
|
|
|
n->subname = $3;
|
|
|
|
|
n->newname = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2003-06-27 16:45:32 +02:00
|
|
|
}
|
2011-12-09 19:42:30 +01:00
|
|
|
| ALTER SERVER name RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-12-09 19:42:30 +01:00
|
|
|
n->renameType = OBJECT_FOREIGN_SERVER;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) makeString($3);
|
2011-12-09 19:42:30 +01:00
|
|
|
n->newname = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-12-09 19:42:30 +01:00
|
|
|
}
|
2017-03-03 16:47:04 +01:00
|
|
|
| ALTER SUBSCRIPTION name RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-03-03 16:47:04 +01:00
|
|
|
n->renameType = OBJECT_SUBSCRIPTION;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) makeString($3);
|
2017-03-03 16:47:04 +01:00
|
|
|
n->newname = $6;
|
|
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-03-03 16:47:04 +01:00
|
|
|
}
|
2004-05-05 06:48:48 +02:00
|
|
|
| ALTER TABLE relation_expr RENAME TO name
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-05-05 06:48:48 +02:00
|
|
|
n->renameType = OBJECT_TABLE;
|
|
|
|
|
n->relation = $3;
|
|
|
|
|
n->subname = NULL;
|
|
|
|
|
n->newname = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-01-24 00:25:04 +01:00
|
|
|
}
|
|
|
|
|
| ALTER TABLE IF_P EXISTS relation_expr RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-01-24 00:25:04 +01:00
|
|
|
n->renameType = OBJECT_TABLE;
|
|
|
|
|
n->relation = $5;
|
|
|
|
|
n->subname = NULL;
|
|
|
|
|
n->newname = $8;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-08-20 06:29:33 +02:00
|
|
|
}
|
2009-01-12 10:38:30 +01:00
|
|
|
| ALTER SEQUENCE qualified_name RENAME TO name
|
2007-07-03 03:30:37 +02:00
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-07-03 03:30:37 +02:00
|
|
|
n->renameType = OBJECT_SEQUENCE;
|
|
|
|
|
n->relation = $3;
|
|
|
|
|
n->subname = NULL;
|
|
|
|
|
n->newname = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-01-24 00:25:04 +01:00
|
|
|
}
|
|
|
|
|
| ALTER SEQUENCE IF_P EXISTS qualified_name RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-01-24 00:25:04 +01:00
|
|
|
n->renameType = OBJECT_SEQUENCE;
|
|
|
|
|
n->relation = $5;
|
|
|
|
|
n->subname = NULL;
|
|
|
|
|
n->newname = $8;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-07-03 03:30:37 +02:00
|
|
|
}
|
2009-01-12 10:38:30 +01:00
|
|
|
| ALTER VIEW qualified_name RENAME TO name
|
2007-07-03 03:30:37 +02:00
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-07-03 03:30:37 +02:00
|
|
|
n->renameType = OBJECT_VIEW;
|
|
|
|
|
n->relation = $3;
|
|
|
|
|
n->subname = NULL;
|
|
|
|
|
n->newname = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-01-24 00:25:04 +01:00
|
|
|
}
|
|
|
|
|
| ALTER VIEW IF_P EXISTS qualified_name RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-01-24 00:25:04 +01:00
|
|
|
n->renameType = OBJECT_VIEW;
|
|
|
|
|
n->relation = $5;
|
|
|
|
|
n->subname = NULL;
|
|
|
|
|
n->newname = $8;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-07-03 03:30:37 +02:00
|
|
|
}
|
2013-03-04 01:23:31 +01:00
|
|
|
| ALTER MATERIALIZED VIEW qualified_name RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2013-03-04 01:23:31 +01:00
|
|
|
n->renameType = OBJECT_MATVIEW;
|
|
|
|
|
n->relation = $4;
|
|
|
|
|
n->subname = NULL;
|
|
|
|
|
n->newname = $7;
|
|
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2013-03-04 01:23:31 +01:00
|
|
|
}
|
|
|
|
|
| ALTER MATERIALIZED VIEW IF_P EXISTS qualified_name RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2013-03-04 01:23:31 +01:00
|
|
|
n->renameType = OBJECT_MATVIEW;
|
|
|
|
|
n->relation = $6;
|
|
|
|
|
n->subname = NULL;
|
|
|
|
|
n->newname = $9;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2013-03-04 01:23:31 +01:00
|
|
|
}
|
2009-01-12 10:38:30 +01:00
|
|
|
| ALTER INDEX qualified_name RENAME TO name
|
2004-08-20 06:29:33 +02:00
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-08-20 06:29:33 +02:00
|
|
|
n->renameType = OBJECT_INDEX;
|
|
|
|
|
n->relation = $3;
|
|
|
|
|
n->subname = NULL;
|
|
|
|
|
n->newname = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-01-24 00:25:04 +01:00
|
|
|
}
|
|
|
|
|
| ALTER INDEX IF_P EXISTS qualified_name RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-01-24 00:25:04 +01:00
|
|
|
n->renameType = OBJECT_INDEX;
|
|
|
|
|
n->relation = $5;
|
|
|
|
|
n->subname = NULL;
|
|
|
|
|
n->newname = $8;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-05-05 06:48:48 +02:00
|
|
|
}
|
2011-01-02 05:48:11 +01:00
|
|
|
| ALTER FOREIGN TABLE relation_expr RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-01-02 05:48:11 +01:00
|
|
|
n->renameType = OBJECT_FOREIGN_TABLE;
|
|
|
|
|
n->relation = $4;
|
|
|
|
|
n->subname = NULL;
|
|
|
|
|
n->newname = $7;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-01-24 00:25:04 +01:00
|
|
|
}
|
|
|
|
|
| ALTER FOREIGN TABLE IF_P EXISTS relation_expr RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-01-24 00:25:04 +01:00
|
|
|
n->renameType = OBJECT_FOREIGN_TABLE;
|
|
|
|
|
n->relation = $6;
|
|
|
|
|
n->subname = NULL;
|
|
|
|
|
n->newname = $9;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-01-02 05:48:11 +01:00
|
|
|
}
|
2004-05-05 06:48:48 +02:00
|
|
|
| ALTER TABLE relation_expr RENAME opt_column name TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-05-05 06:48:48 +02:00
|
|
|
n->renameType = OBJECT_COLUMN;
|
2011-01-02 05:48:11 +01:00
|
|
|
n->relationType = OBJECT_TABLE;
|
2002-03-21 17:02:16 +01:00
|
|
|
n->relation = $3;
|
2003-06-27 16:45:32 +02:00
|
|
|
n->subname = $6;
|
2001-05-07 02:43:27 +02:00
|
|
|
n->newname = $8;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-01-24 00:25:04 +01:00
|
|
|
}
|
|
|
|
|
| ALTER TABLE IF_P EXISTS relation_expr RENAME opt_column name TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-01-24 00:25:04 +01:00
|
|
|
n->renameType = OBJECT_COLUMN;
|
|
|
|
|
n->relationType = OBJECT_TABLE;
|
|
|
|
|
n->relation = $5;
|
|
|
|
|
n->subname = $8;
|
|
|
|
|
n->newname = $10;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-04-24 04:48:55 +02:00
|
|
|
}
|
2019-11-21 11:55:13 +01:00
|
|
|
| ALTER VIEW qualified_name RENAME opt_column name TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2019-11-21 11:55:13 +01:00
|
|
|
n->renameType = OBJECT_COLUMN;
|
|
|
|
|
n->relationType = OBJECT_VIEW;
|
|
|
|
|
n->relation = $3;
|
|
|
|
|
n->subname = $6;
|
|
|
|
|
n->newname = $8;
|
|
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2019-11-21 11:55:13 +01:00
|
|
|
}
|
|
|
|
|
| ALTER VIEW IF_P EXISTS qualified_name RENAME opt_column name TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2019-11-21 11:55:13 +01:00
|
|
|
n->renameType = OBJECT_COLUMN;
|
|
|
|
|
n->relationType = OBJECT_VIEW;
|
|
|
|
|
n->relation = $5;
|
|
|
|
|
n->subname = $8;
|
|
|
|
|
n->newname = $10;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2019-11-21 11:55:13 +01:00
|
|
|
}
|
2013-03-04 01:23:31 +01:00
|
|
|
| ALTER MATERIALIZED VIEW qualified_name RENAME opt_column name TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2013-03-04 01:23:31 +01:00
|
|
|
n->renameType = OBJECT_COLUMN;
|
|
|
|
|
n->relationType = OBJECT_MATVIEW;
|
|
|
|
|
n->relation = $4;
|
|
|
|
|
n->subname = $7;
|
|
|
|
|
n->newname = $9;
|
|
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2013-03-04 01:23:31 +01:00
|
|
|
}
|
|
|
|
|
| ALTER MATERIALIZED VIEW IF_P EXISTS qualified_name RENAME opt_column name TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2013-03-04 01:23:31 +01:00
|
|
|
n->renameType = OBJECT_COLUMN;
|
|
|
|
|
n->relationType = OBJECT_MATVIEW;
|
|
|
|
|
n->relation = $6;
|
|
|
|
|
n->subname = $9;
|
|
|
|
|
n->newname = $11;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2013-03-04 01:23:31 +01:00
|
|
|
}
|
2012-03-10 19:19:13 +01:00
|
|
|
| ALTER TABLE relation_expr RENAME CONSTRAINT name TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-12-23 13:06:44 +01:00
|
|
|
n->renameType = OBJECT_TABCONSTRAINT;
|
2012-03-10 19:19:13 +01:00
|
|
|
n->relation = $3;
|
|
|
|
|
n->subname = $6;
|
|
|
|
|
n->newname = $8;
|
2015-03-25 00:52:47 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2015-03-25 00:52:47 +01:00
|
|
|
}
|
|
|
|
|
| ALTER TABLE IF_P EXISTS relation_expr RENAME CONSTRAINT name TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2015-03-25 00:52:47 +01:00
|
|
|
n->renameType = OBJECT_TABCONSTRAINT;
|
|
|
|
|
n->relation = $5;
|
|
|
|
|
n->subname = $8;
|
|
|
|
|
n->newname = $10;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-03-10 19:19:13 +01:00
|
|
|
}
|
2011-01-02 05:48:11 +01:00
|
|
|
| ALTER FOREIGN TABLE relation_expr RENAME opt_column name TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-01-02 05:48:11 +01:00
|
|
|
n->renameType = OBJECT_COLUMN;
|
|
|
|
|
n->relationType = OBJECT_FOREIGN_TABLE;
|
|
|
|
|
n->relation = $4;
|
|
|
|
|
n->subname = $7;
|
|
|
|
|
n->newname = $9;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-01-24 00:25:04 +01:00
|
|
|
}
|
|
|
|
|
| ALTER FOREIGN TABLE IF_P EXISTS relation_expr RENAME opt_column name TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-01-24 00:25:04 +01:00
|
|
|
n->renameType = OBJECT_COLUMN;
|
|
|
|
|
n->relationType = OBJECT_FOREIGN_TABLE;
|
|
|
|
|
n->relation = $6;
|
|
|
|
|
n->subname = $9;
|
|
|
|
|
n->newname = $11;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-01-02 05:48:11 +01:00
|
|
|
}
|
2013-02-09 05:58:40 +01:00
|
|
|
| ALTER RULE name ON qualified_name RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2013-02-09 05:58:40 +01:00
|
|
|
n->renameType = OBJECT_RULE;
|
|
|
|
|
n->relation = $5;
|
|
|
|
|
n->subname = $3;
|
|
|
|
|
n->newname = $8;
|
|
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2013-02-09 05:58:40 +01:00
|
|
|
}
|
2009-01-12 10:38:30 +01:00
|
|
|
| ALTER TRIGGER name ON qualified_name RENAME TO name
|
2002-04-24 04:48:55 +02:00
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-08-01 06:03:59 +02:00
|
|
|
n->renameType = OBJECT_TRIGGER;
|
2002-04-24 04:48:55 +02:00
|
|
|
n->relation = $5;
|
2003-06-27 16:45:32 +02:00
|
|
|
n->subname = $3;
|
2002-04-24 04:48:55 +02:00
|
|
|
n->newname = $8;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2003-06-27 16:45:32 +02:00
|
|
|
}
|
2012-07-18 16:16:16 +02:00
|
|
|
| ALTER EVENT TRIGGER name RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-07-18 16:16:16 +02:00
|
|
|
n->renameType = OBJECT_EVENT_TRIGGER;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) makeString($4);
|
2012-07-18 16:16:16 +02:00
|
|
|
n->newname = $7;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-07-18 16:16:16 +02:00
|
|
|
}
|
2005-06-28 07:09:14 +02:00
|
|
|
| ALTER ROLE RoleId RENAME TO RoleId
|
2003-06-27 16:45:32 +02:00
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-06-28 07:09:14 +02:00
|
|
|
n->renameType = OBJECT_ROLE;
|
|
|
|
|
n->subname = $3;
|
|
|
|
|
n->newname = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-06-28 07:09:14 +02:00
|
|
|
}
|
|
|
|
|
| ALTER USER RoleId RENAME TO RoleId
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-06-28 07:09:14 +02:00
|
|
|
n->renameType = OBJECT_ROLE;
|
2003-06-27 16:45:32 +02:00
|
|
|
n->subname = $3;
|
|
|
|
|
n->newname = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2004-06-25 23:55:59 +02:00
|
|
|
| ALTER TABLESPACE name RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-06-25 23:55:59 +02:00
|
|
|
n->renameType = OBJECT_TABLESPACE;
|
|
|
|
|
n->subname = $3;
|
|
|
|
|
n->newname = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-06-25 23:55:59 +02:00
|
|
|
}
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
| ALTER STATISTICS any_name RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
n->renameType = OBJECT_STATISTIC_EXT;
|
|
|
|
|
n->object = (Node *) $3;
|
|
|
|
|
n->newname = $6;
|
|
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
}
|
2007-08-21 17:13:42 +02:00
|
|
|
| ALTER TEXT_P SEARCH PARSER any_name RENAME TO name
|
2007-08-21 03:11:32 +02:00
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-08-21 03:11:32 +02:00
|
|
|
n->renameType = OBJECT_TSPARSER;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $5;
|
2007-08-21 03:11:32 +02:00
|
|
|
n->newname = $8;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-08-21 03:11:32 +02:00
|
|
|
}
|
2007-08-21 17:13:42 +02:00
|
|
|
| ALTER TEXT_P SEARCH DICTIONARY any_name RENAME TO name
|
2007-08-21 03:11:32 +02:00
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-08-21 03:11:32 +02:00
|
|
|
n->renameType = OBJECT_TSDICTIONARY;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $5;
|
2007-08-21 03:11:32 +02:00
|
|
|
n->newname = $8;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-08-21 03:11:32 +02:00
|
|
|
}
|
2007-08-21 17:13:42 +02:00
|
|
|
| ALTER TEXT_P SEARCH TEMPLATE any_name RENAME TO name
|
2007-08-21 03:11:32 +02:00
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-08-21 03:11:32 +02:00
|
|
|
n->renameType = OBJECT_TSTEMPLATE;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $5;
|
2007-08-21 03:11:32 +02:00
|
|
|
n->newname = $8;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-08-21 03:11:32 +02:00
|
|
|
}
|
2007-08-21 17:13:42 +02:00
|
|
|
| ALTER TEXT_P SEARCH CONFIGURATION any_name RENAME TO name
|
2007-08-21 03:11:32 +02:00
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-08-21 03:11:32 +02:00
|
|
|
n->renameType = OBJECT_TSCONFIGURATION;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $5;
|
2007-08-21 03:11:32 +02:00
|
|
|
n->newname = $8;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-08-21 03:11:32 +02:00
|
|
|
}
|
2008-03-19 19:38:30 +01:00
|
|
|
| ALTER TYPE_P any_name RENAME TO name
|
|
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-03-19 19:38:30 +01:00
|
|
|
n->renameType = OBJECT_TYPE;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2008-03-19 19:38:30 +01:00
|
|
|
n->newname = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2008-03-19 19:38:30 +01:00
|
|
|
}
|
2010-11-23 21:50:17 +01:00
|
|
|
| ALTER TYPE_P any_name RENAME ATTRIBUTE name TO name opt_drop_behavior
|
2010-09-26 13:41:03 +02:00
|
|
|
{
|
|
|
|
|
RenameStmt *n = makeNode(RenameStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-09-26 13:41:03 +02:00
|
|
|
n->renameType = OBJECT_ATTRIBUTE;
|
2011-01-02 05:48:11 +01:00
|
|
|
n->relationType = OBJECT_TYPE;
|
2010-09-26 13:41:03 +02:00
|
|
|
n->relation = makeRangeVarFromAnyName($3, @3, yyscanner);
|
|
|
|
|
n->subname = $6;
|
|
|
|
|
n->newname = $8;
|
2010-11-23 21:50:17 +01:00
|
|
|
n->behavior = $9;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2010-09-26 13:41:03 +02:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
2020-11-12 07:48:36 +01:00
|
|
|
opt_column: COLUMN
|
|
|
|
|
| /*EMPTY*/
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
opt_set_data: SET DATA_P { $$ = 1; }
|
2008-10-21 10:38:16 +02:00
|
|
|
| /*EMPTY*/ { $$ = 0; }
|
|
|
|
|
;
|
|
|
|
|
|
2016-04-05 23:38:54 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* ALTER THING name DEPENDS ON EXTENSION name
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
AlterObjectDependsStmt:
|
2020-04-20 19:42:12 +02:00
|
|
|
ALTER FUNCTION function_with_argtypes opt_no DEPENDS ON EXTENSION name
|
2016-04-05 23:38:54 +02:00
|
|
|
{
|
|
|
|
|
AlterObjectDependsStmt *n = makeNode(AlterObjectDependsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2016-04-05 23:38:54 +02:00
|
|
|
n->objectType = OBJECT_FUNCTION;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2020-04-20 19:42:12 +02:00
|
|
|
n->extname = makeString($8);
|
|
|
|
|
n->remove = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2016-04-05 23:38:54 +02:00
|
|
|
}
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| ALTER PROCEDURE function_with_argtypes opt_no DEPENDS ON EXTENSION name
|
2017-11-30 14:46:13 +01:00
|
|
|
{
|
|
|
|
|
AlterObjectDependsStmt *n = makeNode(AlterObjectDependsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->objectType = OBJECT_PROCEDURE;
|
|
|
|
|
n->object = (Node *) $3;
|
2020-04-20 19:42:12 +02:00
|
|
|
n->extname = makeString($8);
|
|
|
|
|
n->remove = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-11-30 14:46:13 +01:00
|
|
|
}
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| ALTER ROUTINE function_with_argtypes opt_no DEPENDS ON EXTENSION name
|
2017-11-30 14:46:13 +01:00
|
|
|
{
|
|
|
|
|
AlterObjectDependsStmt *n = makeNode(AlterObjectDependsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->objectType = OBJECT_ROUTINE;
|
|
|
|
|
n->object = (Node *) $3;
|
2020-04-20 19:42:12 +02:00
|
|
|
n->extname = makeString($8);
|
|
|
|
|
n->remove = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-11-30 14:46:13 +01:00
|
|
|
}
|
2020-04-20 19:42:12 +02:00
|
|
|
| ALTER TRIGGER name ON qualified_name opt_no DEPENDS ON EXTENSION name
|
2016-04-05 23:38:54 +02:00
|
|
|
{
|
|
|
|
|
AlterObjectDependsStmt *n = makeNode(AlterObjectDependsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2016-04-05 23:38:54 +02:00
|
|
|
n->objectType = OBJECT_TRIGGER;
|
|
|
|
|
n->relation = $5;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) list_make1(makeString($3));
|
2020-04-20 19:42:12 +02:00
|
|
|
n->extname = makeString($10);
|
|
|
|
|
n->remove = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2016-04-05 23:38:54 +02:00
|
|
|
}
|
2020-04-20 19:42:12 +02:00
|
|
|
| ALTER MATERIALIZED VIEW qualified_name opt_no DEPENDS ON EXTENSION name
|
2016-04-05 23:38:54 +02:00
|
|
|
{
|
|
|
|
|
AlterObjectDependsStmt *n = makeNode(AlterObjectDependsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2016-04-05 23:38:54 +02:00
|
|
|
n->objectType = OBJECT_MATVIEW;
|
|
|
|
|
n->relation = $4;
|
2020-04-20 19:42:12 +02:00
|
|
|
n->extname = makeString($9);
|
|
|
|
|
n->remove = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2016-04-05 23:38:54 +02:00
|
|
|
}
|
2020-04-20 19:42:12 +02:00
|
|
|
| ALTER INDEX qualified_name opt_no DEPENDS ON EXTENSION name
|
2016-04-05 23:38:54 +02:00
|
|
|
{
|
|
|
|
|
AlterObjectDependsStmt *n = makeNode(AlterObjectDependsStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2016-04-05 23:38:54 +02:00
|
|
|
n->objectType = OBJECT_INDEX;
|
|
|
|
|
n->relation = $3;
|
2020-04-20 19:42:12 +02:00
|
|
|
n->extname = makeString($8);
|
|
|
|
|
n->remove = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2016-04-05 23:38:54 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2020-04-20 19:42:12 +02:00
|
|
|
opt_no: NO { $$ = true; }
|
|
|
|
|
| /* EMPTY */ { $$ = false; }
|
|
|
|
|
;
|
|
|
|
|
|
2005-08-01 06:03:59 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* ALTER THING name SET SCHEMA name
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
AlterObjectSchemaStmt:
|
2016-09-15 19:00:00 +02:00
|
|
|
ALTER AGGREGATE aggregate_with_argtypes SET SCHEMA name
|
2005-08-01 06:03:59 +02:00
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-08-01 06:03:59 +02:00
|
|
|
n->objectType = OBJECT_AGGREGATE;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2016-09-15 19:00:00 +02:00
|
|
|
n->newschema = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-08-01 06:03:59 +02:00
|
|
|
}
|
2011-02-12 14:54:13 +01:00
|
|
|
| ALTER COLLATION any_name SET SCHEMA name
|
|
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-02-12 14:54:13 +01:00
|
|
|
n->objectType = OBJECT_COLLATION;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2011-02-12 14:54:13 +01:00
|
|
|
n->newschema = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-02-12 14:54:13 +01:00
|
|
|
}
|
2010-11-26 23:27:23 +01:00
|
|
|
| ALTER CONVERSION_P any_name SET SCHEMA name
|
|
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-11-26 23:27:23 +01:00
|
|
|
n->objectType = OBJECT_CONVERSION;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2010-11-26 23:27:23 +01:00
|
|
|
n->newschema = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2010-11-26 23:27:23 +01:00
|
|
|
}
|
2005-08-01 06:03:59 +02:00
|
|
|
| ALTER DOMAIN_P any_name SET SCHEMA name
|
|
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-08-01 06:03:59 +02:00
|
|
|
n->objectType = OBJECT_DOMAIN;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2005-08-01 06:03:59 +02:00
|
|
|
n->newschema = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-08-01 06:03:59 +02:00
|
|
|
}
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
| ALTER EXTENSION name SET SCHEMA name
|
2011-02-08 22:08:41 +01:00
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-02-08 22:08:41 +01:00
|
|
|
n->objectType = OBJECT_EXTENSION;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) makeString($3);
|
2011-02-08 22:08:41 +01:00
|
|
|
n->newschema = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-02-08 22:08:41 +01:00
|
|
|
}
|
2007-09-03 02:39:26 +02:00
|
|
|
| ALTER FUNCTION function_with_argtypes SET SCHEMA name
|
2005-08-01 06:03:59 +02:00
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-08-01 06:03:59 +02:00
|
|
|
n->objectType = OBJECT_FUNCTION;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2007-09-03 02:39:26 +02:00
|
|
|
n->newschema = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-08-01 06:03:59 +02:00
|
|
|
}
|
2016-12-28 18:00:00 +01:00
|
|
|
| ALTER OPERATOR operator_with_argtypes SET SCHEMA name
|
2010-11-26 23:27:23 +01:00
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-11-26 23:27:23 +01:00
|
|
|
n->objectType = OBJECT_OPERATOR;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2016-12-28 18:00:00 +01:00
|
|
|
n->newschema = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2010-11-26 23:27:23 +01:00
|
|
|
}
|
2020-06-10 22:58:46 +02:00
|
|
|
| ALTER OPERATOR CLASS any_name USING name SET SCHEMA name
|
2010-11-26 23:27:23 +01:00
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-11-26 23:27:23 +01:00
|
|
|
n->objectType = OBJECT_OPCLASS;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) lcons(makeString($6), $4);
|
2010-11-26 23:27:23 +01:00
|
|
|
n->newschema = $9;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2010-11-26 23:27:23 +01:00
|
|
|
}
|
2020-06-10 22:58:46 +02:00
|
|
|
| ALTER OPERATOR FAMILY any_name USING name SET SCHEMA name
|
2010-11-26 23:27:23 +01:00
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-11-26 23:27:23 +01:00
|
|
|
n->objectType = OBJECT_OPFAMILY;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) lcons(makeString($6), $4);
|
2010-11-26 23:27:23 +01:00
|
|
|
n->newschema = $9;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2010-11-26 23:27:23 +01:00
|
|
|
}
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| ALTER PROCEDURE function_with_argtypes SET SCHEMA name
|
2017-11-30 14:46:13 +01:00
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->objectType = OBJECT_PROCEDURE;
|
|
|
|
|
n->object = (Node *) $3;
|
|
|
|
|
n->newschema = $6;
|
|
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-11-30 14:46:13 +01:00
|
|
|
}
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| ALTER ROUTINE function_with_argtypes SET SCHEMA name
|
2017-11-30 14:46:13 +01:00
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->objectType = OBJECT_ROUTINE;
|
|
|
|
|
n->object = (Node *) $3;
|
|
|
|
|
n->newschema = $6;
|
|
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-11-30 14:46:13 +01:00
|
|
|
}
|
2008-06-15 03:25:54 +02:00
|
|
|
| ALTER TABLE relation_expr SET SCHEMA name
|
|
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-06-15 03:25:54 +02:00
|
|
|
n->objectType = OBJECT_TABLE;
|
|
|
|
|
n->relation = $3;
|
|
|
|
|
n->newschema = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-01-24 00:25:04 +01:00
|
|
|
}
|
|
|
|
|
| ALTER TABLE IF_P EXISTS relation_expr SET SCHEMA name
|
|
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-01-24 00:25:04 +01:00
|
|
|
n->objectType = OBJECT_TABLE;
|
|
|
|
|
n->relation = $5;
|
|
|
|
|
n->newschema = $8;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2008-06-15 03:25:54 +02:00
|
|
|
}
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
| ALTER STATISTICS any_name SET SCHEMA name
|
|
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
n->objectType = OBJECT_STATISTIC_EXT;
|
|
|
|
|
n->object = (Node *) $3;
|
|
|
|
|
n->newschema = $6;
|
|
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
}
|
2010-11-26 23:27:23 +01:00
|
|
|
| ALTER TEXT_P SEARCH PARSER any_name SET SCHEMA name
|
|
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-11-26 23:27:23 +01:00
|
|
|
n->objectType = OBJECT_TSPARSER;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $5;
|
2010-11-26 23:27:23 +01:00
|
|
|
n->newschema = $8;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2010-11-26 23:27:23 +01:00
|
|
|
}
|
|
|
|
|
| ALTER TEXT_P SEARCH DICTIONARY any_name SET SCHEMA name
|
|
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-11-26 23:27:23 +01:00
|
|
|
n->objectType = OBJECT_TSDICTIONARY;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $5;
|
2010-11-26 23:27:23 +01:00
|
|
|
n->newschema = $8;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2010-11-26 23:27:23 +01:00
|
|
|
}
|
|
|
|
|
| ALTER TEXT_P SEARCH TEMPLATE any_name SET SCHEMA name
|
|
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-11-26 23:27:23 +01:00
|
|
|
n->objectType = OBJECT_TSTEMPLATE;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $5;
|
2010-11-26 23:27:23 +01:00
|
|
|
n->newschema = $8;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2010-11-26 23:27:23 +01:00
|
|
|
}
|
|
|
|
|
| ALTER TEXT_P SEARCH CONFIGURATION any_name SET SCHEMA name
|
|
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-11-26 23:27:23 +01:00
|
|
|
n->objectType = OBJECT_TSCONFIGURATION;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $5;
|
2010-11-26 23:27:23 +01:00
|
|
|
n->newschema = $8;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2010-11-26 23:27:23 +01:00
|
|
|
}
|
2009-01-12 10:38:30 +01:00
|
|
|
| ALTER SEQUENCE qualified_name SET SCHEMA name
|
2005-08-01 06:03:59 +02:00
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-08-01 06:03:59 +02:00
|
|
|
n->objectType = OBJECT_SEQUENCE;
|
|
|
|
|
n->relation = $3;
|
|
|
|
|
n->newschema = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-01-24 00:25:04 +01:00
|
|
|
}
|
|
|
|
|
| ALTER SEQUENCE IF_P EXISTS qualified_name SET SCHEMA name
|
|
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-01-24 00:25:04 +01:00
|
|
|
n->objectType = OBJECT_SEQUENCE;
|
|
|
|
|
n->relation = $5;
|
|
|
|
|
n->newschema = $8;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-08-01 06:03:59 +02:00
|
|
|
}
|
2009-01-12 10:38:30 +01:00
|
|
|
| ALTER VIEW qualified_name SET SCHEMA name
|
2005-08-01 06:03:59 +02:00
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-06-15 03:25:54 +02:00
|
|
|
n->objectType = OBJECT_VIEW;
|
2005-08-01 06:03:59 +02:00
|
|
|
n->relation = $3;
|
|
|
|
|
n->newschema = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-01-24 00:25:04 +01:00
|
|
|
}
|
|
|
|
|
| ALTER VIEW IF_P EXISTS qualified_name SET SCHEMA name
|
|
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-01-24 00:25:04 +01:00
|
|
|
n->objectType = OBJECT_VIEW;
|
|
|
|
|
n->relation = $5;
|
|
|
|
|
n->newschema = $8;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-08-01 06:03:59 +02:00
|
|
|
}
|
2013-03-04 01:23:31 +01:00
|
|
|
| ALTER MATERIALIZED VIEW qualified_name SET SCHEMA name
|
|
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2013-03-04 01:23:31 +01:00
|
|
|
n->objectType = OBJECT_MATVIEW;
|
|
|
|
|
n->relation = $4;
|
|
|
|
|
n->newschema = $7;
|
|
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2013-03-04 01:23:31 +01:00
|
|
|
}
|
|
|
|
|
| ALTER MATERIALIZED VIEW IF_P EXISTS qualified_name SET SCHEMA name
|
|
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2013-03-04 01:23:31 +01:00
|
|
|
n->objectType = OBJECT_MATVIEW;
|
|
|
|
|
n->relation = $6;
|
|
|
|
|
n->newschema = $9;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2013-03-04 01:23:31 +01:00
|
|
|
}
|
2011-01-02 05:48:11 +01:00
|
|
|
| ALTER FOREIGN TABLE relation_expr SET SCHEMA name
|
|
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-01-02 05:48:11 +01:00
|
|
|
n->objectType = OBJECT_FOREIGN_TABLE;
|
|
|
|
|
n->relation = $4;
|
|
|
|
|
n->newschema = $7;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-01-24 00:25:04 +01:00
|
|
|
}
|
|
|
|
|
| ALTER FOREIGN TABLE IF_P EXISTS relation_expr SET SCHEMA name
|
|
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-01-24 00:25:04 +01:00
|
|
|
n->objectType = OBJECT_FOREIGN_TABLE;
|
|
|
|
|
n->relation = $6;
|
|
|
|
|
n->newschema = $9;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-01-02 05:48:11 +01:00
|
|
|
}
|
2005-08-01 06:03:59 +02:00
|
|
|
| ALTER TYPE_P any_name SET SCHEMA name
|
|
|
|
|
{
|
|
|
|
|
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-08-01 06:03:59 +02:00
|
|
|
n->objectType = OBJECT_TYPE;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2005-08-01 06:03:59 +02:00
|
|
|
n->newschema = $6;
|
2012-01-24 00:25:04 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-08-01 06:03:59 +02:00
|
|
|
}
|
|
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2015-07-14 17:17:55 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* ALTER OPERATOR name SET define
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
AlterOperatorStmt:
|
2016-12-28 18:00:00 +01:00
|
|
|
ALTER OPERATOR operator_with_argtypes SET '(' operator_def_list ')'
|
2015-07-14 17:17:55 +02:00
|
|
|
{
|
|
|
|
|
AlterOperatorStmt *n = makeNode(AlterOperatorStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2016-12-28 18:00:00 +01:00
|
|
|
n->opername = $3;
|
2016-12-28 18:00:00 +01:00
|
|
|
n->options = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2015-07-14 17:17:55 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
operator_def_list: operator_def_elem { $$ = list_make1($1); }
|
|
|
|
|
| operator_def_list ',' operator_def_elem { $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
operator_def_elem: ColLabel '=' NONE
|
2016-09-06 18:00:00 +02:00
|
|
|
{ $$ = makeDefElem($1, NULL, @1); }
|
2017-05-09 16:20:42 +02:00
|
|
|
| ColLabel '=' operator_def_arg
|
|
|
|
|
{ $$ = makeDefElem($1, (Node *) $3, @1); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/* must be similar enough to def_arg to avoid reduce/reduce conflicts */
|
|
|
|
|
operator_def_arg:
|
2022-05-13 07:17:29 +02:00
|
|
|
func_type { $$ = (Node *) $1; }
|
|
|
|
|
| reserved_keyword { $$ = (Node *) makeString(pstrdup($1)); }
|
|
|
|
|
| qual_all_Op { $$ = (Node *) $1; }
|
|
|
|
|
| NumericOnly { $$ = (Node *) $1; }
|
|
|
|
|
| Sconst { $$ = (Node *) makeString($1); }
|
2015-07-14 17:17:55 +02:00
|
|
|
;
|
|
|
|
|
|
2020-03-06 18:19:29 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* ALTER TYPE name SET define
|
|
|
|
|
*
|
|
|
|
|
* We repurpose ALTER OPERATOR's version of "definition" here
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
AlterTypeStmt:
|
|
|
|
|
ALTER TYPE_P any_name SET '(' operator_def_list ')'
|
|
|
|
|
{
|
|
|
|
|
AlterTypeStmt *n = makeNode(AlterTypeStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2020-03-06 18:19:29 +01:00
|
|
|
n->typeName = $3;
|
|
|
|
|
n->options = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2020-03-06 18:19:29 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2004-06-25 23:55:59 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2005-08-01 06:03:59 +02:00
|
|
|
* ALTER THING name OWNER TO newname
|
2004-06-25 23:55:59 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2016-09-15 19:00:00 +02:00
|
|
|
AlterOwnerStmt: ALTER AGGREGATE aggregate_with_argtypes OWNER TO RoleSpec
|
2004-06-25 23:55:59 +02:00
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-06-25 23:55:59 +02:00
|
|
|
n->objectType = OBJECT_AGGREGATE;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2016-09-15 19:00:00 +02:00
|
|
|
n->newowner = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-06-25 23:55:59 +02:00
|
|
|
}
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
| ALTER COLLATION any_name OWNER TO RoleSpec
|
2011-02-12 14:54:13 +01:00
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-02-12 14:54:13 +01:00
|
|
|
n->objectType = OBJECT_COLLATION;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2011-02-12 14:54:13 +01:00
|
|
|
n->newowner = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-02-12 14:54:13 +01:00
|
|
|
}
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
| ALTER CONVERSION_P any_name OWNER TO RoleSpec
|
2004-06-25 23:55:59 +02:00
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-06-25 23:55:59 +02:00
|
|
|
n->objectType = OBJECT_CONVERSION;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2004-06-25 23:55:59 +02:00
|
|
|
n->newowner = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-06-25 23:55:59 +02:00
|
|
|
}
|
2020-06-10 22:58:46 +02:00
|
|
|
| ALTER DATABASE name OWNER TO RoleSpec
|
2004-06-25 23:55:59 +02:00
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-06-25 23:55:59 +02:00
|
|
|
n->objectType = OBJECT_DATABASE;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) makeString($3);
|
2004-06-25 23:55:59 +02:00
|
|
|
n->newowner = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-06-25 23:55:59 +02:00
|
|
|
}
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
| ALTER DOMAIN_P any_name OWNER TO RoleSpec
|
2004-06-25 23:55:59 +02:00
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-06-25 23:55:59 +02:00
|
|
|
n->objectType = OBJECT_DOMAIN;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2004-06-25 23:55:59 +02:00
|
|
|
n->newowner = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-06-25 23:55:59 +02:00
|
|
|
}
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
| ALTER FUNCTION function_with_argtypes OWNER TO RoleSpec
|
2004-06-25 23:55:59 +02:00
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-06-25 23:55:59 +02:00
|
|
|
n->objectType = OBJECT_FUNCTION;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2007-09-03 02:39:26 +02:00
|
|
|
n->newowner = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-06-25 23:55:59 +02:00
|
|
|
}
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
| ALTER opt_procedural LANGUAGE name OWNER TO RoleSpec
|
2007-03-26 18:58:41 +02:00
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-03-26 18:58:41 +02:00
|
|
|
n->objectType = OBJECT_LANGUAGE;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) makeString($4);
|
2007-03-26 18:58:41 +02:00
|
|
|
n->newowner = $7;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-03-26 18:58:41 +02:00
|
|
|
}
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
| ALTER LARGE_P OBJECT_P NumericOnly OWNER TO RoleSpec
|
2009-12-11 04:34:57 +01:00
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-12-11 04:34:57 +01:00
|
|
|
n->objectType = OBJECT_LARGEOBJECT;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $4;
|
2009-12-11 04:34:57 +01:00
|
|
|
n->newowner = $7;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2009-12-11 04:34:57 +01:00
|
|
|
}
|
2016-12-28 18:00:00 +01:00
|
|
|
| ALTER OPERATOR operator_with_argtypes OWNER TO RoleSpec
|
2004-06-25 23:55:59 +02:00
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-06-25 23:55:59 +02:00
|
|
|
n->objectType = OBJECT_OPERATOR;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2016-12-28 18:00:00 +01:00
|
|
|
n->newowner = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-06-25 23:55:59 +02:00
|
|
|
}
|
2020-06-10 22:58:46 +02:00
|
|
|
| ALTER OPERATOR CLASS any_name USING name OWNER TO RoleSpec
|
2004-06-25 23:55:59 +02:00
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-06-25 23:55:59 +02:00
|
|
|
n->objectType = OBJECT_OPCLASS;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) lcons(makeString($6), $4);
|
2004-06-25 23:55:59 +02:00
|
|
|
n->newowner = $9;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-06-25 23:55:59 +02:00
|
|
|
}
|
2020-06-10 22:58:46 +02:00
|
|
|
| ALTER OPERATOR FAMILY any_name USING name OWNER TO RoleSpec
|
2007-01-23 06:07:18 +01:00
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-01-23 06:07:18 +01:00
|
|
|
n->objectType = OBJECT_OPFAMILY;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) lcons(makeString($6), $4);
|
2007-01-23 06:07:18 +01:00
|
|
|
n->newowner = $9;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-01-23 06:07:18 +01:00
|
|
|
}
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| ALTER PROCEDURE function_with_argtypes OWNER TO RoleSpec
|
2017-11-30 14:46:13 +01:00
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->objectType = OBJECT_PROCEDURE;
|
|
|
|
|
n->object = (Node *) $3;
|
|
|
|
|
n->newowner = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-11-30 14:46:13 +01:00
|
|
|
}
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
| ALTER ROUTINE function_with_argtypes OWNER TO RoleSpec
|
2017-11-30 14:46:13 +01:00
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-11-30 14:46:13 +01:00
|
|
|
n->objectType = OBJECT_ROUTINE;
|
|
|
|
|
n->object = (Node *) $3;
|
|
|
|
|
n->newowner = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-11-30 14:46:13 +01:00
|
|
|
}
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
| ALTER SCHEMA name OWNER TO RoleSpec
|
2004-06-25 23:55:59 +02:00
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-06-25 23:55:59 +02:00
|
|
|
n->objectType = OBJECT_SCHEMA;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) makeString($3);
|
2004-06-25 23:55:59 +02:00
|
|
|
n->newowner = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-06-25 23:55:59 +02:00
|
|
|
}
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
| ALTER TYPE_P any_name OWNER TO RoleSpec
|
2004-06-25 23:55:59 +02:00
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-06-25 23:55:59 +02:00
|
|
|
n->objectType = OBJECT_TYPE;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $3;
|
2004-06-25 23:55:59 +02:00
|
|
|
n->newowner = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-06-25 23:55:59 +02:00
|
|
|
}
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
| ALTER TABLESPACE name OWNER TO RoleSpec
|
2004-06-25 23:55:59 +02:00
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-06-25 23:55:59 +02:00
|
|
|
n->objectType = OBJECT_TABLESPACE;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) makeString($3);
|
2004-06-25 23:55:59 +02:00
|
|
|
n->newowner = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-06-25 23:55:59 +02:00
|
|
|
}
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
| ALTER STATISTICS any_name OWNER TO RoleSpec
|
|
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
n->objectType = OBJECT_STATISTIC_EXT;
|
|
|
|
|
n->object = (Node *) $3;
|
|
|
|
|
n->newowner = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
}
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
| ALTER TEXT_P SEARCH DICTIONARY any_name OWNER TO RoleSpec
|
2007-08-21 03:11:32 +02:00
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-08-21 03:11:32 +02:00
|
|
|
n->objectType = OBJECT_TSDICTIONARY;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $5;
|
2007-08-21 03:11:32 +02:00
|
|
|
n->newowner = $8;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-08-21 03:11:32 +02:00
|
|
|
}
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
| ALTER TEXT_P SEARCH CONFIGURATION any_name OWNER TO RoleSpec
|
2007-08-21 03:11:32 +02:00
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-08-21 03:11:32 +02:00
|
|
|
n->objectType = OBJECT_TSCONFIGURATION;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) $5;
|
2007-08-21 03:11:32 +02:00
|
|
|
n->newowner = $8;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-08-21 03:11:32 +02:00
|
|
|
}
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
| ALTER FOREIGN DATA_P WRAPPER name OWNER TO RoleSpec
|
2008-12-19 17:25:19 +01:00
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-12-19 17:25:19 +01:00
|
|
|
n->objectType = OBJECT_FDW;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) makeString($5);
|
2008-12-19 17:25:19 +01:00
|
|
|
n->newowner = $8;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2008-12-19 17:25:19 +01:00
|
|
|
}
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
| ALTER SERVER name OWNER TO RoleSpec
|
2008-12-19 17:25:19 +01:00
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-12-19 17:25:19 +01:00
|
|
|
n->objectType = OBJECT_FOREIGN_SERVER;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) makeString($3);
|
2008-12-19 17:25:19 +01:00
|
|
|
n->newowner = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2008-12-19 17:25:19 +01:00
|
|
|
}
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
| ALTER EVENT TRIGGER name OWNER TO RoleSpec
|
2012-07-18 16:16:16 +02:00
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-07-18 16:16:16 +02:00
|
|
|
n->objectType = OBJECT_EVENT_TRIGGER;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) makeString($4);
|
2012-07-18 16:16:16 +02:00
|
|
|
n->newowner = $7;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-07-18 16:16:16 +02:00
|
|
|
}
|
2017-01-19 18:00:00 +01:00
|
|
|
| ALTER PUBLICATION name OWNER TO RoleSpec
|
|
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
n->objectType = OBJECT_PUBLICATION;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) makeString($3);
|
2017-01-19 18:00:00 +01:00
|
|
|
n->newowner = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
|
|
|
|
| ALTER SUBSCRIPTION name OWNER TO RoleSpec
|
|
|
|
|
{
|
|
|
|
|
AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
n->objectType = OBJECT_SUBSCRIPTION;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
n->object = (Node *) makeString($3);
|
2017-01-19 18:00:00 +01:00
|
|
|
n->newowner = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
* CREATE PUBLICATION name [WITH options]
|
|
|
|
|
*
|
|
|
|
|
* CREATE PUBLICATION FOR ALL TABLES [WITH options]
|
|
|
|
|
*
|
Add decoding of sequences to built-in replication
This commit adds support for decoding of sequences to the built-in
replication (the infrastructure was added by commit 0da92dc530).
The syntax and behavior mostly mimics handling of tables, i.e. a
publication may be defined as FOR ALL SEQUENCES (replicating all
sequences in a database), FOR ALL SEQUENCES IN SCHEMA (replicating
all sequences in a particular schema) or individual sequences.
To publish sequence modifications, the publication has to include
'sequence' action. The protocol is extended with a new message,
describing sequence increments.
A new system view pg_publication_sequences lists all the sequences
added to a publication, both directly and indirectly. Various psql
commands (\d and \dRp) are improved to also display publications
including a given sequence, or sequences included in a publication.
Author: Tomas Vondra, Cary Huang
Reviewed-by: Peter Eisentraut, Amit Kapila, Hannu Krosing, Andres
Freund, Petr Jelinek
Discussion: https://postgr.es/m/d045f3c2-6cfb-06d3-5540-e63c320df8bc@enterprisedb.com
Discussion: https://postgr.es/m/1710ed7e13b.cd7177461430746.3372264562543607781@highgo.ca
2022-03-24 18:20:21 +01:00
|
|
|
* CREATE PUBLICATION FOR pub_obj [, ...] [WITH options]
|
2017-01-19 18:00:00 +01:00
|
|
|
*
|
2022-04-07 18:13:13 +02:00
|
|
|
* pub_obj is one of:
|
|
|
|
|
*
|
|
|
|
|
* TABLE table [, ...]
|
2022-09-22 19:02:25 +02:00
|
|
|
* TABLES IN SCHEMA schema [, ...]
|
2022-04-07 18:13:13 +02:00
|
|
|
*
|
2017-01-19 18:00:00 +01:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
CreatePublicationStmt:
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
CREATE PUBLICATION name opt_definition
|
2017-01-19 18:00:00 +01:00
|
|
|
{
|
|
|
|
|
CreatePublicationStmt *n = makeNode(CreatePublicationStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
n->pubname = $3;
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
n->options = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
}
|
2022-04-07 18:13:13 +02:00
|
|
|
| CREATE PUBLICATION name FOR ALL TABLES opt_definition
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
{
|
|
|
|
|
CreatePublicationStmt *n = makeNode(CreatePublicationStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
n->pubname = $3;
|
|
|
|
|
n->options = $7;
|
2022-04-07 18:13:13 +02:00
|
|
|
n->for_all_tables = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
}
|
|
|
|
|
| CREATE PUBLICATION name FOR pub_obj_list opt_definition
|
|
|
|
|
{
|
|
|
|
|
CreatePublicationStmt *n = makeNode(CreatePublicationStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
n->pubname = $3;
|
|
|
|
|
n->options = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
n->pubobjects = (List *) $5;
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
preprocess_pubobj_list(n->pubobjects, yyscanner);
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
2004-06-25 23:55:59 +02:00
|
|
|
;
|
|
|
|
|
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
/*
|
2022-09-22 19:02:25 +02:00
|
|
|
* FOR TABLE and FOR TABLES IN SCHEMA specifications
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
*
|
|
|
|
|
* This rule parses publication objects with and without keyword prefixes.
|
|
|
|
|
*
|
|
|
|
|
* The actual type of the object without keyword prefix depends on the previous
|
|
|
|
|
* one with keyword prefix. It will be preprocessed in preprocess_pubobj_list().
|
|
|
|
|
*
|
|
|
|
|
* For the object without keyword prefix, we cannot just use relation_expr here,
|
|
|
|
|
* because some extended expressions in relation_expr cannot be used as a
|
|
|
|
|
* schemaname and we cannot differentiate it. So, we extract the rules from
|
|
|
|
|
* relation_expr here.
|
|
|
|
|
*/
|
|
|
|
|
PublicationObjSpec:
|
Allow specifying column lists for logical replication
This allows specifying an optional column list when adding a table to
logical replication. The column list may be specified after the table
name, enclosed in parentheses. Columns not included in this list are not
sent to the subscriber, allowing the schema on the subscriber to be a
subset of the publisher schema.
For UPDATE/DELETE publications, the column list needs to cover all
REPLICA IDENTITY columns. For INSERT publications, the column list is
arbitrary and may omit some REPLICA IDENTITY columns. Furthermore, if
the table uses REPLICA IDENTITY FULL, column list is not allowed.
The column list can contain only simple column references. Complex
expressions, function calls etc. are not allowed. This restriction could
be relaxed in the future.
During the initial table synchronization, only columns included in the
column list are copied to the subscriber. If the subscription has
several publications, containing the same table with different column
lists, columns specified in any of the lists will be copied.
This means all columns are replicated if the table has no column list
at all (which is treated as column list with all columns), or when of
the publications is defined as FOR ALL TABLES (possibly IN SCHEMA that
matches the schema of the table).
For partitioned tables, publish_via_partition_root determines whether
the column list for the root or the leaf relation will be used. If the
parameter is 'false' (the default), the list defined for the leaf
relation is used. Otherwise, the column list for the root partition
will be used.
Psql commands \dRp+ and \d <table-name> now display any column lists.
Author: Tomas Vondra, Alvaro Herrera, Rahila Syed
Reviewed-by: Peter Eisentraut, Alvaro Herrera, Vignesh C, Ibrar Ahmed,
Amit Kapila, Hou zj, Peter Smith, Wang wei, Tang, Shi yu
Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektNRH8NJ1jf95g@mail.gmail.com
2022-03-26 00:45:21 +01:00
|
|
|
TABLE relation_expr opt_column_list OptWhereClause
|
2017-01-19 18:00:00 +01:00
|
|
|
{
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
$$ = makeNode(PublicationObjSpec);
|
|
|
|
|
$$->pubobjtype = PUBLICATIONOBJ_TABLE;
|
|
|
|
|
$$->pubtable = makeNode(PublicationTable);
|
|
|
|
|
$$->pubtable->relation = $2;
|
Allow specifying column lists for logical replication
This allows specifying an optional column list when adding a table to
logical replication. The column list may be specified after the table
name, enclosed in parentheses. Columns not included in this list are not
sent to the subscriber, allowing the schema on the subscriber to be a
subset of the publisher schema.
For UPDATE/DELETE publications, the column list needs to cover all
REPLICA IDENTITY columns. For INSERT publications, the column list is
arbitrary and may omit some REPLICA IDENTITY columns. Furthermore, if
the table uses REPLICA IDENTITY FULL, column list is not allowed.
The column list can contain only simple column references. Complex
expressions, function calls etc. are not allowed. This restriction could
be relaxed in the future.
During the initial table synchronization, only columns included in the
column list are copied to the subscriber. If the subscription has
several publications, containing the same table with different column
lists, columns specified in any of the lists will be copied.
This means all columns are replicated if the table has no column list
at all (which is treated as column list with all columns), or when of
the publications is defined as FOR ALL TABLES (possibly IN SCHEMA that
matches the schema of the table).
For partitioned tables, publish_via_partition_root determines whether
the column list for the root or the leaf relation will be used. If the
parameter is 'false' (the default), the list defined for the leaf
relation is used. Otherwise, the column list for the root partition
will be used.
Psql commands \dRp+ and \d <table-name> now display any column lists.
Author: Tomas Vondra, Alvaro Herrera, Rahila Syed
Reviewed-by: Peter Eisentraut, Alvaro Herrera, Vignesh C, Ibrar Ahmed,
Amit Kapila, Hou zj, Peter Smith, Wang wei, Tang, Shi yu
Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektNRH8NJ1jf95g@mail.gmail.com
2022-03-26 00:45:21 +01:00
|
|
|
$$->pubtable->columns = $3;
|
|
|
|
|
$$->pubtable->whereClause = $4;
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
2022-09-22 19:02:25 +02:00
|
|
|
| TABLES IN_P SCHEMA ColId
|
2017-01-19 18:00:00 +01:00
|
|
|
{
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
$$ = makeNode(PublicationObjSpec);
|
2021-12-30 23:24:26 +01:00
|
|
|
$$->pubobjtype = PUBLICATIONOBJ_TABLES_IN_SCHEMA;
|
2022-09-22 19:02:25 +02:00
|
|
|
$$->name = $4;
|
|
|
|
|
$$->location = @4;
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
2022-09-22 19:02:25 +02:00
|
|
|
| TABLES IN_P SCHEMA CURRENT_SCHEMA
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
{
|
|
|
|
|
$$ = makeNode(PublicationObjSpec);
|
2021-12-30 23:24:26 +01:00
|
|
|
$$->pubobjtype = PUBLICATIONOBJ_TABLES_IN_CUR_SCHEMA;
|
2022-09-22 19:02:25 +02:00
|
|
|
$$->location = @4;
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
}
|
Allow specifying column lists for logical replication
This allows specifying an optional column list when adding a table to
logical replication. The column list may be specified after the table
name, enclosed in parentheses. Columns not included in this list are not
sent to the subscriber, allowing the schema on the subscriber to be a
subset of the publisher schema.
For UPDATE/DELETE publications, the column list needs to cover all
REPLICA IDENTITY columns. For INSERT publications, the column list is
arbitrary and may omit some REPLICA IDENTITY columns. Furthermore, if
the table uses REPLICA IDENTITY FULL, column list is not allowed.
The column list can contain only simple column references. Complex
expressions, function calls etc. are not allowed. This restriction could
be relaxed in the future.
During the initial table synchronization, only columns included in the
column list are copied to the subscriber. If the subscription has
several publications, containing the same table with different column
lists, columns specified in any of the lists will be copied.
This means all columns are replicated if the table has no column list
at all (which is treated as column list with all columns), or when of
the publications is defined as FOR ALL TABLES (possibly IN SCHEMA that
matches the schema of the table).
For partitioned tables, publish_via_partition_root determines whether
the column list for the root or the leaf relation will be used. If the
parameter is 'false' (the default), the list defined for the leaf
relation is used. Otherwise, the column list for the root partition
will be used.
Psql commands \dRp+ and \d <table-name> now display any column lists.
Author: Tomas Vondra, Alvaro Herrera, Rahila Syed
Reviewed-by: Peter Eisentraut, Alvaro Herrera, Vignesh C, Ibrar Ahmed,
Amit Kapila, Hou zj, Peter Smith, Wang wei, Tang, Shi yu
Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektNRH8NJ1jf95g@mail.gmail.com
2022-03-26 00:45:21 +01:00
|
|
|
| ColId opt_column_list OptWhereClause
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
{
|
|
|
|
|
$$ = makeNode(PublicationObjSpec);
|
|
|
|
|
$$->pubobjtype = PUBLICATIONOBJ_CONTINUATION;
|
Allow specifying column lists for logical replication
This allows specifying an optional column list when adding a table to
logical replication. The column list may be specified after the table
name, enclosed in parentheses. Columns not included in this list are not
sent to the subscriber, allowing the schema on the subscriber to be a
subset of the publisher schema.
For UPDATE/DELETE publications, the column list needs to cover all
REPLICA IDENTITY columns. For INSERT publications, the column list is
arbitrary and may omit some REPLICA IDENTITY columns. Furthermore, if
the table uses REPLICA IDENTITY FULL, column list is not allowed.
The column list can contain only simple column references. Complex
expressions, function calls etc. are not allowed. This restriction could
be relaxed in the future.
During the initial table synchronization, only columns included in the
column list are copied to the subscriber. If the subscription has
several publications, containing the same table with different column
lists, columns specified in any of the lists will be copied.
This means all columns are replicated if the table has no column list
at all (which is treated as column list with all columns), or when of
the publications is defined as FOR ALL TABLES (possibly IN SCHEMA that
matches the schema of the table).
For partitioned tables, publish_via_partition_root determines whether
the column list for the root or the leaf relation will be used. If the
parameter is 'false' (the default), the list defined for the leaf
relation is used. Otherwise, the column list for the root partition
will be used.
Psql commands \dRp+ and \d <table-name> now display any column lists.
Author: Tomas Vondra, Alvaro Herrera, Rahila Syed
Reviewed-by: Peter Eisentraut, Alvaro Herrera, Vignesh C, Ibrar Ahmed,
Amit Kapila, Hou zj, Peter Smith, Wang wei, Tang, Shi yu
Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektNRH8NJ1jf95g@mail.gmail.com
2022-03-26 00:45:21 +01:00
|
|
|
/*
|
|
|
|
|
* If either a row filter or column list is specified, create
|
|
|
|
|
* a PublicationTable object.
|
|
|
|
|
*/
|
|
|
|
|
if ($2 || $3)
|
Allow specifying row filters for logical replication of tables.
This feature adds row filtering for publication tables. When a publication
is defined or modified, an optional WHERE clause can be specified. Rows
that don't satisfy this WHERE clause will be filtered out. This allows a
set of tables to be partially replicated. The row filter is per table. A
new row filter can be added simply by specifying a WHERE clause after the
table name. The WHERE clause must be enclosed by parentheses.
The row filter WHERE clause for a table added to a publication that
publishes UPDATE and/or DELETE operations must contain only columns that
are covered by REPLICA IDENTITY. The row filter WHERE clause for a table
added to a publication that publishes INSERT can use any column. If the
row filter evaluates to NULL, it is regarded as "false". The WHERE clause
only allows simple expressions that don't have user-defined functions,
user-defined operators, user-defined types, user-defined collations,
non-immutable built-in functions, or references to system columns. These
restrictions could be addressed in the future.
If you choose to do the initial table synchronization, only data that
satisfies the row filters is copied to the subscriber. If the subscription
has several publications in which a table has been published with
different WHERE clauses, rows that satisfy ANY of the expressions will be
copied. If a subscriber is a pre-15 version, the initial table
synchronization won't use row filters even if they are defined in the
publisher.
The row filters are applied before publishing the changes. If the
subscription has several publications in which the same table has been
published with different filters (for the same publish operation), those
expressions get OR'ed together so that rows satisfying any of the
expressions will be replicated.
This means all the other filters become redundant if (a) one of the
publications have no filter at all, (b) one of the publications was
created using FOR ALL TABLES, (c) one of the publications was created
using FOR ALL TABLES IN SCHEMA and the table belongs to that same schema.
If your publication contains a partitioned table, the publication
parameter publish_via_partition_root determines if it uses the partition's
row filter (if the parameter is false, the default) or the root
partitioned table's row filter.
Psql commands \dRp+ and \d <table-name> will display any row filters.
Author: Hou Zhijie, Euler Taveira, Peter Smith, Ajin Cherian
Reviewed-by: Greg Nancarrow, Haiying Tang, Amit Kapila, Tomas Vondra, Dilip Kumar, Vignesh C, Alvaro Herrera, Andres Freund, Wei Wang
Discussion: https://www.postgresql.org/message-id/flat/CAHE3wggb715X%2BmK_DitLXF25B%3DjE6xyNCH4YOwM860JR7HarGQ%40mail.gmail.com
2022-02-22 03:24:12 +01:00
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* The OptWhereClause must be stored here but it is
|
|
|
|
|
* valid only for tables. For non-table objects, an
|
|
|
|
|
* error will be thrown later via
|
|
|
|
|
* preprocess_pubobj_list().
|
|
|
|
|
*/
|
|
|
|
|
$$->pubtable = makeNode(PublicationTable);
|
|
|
|
|
$$->pubtable->relation = makeRangeVar(NULL, $1, @1);
|
Allow specifying column lists for logical replication
This allows specifying an optional column list when adding a table to
logical replication. The column list may be specified after the table
name, enclosed in parentheses. Columns not included in this list are not
sent to the subscriber, allowing the schema on the subscriber to be a
subset of the publisher schema.
For UPDATE/DELETE publications, the column list needs to cover all
REPLICA IDENTITY columns. For INSERT publications, the column list is
arbitrary and may omit some REPLICA IDENTITY columns. Furthermore, if
the table uses REPLICA IDENTITY FULL, column list is not allowed.
The column list can contain only simple column references. Complex
expressions, function calls etc. are not allowed. This restriction could
be relaxed in the future.
During the initial table synchronization, only columns included in the
column list are copied to the subscriber. If the subscription has
several publications, containing the same table with different column
lists, columns specified in any of the lists will be copied.
This means all columns are replicated if the table has no column list
at all (which is treated as column list with all columns), or when of
the publications is defined as FOR ALL TABLES (possibly IN SCHEMA that
matches the schema of the table).
For partitioned tables, publish_via_partition_root determines whether
the column list for the root or the leaf relation will be used. If the
parameter is 'false' (the default), the list defined for the leaf
relation is used. Otherwise, the column list for the root partition
will be used.
Psql commands \dRp+ and \d <table-name> now display any column lists.
Author: Tomas Vondra, Alvaro Herrera, Rahila Syed
Reviewed-by: Peter Eisentraut, Alvaro Herrera, Vignesh C, Ibrar Ahmed,
Amit Kapila, Hou zj, Peter Smith, Wang wei, Tang, Shi yu
Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektNRH8NJ1jf95g@mail.gmail.com
2022-03-26 00:45:21 +01:00
|
|
|
$$->pubtable->columns = $2;
|
|
|
|
|
$$->pubtable->whereClause = $3;
|
Allow specifying row filters for logical replication of tables.
This feature adds row filtering for publication tables. When a publication
is defined or modified, an optional WHERE clause can be specified. Rows
that don't satisfy this WHERE clause will be filtered out. This allows a
set of tables to be partially replicated. The row filter is per table. A
new row filter can be added simply by specifying a WHERE clause after the
table name. The WHERE clause must be enclosed by parentheses.
The row filter WHERE clause for a table added to a publication that
publishes UPDATE and/or DELETE operations must contain only columns that
are covered by REPLICA IDENTITY. The row filter WHERE clause for a table
added to a publication that publishes INSERT can use any column. If the
row filter evaluates to NULL, it is regarded as "false". The WHERE clause
only allows simple expressions that don't have user-defined functions,
user-defined operators, user-defined types, user-defined collations,
non-immutable built-in functions, or references to system columns. These
restrictions could be addressed in the future.
If you choose to do the initial table synchronization, only data that
satisfies the row filters is copied to the subscriber. If the subscription
has several publications in which a table has been published with
different WHERE clauses, rows that satisfy ANY of the expressions will be
copied. If a subscriber is a pre-15 version, the initial table
synchronization won't use row filters even if they are defined in the
publisher.
The row filters are applied before publishing the changes. If the
subscription has several publications in which the same table has been
published with different filters (for the same publish operation), those
expressions get OR'ed together so that rows satisfying any of the
expressions will be replicated.
This means all the other filters become redundant if (a) one of the
publications have no filter at all, (b) one of the publications was
created using FOR ALL TABLES, (c) one of the publications was created
using FOR ALL TABLES IN SCHEMA and the table belongs to that same schema.
If your publication contains a partitioned table, the publication
parameter publish_via_partition_root determines if it uses the partition's
row filter (if the parameter is false, the default) or the root
partitioned table's row filter.
Psql commands \dRp+ and \d <table-name> will display any row filters.
Author: Hou Zhijie, Euler Taveira, Peter Smith, Ajin Cherian
Reviewed-by: Greg Nancarrow, Haiying Tang, Amit Kapila, Tomas Vondra, Dilip Kumar, Vignesh C, Alvaro Herrera, Andres Freund, Wei Wang
Discussion: https://www.postgresql.org/message-id/flat/CAHE3wggb715X%2BmK_DitLXF25B%3DjE6xyNCH4YOwM860JR7HarGQ%40mail.gmail.com
2022-02-22 03:24:12 +01:00
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
$$->name = $1;
|
|
|
|
|
}
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
$$->location = @1;
|
|
|
|
|
}
|
Allow specifying column lists for logical replication
This allows specifying an optional column list when adding a table to
logical replication. The column list may be specified after the table
name, enclosed in parentheses. Columns not included in this list are not
sent to the subscriber, allowing the schema on the subscriber to be a
subset of the publisher schema.
For UPDATE/DELETE publications, the column list needs to cover all
REPLICA IDENTITY columns. For INSERT publications, the column list is
arbitrary and may omit some REPLICA IDENTITY columns. Furthermore, if
the table uses REPLICA IDENTITY FULL, column list is not allowed.
The column list can contain only simple column references. Complex
expressions, function calls etc. are not allowed. This restriction could
be relaxed in the future.
During the initial table synchronization, only columns included in the
column list are copied to the subscriber. If the subscription has
several publications, containing the same table with different column
lists, columns specified in any of the lists will be copied.
This means all columns are replicated if the table has no column list
at all (which is treated as column list with all columns), or when of
the publications is defined as FOR ALL TABLES (possibly IN SCHEMA that
matches the schema of the table).
For partitioned tables, publish_via_partition_root determines whether
the column list for the root or the leaf relation will be used. If the
parameter is 'false' (the default), the list defined for the leaf
relation is used. Otherwise, the column list for the root partition
will be used.
Psql commands \dRp+ and \d <table-name> now display any column lists.
Author: Tomas Vondra, Alvaro Herrera, Rahila Syed
Reviewed-by: Peter Eisentraut, Alvaro Herrera, Vignesh C, Ibrar Ahmed,
Amit Kapila, Hou zj, Peter Smith, Wang wei, Tang, Shi yu
Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektNRH8NJ1jf95g@mail.gmail.com
2022-03-26 00:45:21 +01:00
|
|
|
| ColId indirection opt_column_list OptWhereClause
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
{
|
|
|
|
|
$$ = makeNode(PublicationObjSpec);
|
|
|
|
|
$$->pubobjtype = PUBLICATIONOBJ_CONTINUATION;
|
|
|
|
|
$$->pubtable = makeNode(PublicationTable);
|
|
|
|
|
$$->pubtable->relation = makeRangeVarFromQualifiedName($1, $2, @1, yyscanner);
|
Allow specifying column lists for logical replication
This allows specifying an optional column list when adding a table to
logical replication. The column list may be specified after the table
name, enclosed in parentheses. Columns not included in this list are not
sent to the subscriber, allowing the schema on the subscriber to be a
subset of the publisher schema.
For UPDATE/DELETE publications, the column list needs to cover all
REPLICA IDENTITY columns. For INSERT publications, the column list is
arbitrary and may omit some REPLICA IDENTITY columns. Furthermore, if
the table uses REPLICA IDENTITY FULL, column list is not allowed.
The column list can contain only simple column references. Complex
expressions, function calls etc. are not allowed. This restriction could
be relaxed in the future.
During the initial table synchronization, only columns included in the
column list are copied to the subscriber. If the subscription has
several publications, containing the same table with different column
lists, columns specified in any of the lists will be copied.
This means all columns are replicated if the table has no column list
at all (which is treated as column list with all columns), or when of
the publications is defined as FOR ALL TABLES (possibly IN SCHEMA that
matches the schema of the table).
For partitioned tables, publish_via_partition_root determines whether
the column list for the root or the leaf relation will be used. If the
parameter is 'false' (the default), the list defined for the leaf
relation is used. Otherwise, the column list for the root partition
will be used.
Psql commands \dRp+ and \d <table-name> now display any column lists.
Author: Tomas Vondra, Alvaro Herrera, Rahila Syed
Reviewed-by: Peter Eisentraut, Alvaro Herrera, Vignesh C, Ibrar Ahmed,
Amit Kapila, Hou zj, Peter Smith, Wang wei, Tang, Shi yu
Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektNRH8NJ1jf95g@mail.gmail.com
2022-03-26 00:45:21 +01:00
|
|
|
$$->pubtable->columns = $3;
|
|
|
|
|
$$->pubtable->whereClause = $4;
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
$$->location = @1;
|
|
|
|
|
}
|
|
|
|
|
/* grammar like tablename * , ONLY tablename, ONLY ( tablename ) */
|
Allow specifying column lists for logical replication
This allows specifying an optional column list when adding a table to
logical replication. The column list may be specified after the table
name, enclosed in parentheses. Columns not included in this list are not
sent to the subscriber, allowing the schema on the subscriber to be a
subset of the publisher schema.
For UPDATE/DELETE publications, the column list needs to cover all
REPLICA IDENTITY columns. For INSERT publications, the column list is
arbitrary and may omit some REPLICA IDENTITY columns. Furthermore, if
the table uses REPLICA IDENTITY FULL, column list is not allowed.
The column list can contain only simple column references. Complex
expressions, function calls etc. are not allowed. This restriction could
be relaxed in the future.
During the initial table synchronization, only columns included in the
column list are copied to the subscriber. If the subscription has
several publications, containing the same table with different column
lists, columns specified in any of the lists will be copied.
This means all columns are replicated if the table has no column list
at all (which is treated as column list with all columns), or when of
the publications is defined as FOR ALL TABLES (possibly IN SCHEMA that
matches the schema of the table).
For partitioned tables, publish_via_partition_root determines whether
the column list for the root or the leaf relation will be used. If the
parameter is 'false' (the default), the list defined for the leaf
relation is used. Otherwise, the column list for the root partition
will be used.
Psql commands \dRp+ and \d <table-name> now display any column lists.
Author: Tomas Vondra, Alvaro Herrera, Rahila Syed
Reviewed-by: Peter Eisentraut, Alvaro Herrera, Vignesh C, Ibrar Ahmed,
Amit Kapila, Hou zj, Peter Smith, Wang wei, Tang, Shi yu
Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektNRH8NJ1jf95g@mail.gmail.com
2022-03-26 00:45:21 +01:00
|
|
|
| extended_relation_expr opt_column_list OptWhereClause
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
{
|
|
|
|
|
$$ = makeNode(PublicationObjSpec);
|
|
|
|
|
$$->pubobjtype = PUBLICATIONOBJ_CONTINUATION;
|
|
|
|
|
$$->pubtable = makeNode(PublicationTable);
|
|
|
|
|
$$->pubtable->relation = $1;
|
Allow specifying column lists for logical replication
This allows specifying an optional column list when adding a table to
logical replication. The column list may be specified after the table
name, enclosed in parentheses. Columns not included in this list are not
sent to the subscriber, allowing the schema on the subscriber to be a
subset of the publisher schema.
For UPDATE/DELETE publications, the column list needs to cover all
REPLICA IDENTITY columns. For INSERT publications, the column list is
arbitrary and may omit some REPLICA IDENTITY columns. Furthermore, if
the table uses REPLICA IDENTITY FULL, column list is not allowed.
The column list can contain only simple column references. Complex
expressions, function calls etc. are not allowed. This restriction could
be relaxed in the future.
During the initial table synchronization, only columns included in the
column list are copied to the subscriber. If the subscription has
several publications, containing the same table with different column
lists, columns specified in any of the lists will be copied.
This means all columns are replicated if the table has no column list
at all (which is treated as column list with all columns), or when of
the publications is defined as FOR ALL TABLES (possibly IN SCHEMA that
matches the schema of the table).
For partitioned tables, publish_via_partition_root determines whether
the column list for the root or the leaf relation will be used. If the
parameter is 'false' (the default), the list defined for the leaf
relation is used. Otherwise, the column list for the root partition
will be used.
Psql commands \dRp+ and \d <table-name> now display any column lists.
Author: Tomas Vondra, Alvaro Herrera, Rahila Syed
Reviewed-by: Peter Eisentraut, Alvaro Herrera, Vignesh C, Ibrar Ahmed,
Amit Kapila, Hou zj, Peter Smith, Wang wei, Tang, Shi yu
Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektNRH8NJ1jf95g@mail.gmail.com
2022-03-26 00:45:21 +01:00
|
|
|
$$->pubtable->columns = $2;
|
|
|
|
|
$$->pubtable->whereClause = $3;
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
}
|
|
|
|
|
| CURRENT_SCHEMA
|
|
|
|
|
{
|
|
|
|
|
$$ = makeNode(PublicationObjSpec);
|
|
|
|
|
$$->pubobjtype = PUBLICATIONOBJ_CONTINUATION;
|
|
|
|
|
$$->location = @1;
|
|
|
|
|
}
|
|
|
|
|
;
|
2017-01-19 18:00:00 +01:00
|
|
|
|
2022-05-13 07:17:29 +02:00
|
|
|
pub_obj_list: PublicationObjSpec
|
2021-09-06 19:24:50 +02:00
|
|
|
{ $$ = list_make1($1); }
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
| pub_obj_list ',' PublicationObjSpec
|
|
|
|
|
{ $$ = lappend($1, $3); }
|
2021-09-06 19:24:50 +02:00
|
|
|
;
|
2017-05-12 14:57:01 +02:00
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2017-05-12 14:57:01 +02:00
|
|
|
* ALTER PUBLICATION name SET ( options )
|
2017-01-19 18:00:00 +01:00
|
|
|
*
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
* ALTER PUBLICATION name ADD pub_obj [, ...]
|
|
|
|
|
*
|
|
|
|
|
* ALTER PUBLICATION name DROP pub_obj [, ...]
|
|
|
|
|
*
|
|
|
|
|
* ALTER PUBLICATION name SET pub_obj [, ...]
|
2017-01-19 18:00:00 +01:00
|
|
|
*
|
2022-04-07 18:13:13 +02:00
|
|
|
* pub_obj is one of:
|
|
|
|
|
*
|
|
|
|
|
* TABLE table_name [, ...]
|
2022-09-22 19:02:25 +02:00
|
|
|
* TABLES IN SCHEMA schema_name [, ...]
|
2022-04-07 18:13:13 +02:00
|
|
|
*
|
2017-01-19 18:00:00 +01:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
AlterPublicationStmt:
|
2017-05-12 14:57:01 +02:00
|
|
|
ALTER PUBLICATION name SET definition
|
2017-01-19 18:00:00 +01:00
|
|
|
{
|
|
|
|
|
AlterPublicationStmt *n = makeNode(AlterPublicationStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
n->pubname = $3;
|
|
|
|
|
n->options = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
| ALTER PUBLICATION name ADD_P pub_obj_list
|
2017-01-19 18:00:00 +01:00
|
|
|
{
|
|
|
|
|
AlterPublicationStmt *n = makeNode(AlterPublicationStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
n->pubname = $3;
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
n->pubobjects = $5;
|
|
|
|
|
preprocess_pubobj_list(n->pubobjects, yyscanner);
|
2022-01-03 14:48:48 +01:00
|
|
|
n->action = AP_AddObjects;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
| ALTER PUBLICATION name SET pub_obj_list
|
2017-01-19 18:00:00 +01:00
|
|
|
{
|
|
|
|
|
AlterPublicationStmt *n = makeNode(AlterPublicationStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
n->pubname = $3;
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
n->pubobjects = $5;
|
|
|
|
|
preprocess_pubobj_list(n->pubobjects, yyscanner);
|
2022-01-03 14:48:48 +01:00
|
|
|
n->action = AP_SetObjects;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
| ALTER PUBLICATION name DROP pub_obj_list
|
2017-01-19 18:00:00 +01:00
|
|
|
{
|
|
|
|
|
AlterPublicationStmt *n = makeNode(AlterPublicationStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
n->pubname = $3;
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
n->pubobjects = $5;
|
|
|
|
|
preprocess_pubobj_list(n->pubobjects, yyscanner);
|
2022-01-03 14:48:48 +01:00
|
|
|
n->action = AP_DropObjects;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* CREATE SUBSCRIPTION name ...
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
CreateSubscriptionStmt:
|
2020-12-04 11:09:29 +01:00
|
|
|
CREATE SUBSCRIPTION name CONNECTION Sconst PUBLICATION name_list opt_definition
|
2017-01-19 18:00:00 +01:00
|
|
|
{
|
|
|
|
|
CreateSubscriptionStmt *n =
|
|
|
|
|
makeNode(CreateSubscriptionStmt);
|
|
|
|
|
n->subname = $3;
|
|
|
|
|
n->conninfo = $5;
|
|
|
|
|
n->publication = $7;
|
|
|
|
|
n->options = $8;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2017-05-12 14:57:01 +02:00
|
|
|
* ALTER SUBSCRIPTION name ...
|
2017-01-19 18:00:00 +01:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
AlterSubscriptionStmt:
|
2017-05-12 14:57:01 +02:00
|
|
|
ALTER SUBSCRIPTION name SET definition
|
2017-01-19 18:00:00 +01:00
|
|
|
{
|
|
|
|
|
AlterSubscriptionStmt *n =
|
|
|
|
|
makeNode(AlterSubscriptionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-03-23 13:36:36 +01:00
|
|
|
n->kind = ALTER_SUBSCRIPTION_OPTIONS;
|
2017-01-19 18:00:00 +01:00
|
|
|
n->subname = $3;
|
|
|
|
|
n->options = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
|
|
|
|
| ALTER SUBSCRIPTION name CONNECTION Sconst
|
|
|
|
|
{
|
|
|
|
|
AlterSubscriptionStmt *n =
|
|
|
|
|
makeNode(AlterSubscriptionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-03-23 13:36:36 +01:00
|
|
|
n->kind = ALTER_SUBSCRIPTION_CONNECTION;
|
2017-01-19 18:00:00 +01:00
|
|
|
n->subname = $3;
|
2017-03-23 13:36:36 +01:00
|
|
|
n->conninfo = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-03-23 13:36:36 +01:00
|
|
|
}
|
|
|
|
|
| ALTER SUBSCRIPTION name REFRESH PUBLICATION opt_definition
|
|
|
|
|
{
|
|
|
|
|
AlterSubscriptionStmt *n =
|
|
|
|
|
makeNode(AlterSubscriptionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-03-23 13:36:36 +01:00
|
|
|
n->kind = ALTER_SUBSCRIPTION_REFRESH;
|
|
|
|
|
n->subname = $3;
|
|
|
|
|
n->options = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-03-23 13:36:36 +01:00
|
|
|
}
|
2021-04-06 10:44:26 +02:00
|
|
|
| ALTER SUBSCRIPTION name ADD_P PUBLICATION name_list opt_definition
|
|
|
|
|
{
|
|
|
|
|
AlterSubscriptionStmt *n =
|
|
|
|
|
makeNode(AlterSubscriptionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-04-06 10:44:26 +02:00
|
|
|
n->kind = ALTER_SUBSCRIPTION_ADD_PUBLICATION;
|
|
|
|
|
n->subname = $3;
|
|
|
|
|
n->publication = $6;
|
|
|
|
|
n->options = $7;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2021-04-06 10:44:26 +02:00
|
|
|
}
|
|
|
|
|
| ALTER SUBSCRIPTION name DROP PUBLICATION name_list opt_definition
|
|
|
|
|
{
|
|
|
|
|
AlterSubscriptionStmt *n =
|
|
|
|
|
makeNode(AlterSubscriptionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-04-06 10:44:26 +02:00
|
|
|
n->kind = ALTER_SUBSCRIPTION_DROP_PUBLICATION;
|
|
|
|
|
n->subname = $3;
|
|
|
|
|
n->publication = $6;
|
|
|
|
|
n->options = $7;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2021-04-06 10:44:26 +02:00
|
|
|
}
|
2020-12-04 11:09:29 +01:00
|
|
|
| ALTER SUBSCRIPTION name SET PUBLICATION name_list opt_definition
|
2017-01-19 18:00:00 +01:00
|
|
|
{
|
|
|
|
|
AlterSubscriptionStmt *n =
|
|
|
|
|
makeNode(AlterSubscriptionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-04-06 10:44:26 +02:00
|
|
|
n->kind = ALTER_SUBSCRIPTION_SET_PUBLICATION;
|
2017-01-19 18:00:00 +01:00
|
|
|
n->subname = $3;
|
2017-03-23 13:36:36 +01:00
|
|
|
n->publication = $6;
|
2017-06-06 03:37:00 +02:00
|
|
|
n->options = $7;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
|
|
|
|
| ALTER SUBSCRIPTION name ENABLE_P
|
|
|
|
|
{
|
|
|
|
|
AlterSubscriptionStmt *n =
|
|
|
|
|
makeNode(AlterSubscriptionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-03-23 13:36:36 +01:00
|
|
|
n->kind = ALTER_SUBSCRIPTION_ENABLED;
|
2017-01-19 18:00:00 +01:00
|
|
|
n->subname = $3;
|
|
|
|
|
n->options = list_make1(makeDefElem("enabled",
|
2022-05-13 07:17:29 +02:00
|
|
|
(Node *) makeBoolean(true), @1));
|
|
|
|
|
$$ = (Node *) n;
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
|
|
|
|
| ALTER SUBSCRIPTION name DISABLE_P
|
|
|
|
|
{
|
|
|
|
|
AlterSubscriptionStmt *n =
|
|
|
|
|
makeNode(AlterSubscriptionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-03-23 13:36:36 +01:00
|
|
|
n->kind = ALTER_SUBSCRIPTION_ENABLED;
|
2017-01-19 18:00:00 +01:00
|
|
|
n->subname = $3;
|
|
|
|
|
n->options = list_make1(makeDefElem("enabled",
|
2022-05-13 07:17:29 +02:00
|
|
|
(Node *) makeBoolean(false), @1));
|
|
|
|
|
$$ = (Node *) n;
|
2017-03-23 13:36:36 +01:00
|
|
|
}
|
Add ALTER SUBSCRIPTION ... SKIP.
This feature allows skipping the transaction on subscriber nodes.
If incoming change violates any constraint, logical replication stops
until it's resolved. Currently, users need to either manually resolve the
conflict by updating a subscriber-side database or by using function
pg_replication_origin_advance() to skip the conflicting transaction. This
commit introduces a simpler way to skip the conflicting transactions.
The user can specify LSN by ALTER SUBSCRIPTION ... SKIP (lsn = XXX),
which allows the apply worker to skip the transaction finished at
specified LSN. The apply worker skips all data modification changes within
the transaction.
Author: Masahiko Sawada
Reviewed-by: Takamichi Osumi, Hou Zhijie, Peter Eisentraut, Amit Kapila, Shi Yu, Vignesh C, Greg Nancarrow, Haiying Tang, Euler Taveira
Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2022-03-22 02:41:19 +01:00
|
|
|
| ALTER SUBSCRIPTION name SKIP definition
|
|
|
|
|
{
|
|
|
|
|
AlterSubscriptionStmt *n =
|
|
|
|
|
makeNode(AlterSubscriptionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Add ALTER SUBSCRIPTION ... SKIP.
This feature allows skipping the transaction on subscriber nodes.
If incoming change violates any constraint, logical replication stops
until it's resolved. Currently, users need to either manually resolve the
conflict by updating a subscriber-side database or by using function
pg_replication_origin_advance() to skip the conflicting transaction. This
commit introduces a simpler way to skip the conflicting transactions.
The user can specify LSN by ALTER SUBSCRIPTION ... SKIP (lsn = XXX),
which allows the apply worker to skip the transaction finished at
specified LSN. The apply worker skips all data modification changes within
the transaction.
Author: Masahiko Sawada
Reviewed-by: Takamichi Osumi, Hou Zhijie, Peter Eisentraut, Amit Kapila, Shi Yu, Vignesh C, Greg Nancarrow, Haiying Tang, Euler Taveira
Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2022-03-22 02:41:19 +01:00
|
|
|
n->kind = ALTER_SUBSCRIPTION_SKIP;
|
|
|
|
|
n->subname = $3;
|
|
|
|
|
n->options = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Add ALTER SUBSCRIPTION ... SKIP.
This feature allows skipping the transaction on subscriber nodes.
If incoming change violates any constraint, logical replication stops
until it's resolved. Currently, users need to either manually resolve the
conflict by updating a subscriber-side database or by using function
pg_replication_origin_advance() to skip the conflicting transaction. This
commit introduces a simpler way to skip the conflicting transactions.
The user can specify LSN by ALTER SUBSCRIPTION ... SKIP (lsn = XXX),
which allows the apply worker to skip the transaction finished at
specified LSN. The apply worker skips all data modification changes within
the transaction.
Author: Masahiko Sawada
Reviewed-by: Takamichi Osumi, Hou Zhijie, Peter Eisentraut, Amit Kapila, Shi Yu, Vignesh C, Greg Nancarrow, Haiying Tang, Euler Taveira
Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2022-03-22 02:41:19 +01:00
|
|
|
}
|
2017-03-23 13:36:36 +01:00
|
|
|
;
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* DROP SUBSCRIPTION [ IF EXISTS ] name
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2017-05-09 16:20:42 +02:00
|
|
|
DropSubscriptionStmt: DROP SUBSCRIPTION name opt_drop_behavior
|
2017-01-19 18:00:00 +01:00
|
|
|
{
|
|
|
|
|
DropSubscriptionStmt *n = makeNode(DropSubscriptionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
n->subname = $3;
|
|
|
|
|
n->missing_ok = false;
|
2017-05-09 16:20:42 +02:00
|
|
|
n->behavior = $4;
|
2017-01-19 18:00:00 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2017-05-09 16:20:42 +02:00
|
|
|
| DROP SUBSCRIPTION IF_P EXISTS name opt_drop_behavior
|
2017-01-19 18:00:00 +01:00
|
|
|
{
|
|
|
|
|
DropSubscriptionStmt *n = makeNode(DropSubscriptionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
n->subname = $5;
|
|
|
|
|
n->missing_ok = true;
|
2017-05-09 16:20:42 +02:00
|
|
|
n->behavior = $6;
|
2017-01-19 18:00:00 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
1997-09-01 08:00:35 +02:00
|
|
|
*
|
2002-03-21 17:02:16 +01:00
|
|
|
* QUERY: Define Rewrite Rule
|
1997-09-01 08:00:35 +02:00
|
|
|
*
|
1996-07-09 08:22:35 +02:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-09-02 04:13:02 +02:00
|
|
|
RuleStmt: CREATE opt_or_replace RULE name AS
|
2002-04-21 21:21:49 +02:00
|
|
|
ON event TO qualified_name where_clause
|
|
|
|
|
DO opt_instead RuleActionList
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
RuleStmt *n = makeNode(RuleStmt);
|
|
|
|
|
|
2002-09-02 04:13:02 +02:00
|
|
|
n->replace = $2;
|
2009-11-06 00:24:27 +01:00
|
|
|
n->relation = $9;
|
2002-09-02 04:13:02 +02:00
|
|
|
n->rulename = $4;
|
2009-11-06 00:24:27 +01:00
|
|
|
n->whereClause = $10;
|
|
|
|
|
n->event = $7;
|
|
|
|
|
n->instead = $12;
|
|
|
|
|
n->actions = $13;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
RuleActionList:
|
|
|
|
|
NOTHING { $$ = NIL; }
|
2004-05-31 01:40:41 +02:00
|
|
|
| RuleActionStmt { $$ = list_make1($1); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| '(' RuleActionMulti ')' { $$ = $2; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1997-09-01 08:00:35 +02:00
|
|
|
|
1999-10-07 06:23:24 +02:00
|
|
|
/* the thrashing around here is to discard "empty" statements... */
|
2002-06-17 22:27:43 +02:00
|
|
|
RuleActionMulti:
|
|
|
|
|
RuleActionMulti ';' RuleActionStmtOrEmpty
|
2004-01-07 19:56:30 +01:00
|
|
|
{ if ($3 != NULL)
|
2000-10-28 21:41:00 +02:00
|
|
|
$$ = lappend($1, $3);
|
1999-10-07 06:23:24 +02:00
|
|
|
else
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| RuleActionStmtOrEmpty
|
2004-01-07 19:56:30 +01:00
|
|
|
{ if ($1 != NULL)
|
2004-05-31 01:40:41 +02:00
|
|
|
$$ = list_make1($1);
|
1999-10-07 06:23:24 +02:00
|
|
|
else
|
|
|
|
|
$$ = NIL;
|
|
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1997-09-01 08:00:35 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
RuleActionStmt:
|
|
|
|
|
SelectStmt
|
|
|
|
|
| InsertStmt
|
|
|
|
|
| UpdateStmt
|
|
|
|
|
| DeleteStmt
|
|
|
|
|
| NotifyStmt
|
1999-02-07 20:02:20 +01:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
RuleActionStmtOrEmpty:
|
|
|
|
|
RuleActionStmt { $$ = $1; }
|
2004-01-07 19:56:30 +01:00
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
1999-10-07 06:23:24 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
event: SELECT { $$ = CMD_SELECT; }
|
|
|
|
|
| UPDATE { $$ = CMD_UPDATE; }
|
|
|
|
|
| DELETE_P { $$ = CMD_DELETE; }
|
|
|
|
|
| INSERT { $$ = CMD_INSERT; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
opt_instead:
|
2017-08-16 06:22:32 +02:00
|
|
|
INSTEAD { $$ = true; }
|
|
|
|
|
| ALSO { $$ = false; }
|
|
|
|
|
| /*EMPTY*/ { $$ = false; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* QUERY:
|
2008-09-01 22:42:46 +02:00
|
|
|
* NOTIFY <identifier> can appear both in rule bodies and
|
1997-09-08 05:20:18 +02:00
|
|
|
* as a query-level command
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2010-02-16 23:34:57 +01:00
|
|
|
NotifyStmt: NOTIFY ColId notify_payload
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
|
|
|
|
NotifyStmt *n = makeNode(NotifyStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-09-01 22:42:46 +02:00
|
|
|
n->conditionname = $2;
|
2010-02-16 23:34:57 +01:00
|
|
|
n->payload = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
|
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2010-02-16 23:34:57 +01:00
|
|
|
notify_payload:
|
|
|
|
|
',' Sconst { $$ = $2; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
2007-04-03 00:20:53 +02:00
|
|
|
ListenStmt: LISTEN ColId
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
|
|
|
|
ListenStmt *n = makeNode(ListenStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-09-01 22:42:46 +02:00
|
|
|
n->conditionname = $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2002-03-21 17:02:16 +01:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
UnlistenStmt:
|
2007-04-03 00:20:53 +02:00
|
|
|
UNLISTEN ColId
|
1998-08-25 23:37:08 +02:00
|
|
|
{
|
|
|
|
|
UnlistenStmt *n = makeNode(UnlistenStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-09-01 22:42:46 +02:00
|
|
|
n->conditionname = $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1998-08-25 23:37:08 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| UNLISTEN '*'
|
1998-10-09 09:06:37 +02:00
|
|
|
{
|
|
|
|
|
UnlistenStmt *n = makeNode(UnlistenStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-09-01 22:42:46 +02:00
|
|
|
n->conditionname = NULL;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1998-10-09 09:06:37 +02:00
|
|
|
}
|
2002-03-21 17:02:16 +01:00
|
|
|
;
|
1998-08-25 23:37:08 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* Transactions:
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2002-06-17 22:27:43 +02:00
|
|
|
* BEGIN / COMMIT / ROLLBACK
|
|
|
|
|
* (also older versions END / ABORT)
|
1997-09-01 08:00:35 +02:00
|
|
|
*
|
1996-07-09 08:22:35 +02:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
TransactionStmt:
|
2019-03-24 10:33:14 +01:00
|
|
|
ABORT_P opt_transaction opt_transaction_chain
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
|
|
|
|
TransactionStmt *n = makeNode(TransactionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-02-10 05:44:47 +01:00
|
|
|
n->kind = TRANS_STMT_ROLLBACK;
|
2002-08-04 06:31:44 +02:00
|
|
|
n->options = NIL;
|
2019-03-24 10:33:14 +01:00
|
|
|
n->chain = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2020-04-08 10:37:27 +02:00
|
|
|
| START TRANSACTION transaction_mode_list_or_empty
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
|
|
|
|
TransactionStmt *n = makeNode(TransactionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-02-10 05:44:47 +01:00
|
|
|
n->kind = TRANS_STMT_START;
|
2002-08-04 06:31:44 +02:00
|
|
|
n->options = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2019-03-24 10:33:14 +01:00
|
|
|
| COMMIT opt_transaction opt_transaction_chain
|
2000-08-06 20:06:44 +02:00
|
|
|
{
|
|
|
|
|
TransactionStmt *n = makeNode(TransactionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-02-10 05:44:47 +01:00
|
|
|
n->kind = TRANS_STMT_COMMIT;
|
2002-08-04 06:31:44 +02:00
|
|
|
n->options = NIL;
|
2019-03-24 10:33:14 +01:00
|
|
|
n->chain = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-08-06 20:06:44 +02:00
|
|
|
}
|
2019-03-24 10:33:14 +01:00
|
|
|
| ROLLBACK opt_transaction opt_transaction_chain
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
|
|
|
|
TransactionStmt *n = makeNode(TransactionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-02-10 05:44:47 +01:00
|
|
|
n->kind = TRANS_STMT_ROLLBACK;
|
2002-08-04 06:31:44 +02:00
|
|
|
n->options = NIL;
|
2019-03-24 10:33:14 +01:00
|
|
|
n->chain = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-08-06 20:06:44 +02:00
|
|
|
}
|
2004-07-27 07:11:48 +02:00
|
|
|
| SAVEPOINT ColId
|
|
|
|
|
{
|
|
|
|
|
TransactionStmt *n = makeNode(TransactionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-07-27 07:11:48 +02:00
|
|
|
n->kind = TRANS_STMT_SAVEPOINT;
|
2018-02-17 02:57:06 +01:00
|
|
|
n->savepoint_name = $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-07-27 07:11:48 +02:00
|
|
|
}
|
2004-08-12 21:12:21 +02:00
|
|
|
| RELEASE SAVEPOINT ColId
|
|
|
|
|
{
|
|
|
|
|
TransactionStmt *n = makeNode(TransactionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-08-12 21:12:21 +02:00
|
|
|
n->kind = TRANS_STMT_RELEASE;
|
2018-02-17 02:57:06 +01:00
|
|
|
n->savepoint_name = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-08-12 21:12:21 +02:00
|
|
|
}
|
2004-07-27 07:11:48 +02:00
|
|
|
| RELEASE ColId
|
|
|
|
|
{
|
|
|
|
|
TransactionStmt *n = makeNode(TransactionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-07-27 07:11:48 +02:00
|
|
|
n->kind = TRANS_STMT_RELEASE;
|
2018-02-17 02:57:06 +01:00
|
|
|
n->savepoint_name = $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-07-27 07:11:48 +02:00
|
|
|
}
|
2004-08-12 21:12:21 +02:00
|
|
|
| ROLLBACK opt_transaction TO SAVEPOINT ColId
|
2004-07-27 07:11:48 +02:00
|
|
|
{
|
|
|
|
|
TransactionStmt *n = makeNode(TransactionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-07-27 07:11:48 +02:00
|
|
|
n->kind = TRANS_STMT_ROLLBACK_TO;
|
2018-02-17 02:57:06 +01:00
|
|
|
n->savepoint_name = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-08-12 21:12:21 +02:00
|
|
|
}
|
|
|
|
|
| ROLLBACK opt_transaction TO ColId
|
|
|
|
|
{
|
|
|
|
|
TransactionStmt *n = makeNode(TransactionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-08-12 21:12:21 +02:00
|
|
|
n->kind = TRANS_STMT_ROLLBACK_TO;
|
2018-02-17 02:57:06 +01:00
|
|
|
n->savepoint_name = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-07-27 07:11:48 +02:00
|
|
|
}
|
2005-06-18 00:32:51 +02:00
|
|
|
| PREPARE TRANSACTION Sconst
|
|
|
|
|
{
|
|
|
|
|
TransactionStmt *n = makeNode(TransactionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-06-18 00:32:51 +02:00
|
|
|
n->kind = TRANS_STMT_PREPARE;
|
|
|
|
|
n->gid = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-06-18 00:32:51 +02:00
|
|
|
}
|
|
|
|
|
| COMMIT PREPARED Sconst
|
|
|
|
|
{
|
|
|
|
|
TransactionStmt *n = makeNode(TransactionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-06-18 00:32:51 +02:00
|
|
|
n->kind = TRANS_STMT_COMMIT_PREPARED;
|
|
|
|
|
n->gid = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-06-18 00:32:51 +02:00
|
|
|
}
|
|
|
|
|
| ROLLBACK PREPARED Sconst
|
|
|
|
|
{
|
|
|
|
|
TransactionStmt *n = makeNode(TransactionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-06-18 00:32:51 +02:00
|
|
|
n->kind = TRANS_STMT_ROLLBACK_PREPARED;
|
|
|
|
|
n->gid = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-06-18 00:32:51 +02:00
|
|
|
}
|
1998-07-25 02:17:30 +02:00
|
|
|
;
|
1997-09-08 05:20:18 +02:00
|
|
|
|
2021-04-07 21:30:08 +02:00
|
|
|
TransactionStmtLegacy:
|
|
|
|
|
BEGIN_P opt_transaction transaction_mode_list_or_empty
|
|
|
|
|
{
|
|
|
|
|
TransactionStmt *n = makeNode(TransactionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-04-07 21:30:08 +02:00
|
|
|
n->kind = TRANS_STMT_BEGIN;
|
|
|
|
|
n->options = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2021-04-07 21:30:08 +02:00
|
|
|
}
|
|
|
|
|
| END_P opt_transaction opt_transaction_chain
|
|
|
|
|
{
|
|
|
|
|
TransactionStmt *n = makeNode(TransactionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-04-07 21:30:08 +02:00
|
|
|
n->kind = TRANS_STMT_COMMIT;
|
|
|
|
|
n->options = NIL;
|
|
|
|
|
n->chain = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2021-04-07 21:30:08 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2020-11-12 07:48:36 +01:00
|
|
|
opt_transaction: WORK
|
|
|
|
|
| TRANSACTION
|
|
|
|
|
| /*EMPTY*/
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2004-08-12 23:00:34 +02:00
|
|
|
transaction_mode_item:
|
2003-01-10 23:03:30 +01:00
|
|
|
ISOLATION LEVEL iso_level
|
2004-08-12 23:00:34 +02:00
|
|
|
{ $$ = makeDefElem("transaction_isolation",
|
2016-09-06 18:00:00 +02:00
|
|
|
makeStringConst($3, @3), @1); }
|
2004-08-12 23:00:34 +02:00
|
|
|
| READ ONLY
|
|
|
|
|
{ $$ = makeDefElem("transaction_read_only",
|
2017-08-16 06:22:32 +02:00
|
|
|
makeIntConst(true, @1), @1); }
|
2004-08-12 23:00:34 +02:00
|
|
|
| READ WRITE
|
|
|
|
|
{ $$ = makeDefElem("transaction_read_only",
|
2017-08-16 06:22:32 +02:00
|
|
|
makeIntConst(false, @1), @1); }
|
Implement genuine serializable isolation level.
Until now, our Serializable mode has in fact been what's called Snapshot
Isolation, which allows some anomalies that could not occur in any
serialized ordering of the transactions. This patch fixes that using a
method called Serializable Snapshot Isolation, based on research papers by
Michael J. Cahill (see README-SSI for full references). In Serializable
Snapshot Isolation, transactions run like they do in Snapshot Isolation,
but a predicate lock manager observes the reads and writes performed and
aborts transactions if it detects that an anomaly might occur. This method
produces some false positives, ie. it sometimes aborts transactions even
though there is no anomaly.
To track reads we implement predicate locking, see storage/lmgr/predicate.c.
Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared
memory is finite, so when a transaction takes many tuple-level locks on a
page, the locks are promoted to a single page-level lock, and further to a
single relation level lock if necessary. To lock key values with no matching
tuple, a sequential scan always takes a relation-level lock, and an index
scan acquires a page-level lock that covers the search key, whether or not
there are any matching keys at the moment.
A predicate lock doesn't conflict with any regular locks or with another
predicate locks in the normal sense. They're only used by the predicate lock
manager to detect the danger of anomalies. Only serializable transactions
participate in predicate locking, so there should be no extra overhead for
for other transactions.
Predicate locks can't be released at commit, but must be remembered until
all the transactions that overlapped with it have completed. That means that
we need to remember an unbounded amount of predicate locks, so we apply a
lossy but conservative method of tracking locks for committed transactions.
If we run short of shared memory, we overflow to a new "pg_serial" SLRU
pool.
We don't currently allow Serializable transactions in Hot Standby mode.
That would be hard, because even read-only transactions can cause anomalies
that wouldn't otherwise occur.
Serializable isolation mode now means the new fully serializable level.
Repeatable Read gives you the old Snapshot Isolation level that we have
always had.
Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and
Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
|
|
|
| DEFERRABLE
|
|
|
|
|
{ $$ = makeDefElem("transaction_deferrable",
|
2017-08-16 06:22:32 +02:00
|
|
|
makeIntConst(true, @1), @1); }
|
Implement genuine serializable isolation level.
Until now, our Serializable mode has in fact been what's called Snapshot
Isolation, which allows some anomalies that could not occur in any
serialized ordering of the transactions. This patch fixes that using a
method called Serializable Snapshot Isolation, based on research papers by
Michael J. Cahill (see README-SSI for full references). In Serializable
Snapshot Isolation, transactions run like they do in Snapshot Isolation,
but a predicate lock manager observes the reads and writes performed and
aborts transactions if it detects that an anomaly might occur. This method
produces some false positives, ie. it sometimes aborts transactions even
though there is no anomaly.
To track reads we implement predicate locking, see storage/lmgr/predicate.c.
Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared
memory is finite, so when a transaction takes many tuple-level locks on a
page, the locks are promoted to a single page-level lock, and further to a
single relation level lock if necessary. To lock key values with no matching
tuple, a sequential scan always takes a relation-level lock, and an index
scan acquires a page-level lock that covers the search key, whether or not
there are any matching keys at the moment.
A predicate lock doesn't conflict with any regular locks or with another
predicate locks in the normal sense. They're only used by the predicate lock
manager to detect the danger of anomalies. Only serializable transactions
participate in predicate locking, so there should be no extra overhead for
for other transactions.
Predicate locks can't be released at commit, but must be remembered until
all the transactions that overlapped with it have completed. That means that
we need to remember an unbounded amount of predicate locks, so we apply a
lossy but conservative method of tracking locks for committed transactions.
If we run short of shared memory, we overflow to a new "pg_serial" SLRU
pool.
We don't currently allow Serializable transactions in Hot Standby mode.
That would be hard, because even read-only transactions can cause anomalies
that wouldn't otherwise occur.
Serializable isolation mode now means the new fully serializable level.
Repeatable Read gives you the old Snapshot Isolation level that we have
always had.
Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and
Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
|
|
|
| NOT DEFERRABLE
|
|
|
|
|
{ $$ = makeDefElem("transaction_deferrable",
|
2017-08-16 06:22:32 +02:00
|
|
|
makeIntConst(false, @1), @1); }
|
2004-08-12 23:00:34 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/* Syntax with commas is SQL-spec, without commas is Postgres historical */
|
|
|
|
|
transaction_mode_list:
|
|
|
|
|
transaction_mode_item
|
|
|
|
|
{ $$ = list_make1($1); }
|
|
|
|
|
| transaction_mode_list ',' transaction_mode_item
|
|
|
|
|
{ $$ = lappend($1, $3); }
|
|
|
|
|
| transaction_mode_list transaction_mode_item
|
|
|
|
|
{ $$ = lappend($1, $2); }
|
2003-01-10 23:03:30 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
transaction_mode_list_or_empty:
|
|
|
|
|
transaction_mode_list
|
|
|
|
|
| /* EMPTY */
|
|
|
|
|
{ $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
2019-03-24 10:33:14 +01:00
|
|
|
opt_transaction_chain:
|
|
|
|
|
AND CHAIN { $$ = true; }
|
|
|
|
|
| AND NO CHAIN { $$ = false; }
|
|
|
|
|
| /* EMPTY */ { $$ = false; }
|
|
|
|
|
;
|
|
|
|
|
|
2003-01-10 23:03:30 +01:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2005-02-02 07:36:02 +01:00
|
|
|
* QUERY:
|
2006-05-27 19:38:46 +02:00
|
|
|
* CREATE [ OR REPLACE ] [ TEMP ] VIEW <viewname> '('target-list ')'
|
|
|
|
|
* AS <query> [ WITH [ CASCADED | LOCAL ] CHECK OPTION ]
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2011-12-22 22:15:57 +01:00
|
|
|
ViewStmt: CREATE OptTemp VIEW qualified_name opt_column_list opt_reloptions
|
2006-05-27 19:38:46 +02:00
|
|
|
AS SelectStmt opt_check_option
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
ViewStmt *n = makeNode(ViewStmt);
|
|
|
|
|
|
2002-09-02 04:13:02 +02:00
|
|
|
n->view = $4;
|
2010-12-13 18:34:26 +01:00
|
|
|
n->view->relpersistence = $2;
|
2002-09-02 04:13:02 +02:00
|
|
|
n->aliases = $5;
|
2011-12-22 22:15:57 +01:00
|
|
|
n->query = $8;
|
2007-03-13 01:33:44 +01:00
|
|
|
n->replace = false;
|
2011-12-22 22:15:57 +01:00
|
|
|
n->options = $6;
|
2013-07-18 23:10:16 +02:00
|
|
|
n->withCheckOption = $9;
|
2005-02-02 07:36:02 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2011-12-22 22:15:57 +01:00
|
|
|
| CREATE OR REPLACE OptTemp VIEW qualified_name opt_column_list opt_reloptions
|
2006-05-27 19:38:46 +02:00
|
|
|
AS SelectStmt opt_check_option
|
2005-02-02 07:36:02 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
ViewStmt *n = makeNode(ViewStmt);
|
|
|
|
|
|
2005-02-02 07:36:02 +01:00
|
|
|
n->view = $6;
|
2010-12-13 18:34:26 +01:00
|
|
|
n->view->relpersistence = $4;
|
2005-02-02 07:36:02 +01:00
|
|
|
n->aliases = $7;
|
2011-12-22 22:15:57 +01:00
|
|
|
n->query = $10;
|
2007-03-13 01:33:44 +01:00
|
|
|
n->replace = true;
|
2011-12-22 22:15:57 +01:00
|
|
|
n->options = $8;
|
2013-07-18 23:10:16 +02:00
|
|
|
n->withCheckOption = $11;
|
2005-02-02 07:36:02 +01:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2013-02-01 04:31:58 +01:00
|
|
|
| CREATE OptTemp RECURSIVE VIEW qualified_name '(' columnList ')' opt_reloptions
|
2013-07-18 23:10:16 +02:00
|
|
|
AS SelectStmt opt_check_option
|
2013-02-01 04:31:58 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
ViewStmt *n = makeNode(ViewStmt);
|
|
|
|
|
|
2013-02-01 04:31:58 +01:00
|
|
|
n->view = $5;
|
|
|
|
|
n->view->relpersistence = $2;
|
|
|
|
|
n->aliases = $7;
|
|
|
|
|
n->query = makeRecursiveViewSelect(n->view->relname, n->aliases, $11);
|
|
|
|
|
n->replace = false;
|
|
|
|
|
n->options = $9;
|
2013-07-18 23:10:16 +02:00
|
|
|
n->withCheckOption = $12;
|
|
|
|
|
if (n->withCheckOption != NO_CHECK_OPTION)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
|
errmsg("WITH CHECK OPTION not supported on recursive views"),
|
|
|
|
|
parser_errposition(@12)));
|
2013-02-01 04:31:58 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| CREATE OR REPLACE OptTemp RECURSIVE VIEW qualified_name '(' columnList ')' opt_reloptions
|
2013-07-18 23:10:16 +02:00
|
|
|
AS SelectStmt opt_check_option
|
2013-02-01 04:31:58 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
ViewStmt *n = makeNode(ViewStmt);
|
|
|
|
|
|
2013-02-01 04:31:58 +01:00
|
|
|
n->view = $7;
|
|
|
|
|
n->view->relpersistence = $4;
|
|
|
|
|
n->aliases = $9;
|
|
|
|
|
n->query = makeRecursiveViewSelect(n->view->relname, n->aliases, $13);
|
|
|
|
|
n->replace = true;
|
|
|
|
|
n->options = $11;
|
2013-07-18 23:10:16 +02:00
|
|
|
n->withCheckOption = $14;
|
|
|
|
|
if (n->withCheckOption != NO_CHECK_OPTION)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
|
errmsg("WITH CHECK OPTION not supported on recursive views"),
|
|
|
|
|
parser_errposition(@14)));
|
2013-02-01 04:31:58 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2006-05-27 19:38:46 +02:00
|
|
|
opt_check_option:
|
2013-07-18 23:10:16 +02:00
|
|
|
WITH CHECK OPTION { $$ = CASCADED_CHECK_OPTION; }
|
|
|
|
|
| WITH CASCADED CHECK OPTION { $$ = CASCADED_CHECK_OPTION; }
|
|
|
|
|
| WITH LOCAL CHECK OPTION { $$ = LOCAL_CHECK_OPTION; }
|
|
|
|
|
| /* EMPTY */ { $$ = NO_CHECK_OPTION; }
|
2006-05-27 19:38:46 +02:00
|
|
|
;
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* QUERY:
|
2007-04-08 02:26:34 +02:00
|
|
|
* LOAD "filename"
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
LoadStmt: LOAD file_name
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
LoadStmt *n = makeNode(LoadStmt);
|
|
|
|
|
|
1997-09-08 05:20:18 +02:00
|
|
|
n->filename = $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
|
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2000-01-13 19:26:18 +01:00
|
|
|
* CREATE DATABASE
|
|
|
|
|
*
|
1996-07-09 08:22:35 +02:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
CreatedbStmt:
|
2020-06-10 22:58:46 +02:00
|
|
|
CREATE DATABASE name opt_with createdb_opt_list
|
2000-08-06 20:06:44 +02:00
|
|
|
{
|
2000-10-25 20:56:16 +02:00
|
|
|
CreatedbStmt *n = makeNode(CreatedbStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
1997-09-08 05:20:18 +02:00
|
|
|
n->dbname = $3;
|
2002-06-18 19:27:58 +02:00
|
|
|
n->options = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
1998-07-24 05:32:46 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
createdb_opt_list:
|
2014-07-02 01:02:21 +02:00
|
|
|
createdb_opt_items { $$ = $1; }
|
2002-06-18 02:28:11 +02:00
|
|
|
| /* EMPTY */ { $$ = NIL; }
|
1997-11-07 08:02:10 +01:00
|
|
|
;
|
|
|
|
|
|
2014-07-02 01:02:21 +02:00
|
|
|
createdb_opt_items:
|
|
|
|
|
createdb_opt_item { $$ = list_make1($1); }
|
|
|
|
|
| createdb_opt_items createdb_opt_item { $$ = lappend($1, $2); }
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
createdb_opt_item:
|
2022-11-04 15:39:52 +01:00
|
|
|
createdb_opt_name opt_equal NumericOnly
|
2008-09-23 11:20:39 +02:00
|
|
|
{
|
2022-11-04 15:39:52 +01:00
|
|
|
$$ = makeDefElem($1, $3, @1);
|
2008-09-23 11:20:39 +02:00
|
|
|
}
|
2014-07-02 01:02:21 +02:00
|
|
|
| createdb_opt_name opt_equal opt_boolean_or_string
|
2008-09-23 11:20:39 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = makeDefElem($1, (Node *) makeString($3), @1);
|
2008-09-23 11:20:39 +02:00
|
|
|
}
|
2014-07-02 01:02:21 +02:00
|
|
|
| createdb_opt_name opt_equal DEFAULT
|
2005-07-31 19:19:22 +02:00
|
|
|
{
|
2016-09-06 18:00:00 +02:00
|
|
|
$$ = makeDefElem($1, NULL, @1);
|
2002-03-19 13:52:22 +01:00
|
|
|
}
|
2002-03-19 03:18:25 +01:00
|
|
|
;
|
|
|
|
|
|
2014-07-02 01:02:21 +02:00
|
|
|
/*
|
|
|
|
|
* Ideally we'd use ColId here, but that causes shift/reduce conflicts against
|
|
|
|
|
* the ALTER DATABASE SET/RESET syntaxes. Instead call out specific keywords
|
|
|
|
|
* we need, and allow IDENT so that database option names don't have to be
|
|
|
|
|
* parser keywords unless they are already keywords for other reasons.
|
|
|
|
|
*
|
|
|
|
|
* XXX this coding technique is fragile since if someone makes a formerly
|
|
|
|
|
* non-keyword option name into a keyword and forgets to add it here, the
|
|
|
|
|
* option will silently break. Best defense is to provide a regression test
|
|
|
|
|
* exercising every such option, at least at the syntax level.
|
|
|
|
|
*/
|
|
|
|
|
createdb_opt_name:
|
|
|
|
|
IDENT { $$ = $1; }
|
|
|
|
|
| CONNECTION LIMIT { $$ = pstrdup("connection_limit"); }
|
|
|
|
|
| ENCODING { $$ = pstrdup($1); }
|
|
|
|
|
| LOCATION { $$ = pstrdup($1); }
|
|
|
|
|
| OWNER { $$ = pstrdup($1); }
|
|
|
|
|
| TABLESPACE { $$ = pstrdup($1); }
|
|
|
|
|
| TEMPLATE { $$ = pstrdup($1); }
|
|
|
|
|
;
|
|
|
|
|
|
2002-03-20 20:45:13 +01:00
|
|
|
/*
|
|
|
|
|
* Though the equals sign doesn't match other WITH options, pg_dump uses
|
2005-07-31 19:19:22 +02:00
|
|
|
* equals for backward compatibility, and it doesn't seem worth removing it.
|
2002-03-20 20:45:13 +01:00
|
|
|
*/
|
2020-11-12 07:48:36 +01:00
|
|
|
opt_equal: '='
|
|
|
|
|
| /*EMPTY*/
|
2002-03-20 20:45:13 +01:00
|
|
|
;
|
|
|
|
|
|
2002-03-19 03:18:25 +01:00
|
|
|
|
2002-03-01 23:45:19 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* ALTER DATABASE
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2005-07-31 19:19:22 +02:00
|
|
|
AlterDatabaseStmt:
|
2020-06-10 22:58:46 +02:00
|
|
|
ALTER DATABASE name WITH createdb_opt_list
|
2005-07-31 19:19:22 +02:00
|
|
|
{
|
|
|
|
|
AlterDatabaseStmt *n = makeNode(AlterDatabaseStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-07-31 19:19:22 +02:00
|
|
|
n->dbname = $3;
|
|
|
|
|
n->options = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-07-31 19:19:22 +02:00
|
|
|
}
|
2020-06-10 22:58:46 +02:00
|
|
|
| ALTER DATABASE name createdb_opt_list
|
2014-07-02 01:02:21 +02:00
|
|
|
{
|
|
|
|
|
AlterDatabaseStmt *n = makeNode(AlterDatabaseStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-07-02 01:02:21 +02:00
|
|
|
n->dbname = $3;
|
|
|
|
|
n->options = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2014-07-02 01:02:21 +02:00
|
|
|
}
|
2020-06-10 22:58:46 +02:00
|
|
|
| ALTER DATABASE name SET TABLESPACE name
|
2008-11-07 19:25:07 +01:00
|
|
|
{
|
|
|
|
|
AlterDatabaseStmt *n = makeNode(AlterDatabaseStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-11-07 19:25:07 +01:00
|
|
|
n->dbname = $3;
|
|
|
|
|
n->options = list_make1(makeDefElem("tablespace",
|
2022-05-13 07:17:29 +02:00
|
|
|
(Node *) makeString($6), @6));
|
|
|
|
|
$$ = (Node *) n;
|
2008-11-07 19:25:07 +01:00
|
|
|
}
|
2022-02-14 08:09:04 +01:00
|
|
|
| ALTER DATABASE name REFRESH COLLATION VERSION_P
|
|
|
|
|
{
|
|
|
|
|
AlterDatabaseRefreshCollStmt *n = makeNode(AlterDatabaseRefreshCollStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2022-02-14 08:09:04 +01:00
|
|
|
n->dbname = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2022-02-14 08:09:04 +01:00
|
|
|
}
|
2005-07-31 19:19:22 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
AlterDatabaseSetStmt:
|
2020-06-10 22:58:46 +02:00
|
|
|
ALTER DATABASE name SetResetClause
|
2002-03-01 23:45:19 +01:00
|
|
|
{
|
|
|
|
|
AlterDatabaseSetStmt *n = makeNode(AlterDatabaseSetStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-03-01 23:45:19 +01:00
|
|
|
n->dbname = $3;
|
2007-09-03 20:46:30 +02:00
|
|
|
n->setstmt = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-03-01 23:45:19 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2002-03-21 17:02:16 +01:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2019-11-12 06:36:13 +01:00
|
|
|
* DROP DATABASE [ IF EXISTS ] dbname [ [ WITH ] ( options ) ]
|
2002-03-21 17:02:16 +01:00
|
|
|
*
|
2002-07-01 17:27:56 +02:00
|
|
|
* This is implicitly CASCADE, no need for drop behavior
|
2002-03-21 17:02:16 +01:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2020-06-10 22:58:46 +02:00
|
|
|
DropdbStmt: DROP DATABASE name
|
2002-03-21 17:02:16 +01:00
|
|
|
{
|
|
|
|
|
DropdbStmt *n = makeNode(DropdbStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-03-21 17:02:16 +01:00
|
|
|
n->dbname = $3;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = false;
|
2019-11-12 06:36:13 +01:00
|
|
|
n->options = NULL;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2005-11-22 16:24:18 +01:00
|
|
|
}
|
2020-06-10 22:58:46 +02:00
|
|
|
| DROP DATABASE IF_P EXISTS name
|
2005-11-22 16:24:18 +01:00
|
|
|
{
|
|
|
|
|
DropdbStmt *n = makeNode(DropdbStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-11-22 16:24:18 +01:00
|
|
|
n->dbname = $5;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->missing_ok = true;
|
2019-11-12 06:36:13 +01:00
|
|
|
n->options = NULL;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-03-21 17:02:16 +01:00
|
|
|
}
|
2020-06-10 22:58:46 +02:00
|
|
|
| DROP DATABASE name opt_with '(' drop_option_list ')'
|
2019-11-12 06:36:13 +01:00
|
|
|
{
|
|
|
|
|
DropdbStmt *n = makeNode(DropdbStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2019-11-12 06:36:13 +01:00
|
|
|
n->dbname = $3;
|
|
|
|
|
n->missing_ok = false;
|
|
|
|
|
n->options = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2019-11-12 06:36:13 +01:00
|
|
|
}
|
2020-06-10 22:58:46 +02:00
|
|
|
| DROP DATABASE IF_P EXISTS name opt_with '(' drop_option_list ')'
|
2019-11-12 06:36:13 +01:00
|
|
|
{
|
|
|
|
|
DropdbStmt *n = makeNode(DropdbStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2019-11-12 06:36:13 +01:00
|
|
|
n->dbname = $5;
|
|
|
|
|
n->missing_ok = true;
|
|
|
|
|
n->options = $8;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2019-11-12 06:36:13 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
drop_option_list:
|
|
|
|
|
drop_option
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make1((Node *) $1);
|
|
|
|
|
}
|
|
|
|
|
| drop_option_list ',' drop_option
|
|
|
|
|
{
|
|
|
|
|
$$ = lappend($1, (Node *) $3);
|
|
|
|
|
}
|
2002-03-21 17:02:16 +01:00
|
|
|
;
|
|
|
|
|
|
2019-11-12 06:36:13 +01:00
|
|
|
/*
|
|
|
|
|
* Currently only the FORCE option is supported, but the syntax is designed
|
|
|
|
|
* to be extensible so that we can add more options in the future if required.
|
|
|
|
|
*/
|
|
|
|
|
drop_option:
|
|
|
|
|
FORCE
|
|
|
|
|
{
|
|
|
|
|
$$ = makeDefElem("force", NULL, @1);
|
|
|
|
|
}
|
|
|
|
|
;
|
2002-03-21 17:02:16 +01:00
|
|
|
|
2021-05-07 10:17:42 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* ALTER COLLATION
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
AlterCollationStmt: ALTER COLLATION any_name REFRESH VERSION_P
|
|
|
|
|
{
|
|
|
|
|
AlterCollationStmt *n = makeNode(AlterCollationStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-05-07 10:17:42 +02:00
|
|
|
n->collname = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2021-05-07 10:17:42 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
2013-12-18 15:42:44 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2014-09-02 09:06:58 +02:00
|
|
|
* ALTER SYSTEM
|
2013-12-18 15:42:44 +01:00
|
|
|
*
|
|
|
|
|
* This is used to change configuration parameters persistently.
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
AlterSystemStmt:
|
|
|
|
|
ALTER SYSTEM_P SET generic_set
|
|
|
|
|
{
|
|
|
|
|
AlterSystemStmt *n = makeNode(AlterSystemStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2013-12-18 15:42:44 +01:00
|
|
|
n->setstmt = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2013-12-18 15:42:44 +01:00
|
|
|
}
|
2014-09-02 09:06:58 +02:00
|
|
|
| ALTER SYSTEM_P RESET generic_reset
|
|
|
|
|
{
|
|
|
|
|
AlterSystemStmt *n = makeNode(AlterSystemStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2014-09-02 09:06:58 +02:00
|
|
|
n->setstmt = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2014-09-02 09:06:58 +02:00
|
|
|
}
|
2013-12-18 15:42:44 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
2002-03-21 17:02:16 +01:00
|
|
|
/*****************************************************************************
|
2000-01-13 19:26:18 +01:00
|
|
|
*
|
2002-03-21 17:02:16 +01:00
|
|
|
* Manipulate a domain
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
CreateDomainStmt:
|
2003-09-06 16:01:51 +02:00
|
|
|
CREATE DOMAIN_P any_name opt_as Typename ColQualList
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2002-03-19 03:18:25 +01:00
|
|
|
CreateDomainStmt *n = makeNode(CreateDomainStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-03-19 03:18:25 +01:00
|
|
|
n->domainname = $3;
|
2009-07-16 08:33:46 +02:00
|
|
|
n->typeName = $5;
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
SplitColQualList($6, &n->constraints, &n->collClause,
|
|
|
|
|
yyscanner);
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
|
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-12-06 06:00:34 +01:00
|
|
|
AlterDomainStmt:
|
|
|
|
|
/* ALTER DOMAIN <domain> {SET DEFAULT <expr>|DROP DEFAULT} */
|
|
|
|
|
ALTER DOMAIN_P any_name alter_column_default
|
|
|
|
|
{
|
|
|
|
|
AlterDomainStmt *n = makeNode(AlterDomainStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-12-06 06:00:34 +01:00
|
|
|
n->subtype = 'T';
|
2009-07-16 08:33:46 +02:00
|
|
|
n->typeName = $3;
|
2002-12-06 06:00:34 +01:00
|
|
|
n->def = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-12-06 06:00:34 +01:00
|
|
|
}
|
|
|
|
|
/* ALTER DOMAIN <domain> DROP NOT NULL */
|
|
|
|
|
| ALTER DOMAIN_P any_name DROP NOT NULL_P
|
|
|
|
|
{
|
|
|
|
|
AlterDomainStmt *n = makeNode(AlterDomainStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-12-06 06:00:34 +01:00
|
|
|
n->subtype = 'N';
|
2009-07-16 08:33:46 +02:00
|
|
|
n->typeName = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-12-06 06:00:34 +01:00
|
|
|
}
|
|
|
|
|
/* ALTER DOMAIN <domain> SET NOT NULL */
|
|
|
|
|
| ALTER DOMAIN_P any_name SET NOT NULL_P
|
|
|
|
|
{
|
|
|
|
|
AlterDomainStmt *n = makeNode(AlterDomainStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-12-06 06:00:34 +01:00
|
|
|
n->subtype = 'O';
|
2009-07-16 08:33:46 +02:00
|
|
|
n->typeName = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-12-06 06:00:34 +01:00
|
|
|
}
|
2005-12-29 05:53:18 +01:00
|
|
|
/* ALTER DOMAIN <domain> ADD CONSTRAINT ... */
|
2005-12-27 05:00:08 +01:00
|
|
|
| ALTER DOMAIN_P any_name ADD_P TableConstraint
|
2002-12-06 06:00:34 +01:00
|
|
|
{
|
|
|
|
|
AlterDomainStmt *n = makeNode(AlterDomainStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-12-06 06:00:34 +01:00
|
|
|
n->subtype = 'C';
|
2009-07-16 08:33:46 +02:00
|
|
|
n->typeName = $3;
|
2002-12-06 06:00:34 +01:00
|
|
|
n->def = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-12-06 06:00:34 +01:00
|
|
|
}
|
|
|
|
|
/* ALTER DOMAIN <domain> DROP CONSTRAINT <name> [RESTRICT|CASCADE] */
|
|
|
|
|
| ALTER DOMAIN_P any_name DROP CONSTRAINT name opt_drop_behavior
|
|
|
|
|
{
|
|
|
|
|
AlterDomainStmt *n = makeNode(AlterDomainStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-12-06 06:00:34 +01:00
|
|
|
n->subtype = 'X';
|
2009-07-16 08:33:46 +02:00
|
|
|
n->typeName = $3;
|
2002-12-06 06:00:34 +01:00
|
|
|
n->name = $6;
|
|
|
|
|
n->behavior = $7;
|
2012-01-05 18:48:55 +01:00
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2012-01-05 18:48:55 +01:00
|
|
|
}
|
|
|
|
|
/* ALTER DOMAIN <domain> DROP CONSTRAINT IF EXISTS <name> [RESTRICT|CASCADE] */
|
|
|
|
|
| ALTER DOMAIN_P any_name DROP CONSTRAINT IF_P EXISTS name opt_drop_behavior
|
|
|
|
|
{
|
|
|
|
|
AlterDomainStmt *n = makeNode(AlterDomainStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-01-05 18:48:55 +01:00
|
|
|
n->subtype = 'X';
|
|
|
|
|
n->typeName = $3;
|
|
|
|
|
n->name = $8;
|
|
|
|
|
n->behavior = $9;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-12-06 06:00:34 +01:00
|
|
|
}
|
2011-06-02 00:43:50 +02:00
|
|
|
/* ALTER DOMAIN <domain> VALIDATE CONSTRAINT <name> */
|
|
|
|
|
| ALTER DOMAIN_P any_name VALIDATE CONSTRAINT name
|
|
|
|
|
{
|
|
|
|
|
AlterDomainStmt *n = makeNode(AlterDomainStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-06-02 00:43:50 +02:00
|
|
|
n->subtype = 'V';
|
|
|
|
|
n->typeName = $3;
|
|
|
|
|
n->name = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2011-06-02 00:43:50 +02:00
|
|
|
}
|
2002-12-06 06:00:34 +01:00
|
|
|
;
|
|
|
|
|
|
2020-11-12 07:48:36 +01:00
|
|
|
opt_as: AS
|
|
|
|
|
| /* EMPTY */
|
2002-06-17 22:27:43 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-03-21 17:02:16 +01:00
|
|
|
|
2007-08-21 03:11:32 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* Manipulate a text search dictionary or configuration
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
AlterTSDictionaryStmt:
|
2007-08-21 17:13:42 +02:00
|
|
|
ALTER TEXT_P SEARCH DICTIONARY any_name definition
|
2007-08-21 03:11:32 +02:00
|
|
|
{
|
|
|
|
|
AlterTSDictionaryStmt *n = makeNode(AlterTSDictionaryStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-08-21 03:11:32 +02:00
|
|
|
n->dictname = $5;
|
|
|
|
|
n->options = $6;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-08-21 03:11:32 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
AlterTSConfigurationStmt:
|
Improve parser's one-extra-token lookahead mechanism.
There are a couple of places in our grammar that fail to be strict LALR(1),
by requiring more than a single token of lookahead to decide what to do.
Up to now we've dealt with that by using a filter between the lexer and
parser that merges adjacent tokens into one in the places where two tokens
of lookahead are necessary. But that creates a number of user-visible
anomalies, for instance that you can't name a CTE "ordinality" because
"WITH ordinality AS ..." triggers folding of WITH and ORDINALITY into one
token. I realized that there's a better way.
In this patch, we still do the lookahead basically as before, but we never
merge the second token into the first; we replace just the first token by
a special lookahead symbol when one of the lookahead pairs is seen.
This requires a couple extra productions in the grammar, but it involves
fewer special tokens, so that the grammar tables come out a bit smaller
than before. The filter logic is no slower than before, perhaps a bit
faster.
I also fixed the filter logic so that when backing up after a lookahead,
the current token's terminator is correctly restored; this eliminates some
weird behavior in error message issuance, as is shown by the one change in
existing regression test outputs.
I believe that this patch entirely eliminates odd behaviors caused by
lookahead for WITH. It doesn't really improve the situation for NULLS
followed by FIRST/LAST unfortunately: those sequences still act like a
reserved word, even though there are cases where they should be seen as two
ordinary identifiers, eg "SELECT nulls first FROM ...". I experimented
with additional grammar hacks but couldn't find any simple solution for
that. Still, this is better than before, and it seems much more likely
that we *could* somehow solve the NULLS case on the basis of this filter
behavior than the previous one.
2015-02-24 23:53:42 +01:00
|
|
|
ALTER TEXT_P SEARCH CONFIGURATION any_name ADD_P MAPPING FOR name_list any_with any_name_list
|
2007-08-21 03:11:32 +02:00
|
|
|
{
|
|
|
|
|
AlterTSConfigurationStmt *n = makeNode(AlterTSConfigurationStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
n->kind = ALTER_TSCONFIG_ADD_MAPPING;
|
2007-08-21 03:11:32 +02:00
|
|
|
n->cfgname = $5;
|
|
|
|
|
n->tokentype = $9;
|
|
|
|
|
n->dicts = $11;
|
|
|
|
|
n->override = false;
|
|
|
|
|
n->replace = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-08-21 03:11:32 +02:00
|
|
|
}
|
Improve parser's one-extra-token lookahead mechanism.
There are a couple of places in our grammar that fail to be strict LALR(1),
by requiring more than a single token of lookahead to decide what to do.
Up to now we've dealt with that by using a filter between the lexer and
parser that merges adjacent tokens into one in the places where two tokens
of lookahead are necessary. But that creates a number of user-visible
anomalies, for instance that you can't name a CTE "ordinality" because
"WITH ordinality AS ..." triggers folding of WITH and ORDINALITY into one
token. I realized that there's a better way.
In this patch, we still do the lookahead basically as before, but we never
merge the second token into the first; we replace just the first token by
a special lookahead symbol when one of the lookahead pairs is seen.
This requires a couple extra productions in the grammar, but it involves
fewer special tokens, so that the grammar tables come out a bit smaller
than before. The filter logic is no slower than before, perhaps a bit
faster.
I also fixed the filter logic so that when backing up after a lookahead,
the current token's terminator is correctly restored; this eliminates some
weird behavior in error message issuance, as is shown by the one change in
existing regression test outputs.
I believe that this patch entirely eliminates odd behaviors caused by
lookahead for WITH. It doesn't really improve the situation for NULLS
followed by FIRST/LAST unfortunately: those sequences still act like a
reserved word, even though there are cases where they should be seen as two
ordinary identifiers, eg "SELECT nulls first FROM ...". I experimented
with additional grammar hacks but couldn't find any simple solution for
that. Still, this is better than before, and it seems much more likely
that we *could* somehow solve the NULLS case on the basis of this filter
behavior than the previous one.
2015-02-24 23:53:42 +01:00
|
|
|
| ALTER TEXT_P SEARCH CONFIGURATION any_name ALTER MAPPING FOR name_list any_with any_name_list
|
2007-08-21 03:11:32 +02:00
|
|
|
{
|
|
|
|
|
AlterTSConfigurationStmt *n = makeNode(AlterTSConfigurationStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
n->kind = ALTER_TSCONFIG_ALTER_MAPPING_FOR_TOKEN;
|
2007-08-21 03:11:32 +02:00
|
|
|
n->cfgname = $5;
|
|
|
|
|
n->tokentype = $9;
|
|
|
|
|
n->dicts = $11;
|
|
|
|
|
n->override = true;
|
|
|
|
|
n->replace = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-08-21 03:11:32 +02:00
|
|
|
}
|
Improve parser's one-extra-token lookahead mechanism.
There are a couple of places in our grammar that fail to be strict LALR(1),
by requiring more than a single token of lookahead to decide what to do.
Up to now we've dealt with that by using a filter between the lexer and
parser that merges adjacent tokens into one in the places where two tokens
of lookahead are necessary. But that creates a number of user-visible
anomalies, for instance that you can't name a CTE "ordinality" because
"WITH ordinality AS ..." triggers folding of WITH and ORDINALITY into one
token. I realized that there's a better way.
In this patch, we still do the lookahead basically as before, but we never
merge the second token into the first; we replace just the first token by
a special lookahead symbol when one of the lookahead pairs is seen.
This requires a couple extra productions in the grammar, but it involves
fewer special tokens, so that the grammar tables come out a bit smaller
than before. The filter logic is no slower than before, perhaps a bit
faster.
I also fixed the filter logic so that when backing up after a lookahead,
the current token's terminator is correctly restored; this eliminates some
weird behavior in error message issuance, as is shown by the one change in
existing regression test outputs.
I believe that this patch entirely eliminates odd behaviors caused by
lookahead for WITH. It doesn't really improve the situation for NULLS
followed by FIRST/LAST unfortunately: those sequences still act like a
reserved word, even though there are cases where they should be seen as two
ordinary identifiers, eg "SELECT nulls first FROM ...". I experimented
with additional grammar hacks but couldn't find any simple solution for
that. Still, this is better than before, and it seems much more likely
that we *could* somehow solve the NULLS case on the basis of this filter
behavior than the previous one.
2015-02-24 23:53:42 +01:00
|
|
|
| ALTER TEXT_P SEARCH CONFIGURATION any_name ALTER MAPPING REPLACE any_name any_with any_name
|
2007-08-21 03:11:32 +02:00
|
|
|
{
|
|
|
|
|
AlterTSConfigurationStmt *n = makeNode(AlterTSConfigurationStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
n->kind = ALTER_TSCONFIG_REPLACE_DICT;
|
2007-08-21 03:11:32 +02:00
|
|
|
n->cfgname = $5;
|
|
|
|
|
n->tokentype = NIL;
|
|
|
|
|
n->dicts = list_make2($9,$11);
|
|
|
|
|
n->override = false;
|
|
|
|
|
n->replace = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-08-21 03:11:32 +02:00
|
|
|
}
|
Improve parser's one-extra-token lookahead mechanism.
There are a couple of places in our grammar that fail to be strict LALR(1),
by requiring more than a single token of lookahead to decide what to do.
Up to now we've dealt with that by using a filter between the lexer and
parser that merges adjacent tokens into one in the places where two tokens
of lookahead are necessary. But that creates a number of user-visible
anomalies, for instance that you can't name a CTE "ordinality" because
"WITH ordinality AS ..." triggers folding of WITH and ORDINALITY into one
token. I realized that there's a better way.
In this patch, we still do the lookahead basically as before, but we never
merge the second token into the first; we replace just the first token by
a special lookahead symbol when one of the lookahead pairs is seen.
This requires a couple extra productions in the grammar, but it involves
fewer special tokens, so that the grammar tables come out a bit smaller
than before. The filter logic is no slower than before, perhaps a bit
faster.
I also fixed the filter logic so that when backing up after a lookahead,
the current token's terminator is correctly restored; this eliminates some
weird behavior in error message issuance, as is shown by the one change in
existing regression test outputs.
I believe that this patch entirely eliminates odd behaviors caused by
lookahead for WITH. It doesn't really improve the situation for NULLS
followed by FIRST/LAST unfortunately: those sequences still act like a
reserved word, even though there are cases where they should be seen as two
ordinary identifiers, eg "SELECT nulls first FROM ...". I experimented
with additional grammar hacks but couldn't find any simple solution for
that. Still, this is better than before, and it seems much more likely
that we *could* somehow solve the NULLS case on the basis of this filter
behavior than the previous one.
2015-02-24 23:53:42 +01:00
|
|
|
| ALTER TEXT_P SEARCH CONFIGURATION any_name ALTER MAPPING FOR name_list REPLACE any_name any_with any_name
|
2007-08-21 03:11:32 +02:00
|
|
|
{
|
|
|
|
|
AlterTSConfigurationStmt *n = makeNode(AlterTSConfigurationStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
n->kind = ALTER_TSCONFIG_REPLACE_DICT_FOR_TOKEN;
|
2007-08-21 03:11:32 +02:00
|
|
|
n->cfgname = $5;
|
|
|
|
|
n->tokentype = $9;
|
|
|
|
|
n->dicts = list_make2($11,$13);
|
|
|
|
|
n->override = false;
|
|
|
|
|
n->replace = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-08-21 03:11:32 +02:00
|
|
|
}
|
2008-12-18 19:20:35 +01:00
|
|
|
| ALTER TEXT_P SEARCH CONFIGURATION any_name DROP MAPPING FOR name_list
|
2007-08-21 03:11:32 +02:00
|
|
|
{
|
|
|
|
|
AlterTSConfigurationStmt *n = makeNode(AlterTSConfigurationStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
n->kind = ALTER_TSCONFIG_DROP_MAPPING;
|
2007-08-21 03:11:32 +02:00
|
|
|
n->cfgname = $5;
|
|
|
|
|
n->tokentype = $9;
|
|
|
|
|
n->missing_ok = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-08-21 03:11:32 +02:00
|
|
|
}
|
2008-12-18 19:20:35 +01:00
|
|
|
| ALTER TEXT_P SEARCH CONFIGURATION any_name DROP MAPPING IF_P EXISTS FOR name_list
|
2007-08-21 03:11:32 +02:00
|
|
|
{
|
|
|
|
|
AlterTSConfigurationStmt *n = makeNode(AlterTSConfigurationStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
n->kind = ALTER_TSCONFIG_DROP_MAPPING;
|
2007-08-21 03:11:32 +02:00
|
|
|
n->cfgname = $5;
|
|
|
|
|
n->tokentype = $11;
|
|
|
|
|
n->missing_ok = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-08-21 03:11:32 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
Improve parser's one-extra-token lookahead mechanism.
There are a couple of places in our grammar that fail to be strict LALR(1),
by requiring more than a single token of lookahead to decide what to do.
Up to now we've dealt with that by using a filter between the lexer and
parser that merges adjacent tokens into one in the places where two tokens
of lookahead are necessary. But that creates a number of user-visible
anomalies, for instance that you can't name a CTE "ordinality" because
"WITH ordinality AS ..." triggers folding of WITH and ORDINALITY into one
token. I realized that there's a better way.
In this patch, we still do the lookahead basically as before, but we never
merge the second token into the first; we replace just the first token by
a special lookahead symbol when one of the lookahead pairs is seen.
This requires a couple extra productions in the grammar, but it involves
fewer special tokens, so that the grammar tables come out a bit smaller
than before. The filter logic is no slower than before, perhaps a bit
faster.
I also fixed the filter logic so that when backing up after a lookahead,
the current token's terminator is correctly restored; this eliminates some
weird behavior in error message issuance, as is shown by the one change in
existing regression test outputs.
I believe that this patch entirely eliminates odd behaviors caused by
lookahead for WITH. It doesn't really improve the situation for NULLS
followed by FIRST/LAST unfortunately: those sequences still act like a
reserved word, even though there are cases where they should be seen as two
ordinary identifiers, eg "SELECT nulls first FROM ...". I experimented
with additional grammar hacks but couldn't find any simple solution for
that. Still, this is better than before, and it seems much more likely
that we *could* somehow solve the NULLS case on the basis of this filter
behavior than the previous one.
2015-02-24 23:53:42 +01:00
|
|
|
/* Use this if TIME or ORDINALITY after WITH should be taken as an identifier */
|
2020-11-12 07:48:36 +01:00
|
|
|
any_with: WITH
|
|
|
|
|
| WITH_LA
|
Improve parser's one-extra-token lookahead mechanism.
There are a couple of places in our grammar that fail to be strict LALR(1),
by requiring more than a single token of lookahead to decide what to do.
Up to now we've dealt with that by using a filter between the lexer and
parser that merges adjacent tokens into one in the places where two tokens
of lookahead are necessary. But that creates a number of user-visible
anomalies, for instance that you can't name a CTE "ordinality" because
"WITH ordinality AS ..." triggers folding of WITH and ORDINALITY into one
token. I realized that there's a better way.
In this patch, we still do the lookahead basically as before, but we never
merge the second token into the first; we replace just the first token by
a special lookahead symbol when one of the lookahead pairs is seen.
This requires a couple extra productions in the grammar, but it involves
fewer special tokens, so that the grammar tables come out a bit smaller
than before. The filter logic is no slower than before, perhaps a bit
faster.
I also fixed the filter logic so that when backing up after a lookahead,
the current token's terminator is correctly restored; this eliminates some
weird behavior in error message issuance, as is shown by the one change in
existing regression test outputs.
I believe that this patch entirely eliminates odd behaviors caused by
lookahead for WITH. It doesn't really improve the situation for NULLS
followed by FIRST/LAST unfortunately: those sequences still act like a
reserved word, even though there are cases where they should be seen as two
ordinary identifiers, eg "SELECT nulls first FROM ...". I experimented
with additional grammar hacks but couldn't find any simple solution for
that. Still, this is better than before, and it seems much more likely
that we *could* somehow solve the NULLS case on the basis of this filter
behavior than the previous one.
2015-02-24 23:53:42 +01:00
|
|
|
;
|
|
|
|
|
|
2007-08-21 03:11:32 +02:00
|
|
|
|
2002-07-11 09:39:28 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* Manipulate a conversion
|
|
|
|
|
*
|
|
|
|
|
* CREATE [DEFAULT] CONVERSION <conversion_name>
|
|
|
|
|
* FOR <encoding_name> TO <encoding_name> FROM <func_name>
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
CreateConversionStmt:
|
|
|
|
|
CREATE opt_default CONVERSION_P any_name FOR Sconst
|
|
|
|
|
TO Sconst FROM any_name
|
|
|
|
|
{
|
2011-11-01 20:50:00 +01:00
|
|
|
CreateConversionStmt *n = makeNode(CreateConversionStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-11-01 20:50:00 +01:00
|
|
|
n->conversion_name = $4;
|
|
|
|
|
n->for_encoding_name = $6;
|
|
|
|
|
n->to_encoding_name = $8;
|
|
|
|
|
n->func_name = $10;
|
|
|
|
|
n->def = $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-07-11 09:39:28 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* QUERY:
|
2008-11-24 09:46:04 +01:00
|
|
|
* CLUSTER [VERBOSE] <qualified_name> [ USING <index_name> ]
|
2020-12-03 02:13:21 +01:00
|
|
|
* CLUSTER [ (options) ] <qualified_name> [ USING <index_name> ]
|
2008-11-24 09:46:04 +01:00
|
|
|
* CLUSTER [VERBOSE]
|
|
|
|
|
* CLUSTER [VERBOSE] <index_name> ON <qualified_name> (for pre-8.3)
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
ClusterStmt:
|
2008-11-24 09:46:04 +01:00
|
|
|
CLUSTER opt_verbose qualified_name cluster_index_specification
|
2002-11-15 04:09:39 +01:00
|
|
|
{
|
2011-11-01 20:50:00 +01:00
|
|
|
ClusterStmt *n = makeNode(ClusterStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-11-01 20:50:00 +01:00
|
|
|
n->relation = $3;
|
|
|
|
|
n->indexname = $4;
|
2020-12-03 02:13:21 +01:00
|
|
|
n->params = NIL;
|
2018-07-24 04:37:32 +02:00
|
|
|
if ($2)
|
2020-12-03 02:13:21 +01:00
|
|
|
n->params = lappend(n->params, makeDefElem("verbose", NULL, @2));
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2020-12-03 02:13:21 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
| CLUSTER '(' utility_option_list ')' qualified_name cluster_index_specification
|
|
|
|
|
{
|
|
|
|
|
ClusterStmt *n = makeNode(ClusterStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2020-12-03 02:13:21 +01:00
|
|
|
n->relation = $5;
|
|
|
|
|
n->indexname = $6;
|
|
|
|
|
n->params = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-11-15 04:09:39 +01:00
|
|
|
}
|
2008-11-24 09:46:04 +01:00
|
|
|
| CLUSTER opt_verbose
|
2011-11-01 20:50:00 +01:00
|
|
|
{
|
|
|
|
|
ClusterStmt *n = makeNode(ClusterStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-11-01 20:50:00 +01:00
|
|
|
n->relation = NULL;
|
|
|
|
|
n->indexname = NULL;
|
2020-12-03 02:13:21 +01:00
|
|
|
n->params = NIL;
|
2018-07-24 04:37:32 +02:00
|
|
|
if ($2)
|
2020-12-03 02:13:21 +01:00
|
|
|
n->params = lappend(n->params, makeDefElem("verbose", NULL, @2));
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2002-11-15 04:09:39 +01:00
|
|
|
}
|
2007-04-08 02:26:34 +02:00
|
|
|
/* kept for pre-8.3 compatibility */
|
2020-06-10 22:58:46 +02:00
|
|
|
| CLUSTER opt_verbose name ON qualified_name
|
2007-04-08 02:26:34 +02:00
|
|
|
{
|
2011-11-01 20:50:00 +01:00
|
|
|
ClusterStmt *n = makeNode(ClusterStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-11-01 20:50:00 +01:00
|
|
|
n->relation = $5;
|
|
|
|
|
n->indexname = $3;
|
2020-12-03 02:13:21 +01:00
|
|
|
n->params = NIL;
|
2018-07-24 04:37:32 +02:00
|
|
|
if ($2)
|
2020-12-03 02:13:21 +01:00
|
|
|
n->params = lappend(n->params, makeDefElem("verbose", NULL, @2));
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2007-04-08 02:26:34 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
cluster_index_specification:
|
2020-06-10 22:58:46 +02:00
|
|
|
USING name { $$ = $2; }
|
2007-04-08 02:26:34 +02:00
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2007-04-08 02:26:34 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* QUERY:
|
2007-04-08 02:26:34 +02:00
|
|
|
* VACUUM
|
|
|
|
|
* ANALYZE
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2018-01-09 16:12:58 +01:00
|
|
|
VacuumStmt: VACUUM opt_full opt_freeze opt_verbose opt_analyze opt_vacuum_relation_list
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
|
|
|
|
VacuumStmt *n = makeNode(VacuumStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2019-03-18 20:14:52 +01:00
|
|
|
n->options = NIL;
|
2009-11-16 22:32:07 +01:00
|
|
|
if ($2)
|
2019-03-18 20:14:52 +01:00
|
|
|
n->options = lappend(n->options,
|
|
|
|
|
makeDefElem("full", NULL, @2));
|
2015-03-18 15:52:33 +01:00
|
|
|
if ($3)
|
2019-03-18 20:14:52 +01:00
|
|
|
n->options = lappend(n->options,
|
|
|
|
|
makeDefElem("freeze", NULL, @3));
|
2009-11-16 22:32:07 +01:00
|
|
|
if ($4)
|
2019-03-18 20:14:52 +01:00
|
|
|
n->options = lappend(n->options,
|
|
|
|
|
makeDefElem("verbose", NULL, @4));
|
2018-01-09 16:12:58 +01:00
|
|
|
if ($5)
|
2019-03-18 20:14:52 +01:00
|
|
|
n->options = lappend(n->options,
|
|
|
|
|
makeDefElem("analyze", NULL, @5));
|
2018-01-09 16:12:58 +01:00
|
|
|
n->rels = $6;
|
2019-03-18 20:14:52 +01:00
|
|
|
n->is_vacuumcmd = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2020-11-30 12:27:37 +01:00
|
|
|
| VACUUM '(' utility_option_list ')' opt_vacuum_relation_list
|
2009-11-16 22:32:07 +01:00
|
|
|
{
|
|
|
|
|
VacuumStmt *n = makeNode(VacuumStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2019-03-18 20:14:52 +01:00
|
|
|
n->options = $3;
|
2017-10-04 00:53:44 +02:00
|
|
|
n->rels = $5;
|
2019-03-18 20:14:52 +01:00
|
|
|
n->is_vacuumcmd = true;
|
2009-11-16 22:32:07 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2017-10-04 00:53:44 +02:00
|
|
|
AnalyzeStmt: analyze_keyword opt_verbose opt_vacuum_relation_list
|
2001-05-07 02:43:27 +02:00
|
|
|
{
|
|
|
|
|
VacuumStmt *n = makeNode(VacuumStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2019-03-18 20:14:52 +01:00
|
|
|
n->options = NIL;
|
2009-11-16 22:32:07 +01:00
|
|
|
if ($2)
|
2019-03-18 20:14:52 +01:00
|
|
|
n->options = lappend(n->options,
|
|
|
|
|
makeDefElem("verbose", NULL, @2));
|
2017-10-04 00:53:44 +02:00
|
|
|
n->rels = $3;
|
2019-03-18 20:14:52 +01:00
|
|
|
n->is_vacuumcmd = false;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2001-05-07 02:43:27 +02:00
|
|
|
}
|
2020-11-30 12:27:37 +01:00
|
|
|
| analyze_keyword '(' utility_option_list ')' opt_vacuum_relation_list
|
2018-03-06 01:21:05 +01:00
|
|
|
{
|
|
|
|
|
VacuumStmt *n = makeNode(VacuumStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2019-03-18 20:14:52 +01:00
|
|
|
n->options = $3;
|
2018-03-06 01:21:05 +01:00
|
|
|
n->rels = $5;
|
2019-03-18 20:14:52 +01:00
|
|
|
n->is_vacuumcmd = false;
|
2018-03-06 01:21:05 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2020-11-30 12:27:37 +01:00
|
|
|
utility_option_list:
|
|
|
|
|
utility_option_elem
|
2018-10-04 02:00:33 +02:00
|
|
|
{
|
2019-03-18 20:14:52 +01:00
|
|
|
$$ = list_make1($1);
|
|
|
|
|
}
|
2020-11-30 12:27:37 +01:00
|
|
|
| utility_option_list ',' utility_option_elem
|
2019-03-18 20:14:52 +01:00
|
|
|
{
|
|
|
|
|
$$ = lappend($1, $3);
|
2018-10-04 02:00:33 +02:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
analyze_keyword:
|
2020-11-12 07:48:36 +01:00
|
|
|
ANALYZE
|
|
|
|
|
| ANALYSE /* British */
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1997-04-23 08:04:46 +02:00
|
|
|
|
2020-11-30 12:27:37 +01:00
|
|
|
utility_option_elem:
|
|
|
|
|
utility_option_name utility_option_arg
|
2019-03-18 20:14:52 +01:00
|
|
|
{
|
2019-03-29 13:22:49 +01:00
|
|
|
$$ = makeDefElem($1, $2, @1);
|
2019-03-18 20:14:52 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2020-11-30 12:27:37 +01:00
|
|
|
utility_option_name:
|
2019-03-18 20:14:52 +01:00
|
|
|
NonReservedWord { $$ = $1; }
|
|
|
|
|
| analyze_keyword { $$ = "analyze"; }
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
| FORMAT_LA { $$ = "format"; }
|
2019-03-18 20:14:52 +01:00
|
|
|
;
|
|
|
|
|
|
2020-11-30 12:27:37 +01:00
|
|
|
utility_option_arg:
|
2019-03-29 13:22:49 +01:00
|
|
|
opt_boolean_or_string { $$ = (Node *) makeString($1); }
|
2020-11-11 17:37:18 +01:00
|
|
|
| NumericOnly { $$ = (Node *) $1; }
|
|
|
|
|
| /* EMPTY */ { $$ = NULL; }
|
2019-03-29 13:22:49 +01:00
|
|
|
;
|
|
|
|
|
|
2018-01-09 16:12:58 +01:00
|
|
|
opt_analyze:
|
|
|
|
|
analyze_keyword { $$ = true; }
|
|
|
|
|
| /*EMPTY*/ { $$ = false; }
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
opt_verbose:
|
2017-08-16 06:22:32 +02:00
|
|
|
VERBOSE { $$ = true; }
|
|
|
|
|
| /*EMPTY*/ { $$ = false; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1997-04-23 08:04:46 +02:00
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
opt_full: FULL { $$ = true; }
|
|
|
|
|
| /*EMPTY*/ { $$ = false; }
|
2001-07-11 00:09:29 +02:00
|
|
|
;
|
|
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
opt_freeze: FREEZE { $$ = true; }
|
|
|
|
|
| /*EMPTY*/ { $$ = false; }
|
2001-08-26 18:56:03 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
opt_name_list:
|
|
|
|
|
'(' name_list ')' { $$ = $2; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1997-09-01 08:00:35 +02:00
|
|
|
|
2017-10-04 00:53:44 +02:00
|
|
|
vacuum_relation:
|
|
|
|
|
qualified_name opt_name_list
|
|
|
|
|
{
|
|
|
|
|
$$ = (Node *) makeVacuumRelation($1, InvalidOid, $2);
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
vacuum_relation_list:
|
|
|
|
|
vacuum_relation
|
|
|
|
|
{ $$ = list_make1($1); }
|
|
|
|
|
| vacuum_relation_list ',' vacuum_relation
|
|
|
|
|
{ $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_vacuum_relation_list:
|
|
|
|
|
vacuum_relation_list { $$ = $1; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
1997-10-25 07:56:41 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* QUERY:
|
2003-02-03 00:46:38 +01:00
|
|
|
* EXPLAIN [ANALYZE] [VERBOSE] query
|
2009-07-27 01:34:18 +02:00
|
|
|
* EXPLAIN ( options ) query
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2009-07-27 01:34:18 +02:00
|
|
|
ExplainStmt:
|
|
|
|
|
EXPLAIN ExplainableStmt
|
|
|
|
|
{
|
|
|
|
|
ExplainStmt *n = makeNode(ExplainStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-07-27 01:34:18 +02:00
|
|
|
n->query = $2;
|
|
|
|
|
n->options = NIL;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| EXPLAIN analyze_keyword opt_verbose ExplainableStmt
|
2001-09-18 03:59:07 +02:00
|
|
|
{
|
|
|
|
|
ExplainStmt *n = makeNode(ExplainStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-03-13 01:33:44 +01:00
|
|
|
n->query = $4;
|
2016-09-06 18:00:00 +02:00
|
|
|
n->options = list_make1(makeDefElem("analyze", NULL, @2));
|
2009-07-27 01:34:18 +02:00
|
|
|
if ($3)
|
|
|
|
|
n->options = lappend(n->options,
|
2016-09-06 18:00:00 +02:00
|
|
|
makeDefElem("verbose", NULL, @3));
|
2009-07-27 01:34:18 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| EXPLAIN VERBOSE ExplainableStmt
|
|
|
|
|
{
|
|
|
|
|
ExplainStmt *n = makeNode(ExplainStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-07-27 01:34:18 +02:00
|
|
|
n->query = $3;
|
2016-09-06 18:00:00 +02:00
|
|
|
n->options = list_make1(makeDefElem("verbose", NULL, @2));
|
2009-07-27 01:34:18 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2020-11-30 12:27:37 +01:00
|
|
|
| EXPLAIN '(' utility_option_list ')' ExplainableStmt
|
2009-07-27 01:34:18 +02:00
|
|
|
{
|
|
|
|
|
ExplainStmt *n = makeNode(ExplainStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2009-07-27 01:34:18 +02:00
|
|
|
n->query = $5;
|
|
|
|
|
n->options = $3;
|
|
|
|
|
$$ = (Node *) n;
|
2001-09-18 03:59:07 +02:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2003-03-10 04:53:52 +01:00
|
|
|
ExplainableStmt:
|
|
|
|
|
SelectStmt
|
|
|
|
|
| InsertStmt
|
|
|
|
|
| UpdateStmt
|
|
|
|
|
| DeleteStmt
|
2022-03-28 16:45:58 +02:00
|
|
|
| MergeStmt
|
2003-03-10 04:53:52 +01:00
|
|
|
| DeclareCursorStmt
|
2008-10-27 09:47:14 +01:00
|
|
|
| CreateAsStmt
|
2013-03-04 01:23:31 +01:00
|
|
|
| CreateMatViewStmt
|
|
|
|
|
| RefreshMatViewStmt
|
2003-03-10 04:53:52 +01:00
|
|
|
| ExecuteStmt /* by default all are $$=$1 */
|
|
|
|
|
;
|
|
|
|
|
|
2002-08-27 06:55:12 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* QUERY:
|
|
|
|
|
* PREPARE <plan_name> [(args, ...)] AS <query>
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2003-03-10 04:53:52 +01:00
|
|
|
PrepareStmt: PREPARE name prep_type_clause AS PreparableStmt
|
2002-08-27 06:55:12 +02:00
|
|
|
{
|
|
|
|
|
PrepareStmt *n = makeNode(PrepareStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-08-27 06:55:12 +02:00
|
|
|
n->name = $2;
|
|
|
|
|
n->argtypes = $3;
|
2007-03-13 01:33:44 +01:00
|
|
|
n->query = $5;
|
2002-08-27 06:55:12 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2007-01-23 06:07:18 +01:00
|
|
|
prep_type_clause: '(' type_list ')' { $$ = $2; }
|
2002-08-27 06:55:12 +02:00
|
|
|
| /* EMPTY */ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
2003-03-10 04:53:52 +01:00
|
|
|
PreparableStmt:
|
|
|
|
|
SelectStmt
|
|
|
|
|
| InsertStmt
|
|
|
|
|
| UpdateStmt
|
2022-03-28 16:45:58 +02:00
|
|
|
| DeleteStmt
|
|
|
|
|
| MergeStmt /* by default all are $$=$1 */
|
2003-03-10 04:53:52 +01:00
|
|
|
;
|
|
|
|
|
|
2002-08-27 06:55:12 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2003-07-01 02:04:31 +02:00
|
|
|
* EXECUTE <plan_name> [(params, ...)]
|
|
|
|
|
* CREATE TABLE <name> AS EXECUTE <plan_name> [(params, ...)]
|
2002-08-27 06:55:12 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2003-07-01 02:04:31 +02:00
|
|
|
ExecuteStmt: EXECUTE name execute_param_clause
|
2002-08-27 06:55:12 +02:00
|
|
|
{
|
|
|
|
|
ExecuteStmt *n = makeNode(ExecuteStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-08-27 06:55:12 +02:00
|
|
|
n->name = $2;
|
|
|
|
|
n->params = $3;
|
2003-07-01 02:04:31 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2007-02-20 18:32:18 +01:00
|
|
|
| CREATE OptTemp TABLE create_as_target AS
|
2011-11-25 05:21:06 +01:00
|
|
|
EXECUTE name execute_param_clause opt_with_data
|
2003-07-01 02:04:31 +02:00
|
|
|
{
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
2012-03-20 02:37:19 +01:00
|
|
|
CreateTableAsStmt *ctas = makeNode(CreateTableAsStmt);
|
2003-07-01 02:04:31 +02:00
|
|
|
ExecuteStmt *n = makeNode(ExecuteStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-02-20 18:32:18 +01:00
|
|
|
n->name = $7;
|
|
|
|
|
n->params = $8;
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
2012-03-20 02:37:19 +01:00
|
|
|
ctas->query = (Node *) n;
|
|
|
|
|
ctas->into = $4;
|
2020-07-11 06:32:28 +02:00
|
|
|
ctas->objtype = OBJECT_TABLE;
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
2012-03-20 02:37:19 +01:00
|
|
|
ctas->is_select_into = false;
|
2019-02-15 09:12:24 +01:00
|
|
|
ctas->if_not_exists = false;
|
2011-11-25 05:21:06 +01:00
|
|
|
/* cram additional flags into the IntoClause */
|
|
|
|
|
$4->rel->relpersistence = $2;
|
|
|
|
|
$4->skipData = !($9);
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
2012-03-20 02:37:19 +01:00
|
|
|
$$ = (Node *) ctas;
|
2002-08-27 06:55:12 +02:00
|
|
|
}
|
2019-02-15 09:12:24 +01:00
|
|
|
| CREATE OptTemp TABLE IF_P NOT EXISTS create_as_target AS
|
|
|
|
|
EXECUTE name execute_param_clause opt_with_data
|
|
|
|
|
{
|
|
|
|
|
CreateTableAsStmt *ctas = makeNode(CreateTableAsStmt);
|
|
|
|
|
ExecuteStmt *n = makeNode(ExecuteStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2019-02-15 09:12:24 +01:00
|
|
|
n->name = $10;
|
|
|
|
|
n->params = $11;
|
|
|
|
|
ctas->query = (Node *) n;
|
|
|
|
|
ctas->into = $7;
|
2020-07-11 06:32:28 +02:00
|
|
|
ctas->objtype = OBJECT_TABLE;
|
2019-02-15 09:12:24 +01:00
|
|
|
ctas->is_select_into = false;
|
|
|
|
|
ctas->if_not_exists = true;
|
|
|
|
|
/* cram additional flags into the IntoClause */
|
|
|
|
|
$7->rel->relpersistence = $2;
|
|
|
|
|
$7->skipData = !($12);
|
|
|
|
|
$$ = (Node *) ctas;
|
|
|
|
|
}
|
2002-08-27 06:55:12 +02:00
|
|
|
;
|
|
|
|
|
|
2002-11-02 19:41:22 +01:00
|
|
|
execute_param_clause: '(' expr_list ')' { $$ = $2; }
|
2002-08-27 06:55:12 +02:00
|
|
|
| /* EMPTY */ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* QUERY:
|
|
|
|
|
* DEALLOCATE [PREPARE] <plan_name>
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
DeallocateStmt: DEALLOCATE name
|
|
|
|
|
{
|
|
|
|
|
DeallocateStmt *n = makeNode(DeallocateStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-08-27 06:55:12 +02:00
|
|
|
n->name = $2;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| DEALLOCATE PREPARE name
|
|
|
|
|
{
|
|
|
|
|
DeallocateStmt *n = makeNode(DeallocateStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-08-27 06:55:12 +02:00
|
|
|
n->name = $3;
|
|
|
|
|
$$ = (Node *) n;
|
2007-04-12 08:53:49 +02:00
|
|
|
}
|
|
|
|
|
| DEALLOCATE ALL
|
|
|
|
|
{
|
|
|
|
|
DeallocateStmt *n = makeNode(DeallocateStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-04-12 08:53:49 +02:00
|
|
|
n->name = NULL;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| DEALLOCATE PREPARE ALL
|
|
|
|
|
{
|
|
|
|
|
DeallocateStmt *n = makeNode(DeallocateStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-04-12 08:53:49 +02:00
|
|
|
n->name = NULL;
|
|
|
|
|
$$ = (Node *) n;
|
2002-08-27 06:55:12 +02:00
|
|
|
}
|
|
|
|
|
;
|
1997-10-25 07:56:41 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* QUERY:
|
|
|
|
|
* INSERT STATEMENTS
|
1997-09-01 08:00:35 +02:00
|
|
|
*
|
1996-07-09 08:22:35 +02:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
InsertStmt:
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
opt_with_clause INSERT INTO insert_target insert_rest
|
|
|
|
|
opt_on_conflict returning_clause
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2010-10-16 01:53:59 +02:00
|
|
|
$5->relation = $4;
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
$5->onConflictClause = $6;
|
|
|
|
|
$5->returningList = $7;
|
2010-10-16 01:53:59 +02:00
|
|
|
$5->withClause = $1;
|
|
|
|
|
$$ = (Node *) $5;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
|
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
/*
|
|
|
|
|
* Can't easily make AS optional here, because VALUES in insert_rest would
|
2015-05-20 20:50:22 +02:00
|
|
|
* have a shift/reduce conflict with VALUES as an optional alias. We could
|
2015-05-20 15:18:11 +02:00
|
|
|
* easily allow unreserved_keywords as optional aliases, but that'd be an odd
|
2015-05-20 20:50:22 +02:00
|
|
|
* divergence from other places. So just require AS for now.
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
*/
|
|
|
|
|
insert_target:
|
|
|
|
|
qualified_name
|
|
|
|
|
{
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
|
|
|
|
| qualified_name AS ColId
|
|
|
|
|
{
|
|
|
|
|
$1->alias = makeAlias($3, NIL);
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
insert_rest:
|
2006-08-02 03:59:48 +02:00
|
|
|
SelectStmt
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
1998-01-09 21:06:08 +01:00
|
|
|
$$ = makeNode(InsertStmt);
|
1999-07-20 02:18:01 +02:00
|
|
|
$$->cols = NIL;
|
2000-10-05 21:11:39 +02:00
|
|
|
$$->selectStmt = $1;
|
Hi!
INTERSECT and EXCEPT is available for postgresql-v6.4!
The patch against v6.4 is included at the end of the current text
(in uuencoded form!)
I also included the text of my Master's Thesis. (a postscript
version). I hope that you find something of it useful and would be
happy if parts of it find their way into the PostgreSQL documentation
project (If so, tell me, then I send the sources of the document!)
The contents of the document are:
-) The first chapter might be of less interest as it gives only an
overview on SQL.
-) The second chapter gives a description on much of PostgreSQL's
features (like user defined types etc. and how to use these features)
-) The third chapter starts with an overview of PostgreSQL's internal
structure with focus on the stages a query has to pass (i.e. parser,
planner/optimizer, executor). Then a detailed description of the
implementation of the Having clause and the Intersect/Except logic is
given.
Originally I worked on v6.3.2 but never found time enough to prepare
and post a patch. Now I applied the changes to v6.4 to get Intersect
and Except working with the new version. Chapter 3 of my documentation
deals with the changes against v6.3.2, so keep that in mind when
comparing the parts of the code printed there with the patched sources
of v6.4.
Here are some remarks on the patch. There are some things that have
still to be done but at the moment I don't have time to do them
myself. (I'm doing my military service at the moment) Sorry for that
:-(
-) I used a rewrite technique for the implementation of the Except/Intersect
logic which rewrites the query to a semantically equivalent query before
it is handed to the rewrite system (for views, rules etc.), planner,
executor etc.
-) In v6.3.2 the types of the attributes of two select statements
connected by the UNION keyword had to match 100%. In v6.4 the types
only need to be familiar (i.e. int and float can be mixed). Since this
feature did not exist when I worked on Intersect/Except it
does not work correctly for Except/Intersect queries WHEN USED IN
COMBINATION WITH UNIONS! (i.e. sometimes the wrong type is used for the
resulting table. This is because until now the types of the attributes of
the first select statement have been used for the resulting table.
When Intersects and/or Excepts are used in combination with Unions it
might happen, that the first select statement of the original query
appears at another position in the query which will be executed. The reason
for this is the technique used for the implementation of
Except/Intersect which does a query rewrite!)
NOTE: It is NOT broken for pure UNION queries and pure INTERSECT/EXCEPT
queries!!!
-) I had to add the field intersect_clause to some data structures
but did not find time to implement printfuncs for the new field.
This does NOT break the debug modes but when an Except/Intersect
is used the query debug output will be the already rewritten query.
-) Massive changes to the grammar rules for SELECT and INSERT statements
have been necessary (see comments in gram.y and documentation for
deatails) in order to be able to use mixed queries like
(SELECT ... UNION (SELECT ... EXCEPT SELECT)) INTERSECT SELECT...;
-) When using UNION/EXCEPT/INTERSECT you will get:
NOTICE: equal: "Don't know if nodes of type xxx are equal".
I did not have time to add comparsion support for all the needed nodes,
but the default behaviour of the function equal met my requirements.
I did not dare to supress this message!
That's the reason why the regression test for union will fail: These
messages are also included in the union.out file!
-) Somebody of you changed the union_planner() function for v6.4
(I copied the targetlist to new_tlist and that was removed and
replaced by a cleanup of the original targetlist). These chnages
violated some having queries executed against views so I changed
it back again. I did not have time to examine the differences between the
two versions but now it works :-)
If you want to find out, try the file queries/view_having.sql on
both versions and compare the results . Two queries won't produce a
correct result with your version.
regards
Stefan
1999-01-18 01:10:17 +01:00
|
|
|
}
|
2017-04-06 14:33:16 +02:00
|
|
|
| OVERRIDING override_kind VALUE_P SelectStmt
|
|
|
|
|
{
|
|
|
|
|
$$ = makeNode(InsertStmt);
|
|
|
|
|
$$->cols = NIL;
|
|
|
|
|
$$->override = $2;
|
|
|
|
|
$$->selectStmt = $4;
|
|
|
|
|
}
|
2006-08-02 03:59:48 +02:00
|
|
|
| '(' insert_column_list ')' SelectStmt
|
Hi!
INTERSECT and EXCEPT is available for postgresql-v6.4!
The patch against v6.4 is included at the end of the current text
(in uuencoded form!)
I also included the text of my Master's Thesis. (a postscript
version). I hope that you find something of it useful and would be
happy if parts of it find their way into the PostgreSQL documentation
project (If so, tell me, then I send the sources of the document!)
The contents of the document are:
-) The first chapter might be of less interest as it gives only an
overview on SQL.
-) The second chapter gives a description on much of PostgreSQL's
features (like user defined types etc. and how to use these features)
-) The third chapter starts with an overview of PostgreSQL's internal
structure with focus on the stages a query has to pass (i.e. parser,
planner/optimizer, executor). Then a detailed description of the
implementation of the Having clause and the Intersect/Except logic is
given.
Originally I worked on v6.3.2 but never found time enough to prepare
and post a patch. Now I applied the changes to v6.4 to get Intersect
and Except working with the new version. Chapter 3 of my documentation
deals with the changes against v6.3.2, so keep that in mind when
comparing the parts of the code printed there with the patched sources
of v6.4.
Here are some remarks on the patch. There are some things that have
still to be done but at the moment I don't have time to do them
myself. (I'm doing my military service at the moment) Sorry for that
:-(
-) I used a rewrite technique for the implementation of the Except/Intersect
logic which rewrites the query to a semantically equivalent query before
it is handed to the rewrite system (for views, rules etc.), planner,
executor etc.
-) In v6.3.2 the types of the attributes of two select statements
connected by the UNION keyword had to match 100%. In v6.4 the types
only need to be familiar (i.e. int and float can be mixed). Since this
feature did not exist when I worked on Intersect/Except it
does not work correctly for Except/Intersect queries WHEN USED IN
COMBINATION WITH UNIONS! (i.e. sometimes the wrong type is used for the
resulting table. This is because until now the types of the attributes of
the first select statement have been used for the resulting table.
When Intersects and/or Excepts are used in combination with Unions it
might happen, that the first select statement of the original query
appears at another position in the query which will be executed. The reason
for this is the technique used for the implementation of
Except/Intersect which does a query rewrite!)
NOTE: It is NOT broken for pure UNION queries and pure INTERSECT/EXCEPT
queries!!!
-) I had to add the field intersect_clause to some data structures
but did not find time to implement printfuncs for the new field.
This does NOT break the debug modes but when an Except/Intersect
is used the query debug output will be the already rewritten query.
-) Massive changes to the grammar rules for SELECT and INSERT statements
have been necessary (see comments in gram.y and documentation for
deatails) in order to be able to use mixed queries like
(SELECT ... UNION (SELECT ... EXCEPT SELECT)) INTERSECT SELECT...;
-) When using UNION/EXCEPT/INTERSECT you will get:
NOTICE: equal: "Don't know if nodes of type xxx are equal".
I did not have time to add comparsion support for all the needed nodes,
but the default behaviour of the function equal met my requirements.
I did not dare to supress this message!
That's the reason why the regression test for union will fail: These
messages are also included in the union.out file!
-) Somebody of you changed the union_planner() function for v6.4
(I copied the targetlist to new_tlist and that was removed and
replaced by a cleanup of the original targetlist). These chnages
violated some having queries executed against views so I changed
it back again. I did not have time to examine the differences between the
two versions but now it works :-)
If you want to find out, try the file queries/view_having.sql on
both versions and compare the results . Two queries won't produce a
correct result with your version.
regards
Stefan
1999-01-18 01:10:17 +01:00
|
|
|
{
|
|
|
|
|
$$ = makeNode(InsertStmt);
|
|
|
|
|
$$->cols = $2;
|
2006-08-02 03:59:48 +02:00
|
|
|
$$->selectStmt = $4;
|
Hi!
INTERSECT and EXCEPT is available for postgresql-v6.4!
The patch against v6.4 is included at the end of the current text
(in uuencoded form!)
I also included the text of my Master's Thesis. (a postscript
version). I hope that you find something of it useful and would be
happy if parts of it find their way into the PostgreSQL documentation
project (If so, tell me, then I send the sources of the document!)
The contents of the document are:
-) The first chapter might be of less interest as it gives only an
overview on SQL.
-) The second chapter gives a description on much of PostgreSQL's
features (like user defined types etc. and how to use these features)
-) The third chapter starts with an overview of PostgreSQL's internal
structure with focus on the stages a query has to pass (i.e. parser,
planner/optimizer, executor). Then a detailed description of the
implementation of the Having clause and the Intersect/Except logic is
given.
Originally I worked on v6.3.2 but never found time enough to prepare
and post a patch. Now I applied the changes to v6.4 to get Intersect
and Except working with the new version. Chapter 3 of my documentation
deals with the changes against v6.3.2, so keep that in mind when
comparing the parts of the code printed there with the patched sources
of v6.4.
Here are some remarks on the patch. There are some things that have
still to be done but at the moment I don't have time to do them
myself. (I'm doing my military service at the moment) Sorry for that
:-(
-) I used a rewrite technique for the implementation of the Except/Intersect
logic which rewrites the query to a semantically equivalent query before
it is handed to the rewrite system (for views, rules etc.), planner,
executor etc.
-) In v6.3.2 the types of the attributes of two select statements
connected by the UNION keyword had to match 100%. In v6.4 the types
only need to be familiar (i.e. int and float can be mixed). Since this
feature did not exist when I worked on Intersect/Except it
does not work correctly for Except/Intersect queries WHEN USED IN
COMBINATION WITH UNIONS! (i.e. sometimes the wrong type is used for the
resulting table. This is because until now the types of the attributes of
the first select statement have been used for the resulting table.
When Intersects and/or Excepts are used in combination with Unions it
might happen, that the first select statement of the original query
appears at another position in the query which will be executed. The reason
for this is the technique used for the implementation of
Except/Intersect which does a query rewrite!)
NOTE: It is NOT broken for pure UNION queries and pure INTERSECT/EXCEPT
queries!!!
-) I had to add the field intersect_clause to some data structures
but did not find time to implement printfuncs for the new field.
This does NOT break the debug modes but when an Except/Intersect
is used the query debug output will be the already rewritten query.
-) Massive changes to the grammar rules for SELECT and INSERT statements
have been necessary (see comments in gram.y and documentation for
deatails) in order to be able to use mixed queries like
(SELECT ... UNION (SELECT ... EXCEPT SELECT)) INTERSECT SELECT...;
-) When using UNION/EXCEPT/INTERSECT you will get:
NOTICE: equal: "Don't know if nodes of type xxx are equal".
I did not have time to add comparsion support for all the needed nodes,
but the default behaviour of the function equal met my requirements.
I did not dare to supress this message!
That's the reason why the regression test for union will fail: These
messages are also included in the union.out file!
-) Somebody of you changed the union_planner() function for v6.4
(I copied the targetlist to new_tlist and that was removed and
replaced by a cleanup of the original targetlist). These chnages
violated some having queries executed against views so I changed
it back again. I did not have time to examine the differences between the
two versions but now it works :-)
If you want to find out, try the file queries/view_having.sql on
both versions and compare the results . Two queries won't produce a
correct result with your version.
regards
Stefan
1999-01-18 01:10:17 +01:00
|
|
|
}
|
2017-04-06 14:33:16 +02:00
|
|
|
| '(' insert_column_list ')' OVERRIDING override_kind VALUE_P SelectStmt
|
|
|
|
|
{
|
|
|
|
|
$$ = makeNode(InsertStmt);
|
|
|
|
|
$$->cols = $2;
|
|
|
|
|
$$->override = $5;
|
|
|
|
|
$$->selectStmt = $7;
|
|
|
|
|
}
|
2006-08-02 03:59:48 +02:00
|
|
|
| DEFAULT VALUES
|
Hi!
INTERSECT and EXCEPT is available for postgresql-v6.4!
The patch against v6.4 is included at the end of the current text
(in uuencoded form!)
I also included the text of my Master's Thesis. (a postscript
version). I hope that you find something of it useful and would be
happy if parts of it find their way into the PostgreSQL documentation
project (If so, tell me, then I send the sources of the document!)
The contents of the document are:
-) The first chapter might be of less interest as it gives only an
overview on SQL.
-) The second chapter gives a description on much of PostgreSQL's
features (like user defined types etc. and how to use these features)
-) The third chapter starts with an overview of PostgreSQL's internal
structure with focus on the stages a query has to pass (i.e. parser,
planner/optimizer, executor). Then a detailed description of the
implementation of the Having clause and the Intersect/Except logic is
given.
Originally I worked on v6.3.2 but never found time enough to prepare
and post a patch. Now I applied the changes to v6.4 to get Intersect
and Except working with the new version. Chapter 3 of my documentation
deals with the changes against v6.3.2, so keep that in mind when
comparing the parts of the code printed there with the patched sources
of v6.4.
Here are some remarks on the patch. There are some things that have
still to be done but at the moment I don't have time to do them
myself. (I'm doing my military service at the moment) Sorry for that
:-(
-) I used a rewrite technique for the implementation of the Except/Intersect
logic which rewrites the query to a semantically equivalent query before
it is handed to the rewrite system (for views, rules etc.), planner,
executor etc.
-) In v6.3.2 the types of the attributes of two select statements
connected by the UNION keyword had to match 100%. In v6.4 the types
only need to be familiar (i.e. int and float can be mixed). Since this
feature did not exist when I worked on Intersect/Except it
does not work correctly for Except/Intersect queries WHEN USED IN
COMBINATION WITH UNIONS! (i.e. sometimes the wrong type is used for the
resulting table. This is because until now the types of the attributes of
the first select statement have been used for the resulting table.
When Intersects and/or Excepts are used in combination with Unions it
might happen, that the first select statement of the original query
appears at another position in the query which will be executed. The reason
for this is the technique used for the implementation of
Except/Intersect which does a query rewrite!)
NOTE: It is NOT broken for pure UNION queries and pure INTERSECT/EXCEPT
queries!!!
-) I had to add the field intersect_clause to some data structures
but did not find time to implement printfuncs for the new field.
This does NOT break the debug modes but when an Except/Intersect
is used the query debug output will be the already rewritten query.
-) Massive changes to the grammar rules for SELECT and INSERT statements
have been necessary (see comments in gram.y and documentation for
deatails) in order to be able to use mixed queries like
(SELECT ... UNION (SELECT ... EXCEPT SELECT)) INTERSECT SELECT...;
-) When using UNION/EXCEPT/INTERSECT you will get:
NOTICE: equal: "Don't know if nodes of type xxx are equal".
I did not have time to add comparsion support for all the needed nodes,
but the default behaviour of the function equal met my requirements.
I did not dare to supress this message!
That's the reason why the regression test for union will fail: These
messages are also included in the union.out file!
-) Somebody of you changed the union_planner() function for v6.4
(I copied the targetlist to new_tlist and that was removed and
replaced by a cleanup of the original targetlist). These chnages
violated some having queries executed against views so I changed
it back again. I did not have time to examine the differences between the
two versions but now it works :-)
If you want to find out, try the file queries/view_having.sql on
both versions and compare the results . Two queries won't produce a
correct result with your version.
regards
Stefan
1999-01-18 01:10:17 +01:00
|
|
|
{
|
|
|
|
|
$$ = makeNode(InsertStmt);
|
2006-08-02 03:59:48 +02:00
|
|
|
$$->cols = NIL;
|
|
|
|
|
$$->selectStmt = NULL;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2017-04-06 14:33:16 +02:00
|
|
|
override_kind:
|
|
|
|
|
USER { $$ = OVERRIDING_USER_VALUE; }
|
|
|
|
|
| SYSTEM_P { $$ = OVERRIDING_SYSTEM_VALUE; }
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
insert_column_list:
|
2004-06-09 21:08:20 +02:00
|
|
|
insert_column_item
|
|
|
|
|
{ $$ = list_make1($1); }
|
2002-06-18 19:56:41 +02:00
|
|
|
| insert_column_list ',' insert_column_item
|
|
|
|
|
{ $$ = lappend($1, $3); }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
insert_column_item:
|
|
|
|
|
ColId opt_indirection
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2004-06-09 21:08:20 +02:00
|
|
|
$$ = makeNode(ResTarget);
|
|
|
|
|
$$->name = $1;
|
2009-07-13 04:02:20 +02:00
|
|
|
$$->indirection = check_indirection($2, yyscanner);
|
2004-06-09 21:08:20 +02:00
|
|
|
$$->val = NULL;
|
2006-03-23 01:19:30 +01:00
|
|
|
$$->location = @1;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
|
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
opt_on_conflict:
|
|
|
|
|
ON CONFLICT opt_conf_expr DO UPDATE SET set_clause_list where_clause
|
|
|
|
|
{
|
|
|
|
|
$$ = makeNode(OnConflictClause);
|
|
|
|
|
$$->action = ONCONFLICT_UPDATE;
|
|
|
|
|
$$->infer = $3;
|
|
|
|
|
$$->targetList = $7;
|
|
|
|
|
$$->whereClause = $8;
|
|
|
|
|
$$->location = @1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
ON CONFLICT opt_conf_expr DO NOTHING
|
|
|
|
|
{
|
|
|
|
|
$$ = makeNode(OnConflictClause);
|
|
|
|
|
$$->action = ONCONFLICT_NOTHING;
|
|
|
|
|
$$->infer = $3;
|
|
|
|
|
$$->targetList = NIL;
|
|
|
|
|
$$->whereClause = NULL;
|
|
|
|
|
$$->location = @1;
|
|
|
|
|
}
|
|
|
|
|
| /*EMPTY*/
|
|
|
|
|
{
|
|
|
|
|
$$ = NULL;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_conf_expr:
|
|
|
|
|
'(' index_params ')' where_clause
|
|
|
|
|
{
|
|
|
|
|
$$ = makeNode(InferClause);
|
|
|
|
|
$$->indexElems = $2;
|
|
|
|
|
$$->whereClause = $4;
|
|
|
|
|
$$->conname = NULL;
|
|
|
|
|
$$->location = @1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
ON CONSTRAINT name
|
|
|
|
|
{
|
|
|
|
|
$$ = makeNode(InferClause);
|
|
|
|
|
$$->indexElems = NIL;
|
|
|
|
|
$$->whereClause = NULL;
|
|
|
|
|
$$->conname = $3;
|
|
|
|
|
$$->location = @1;
|
|
|
|
|
}
|
|
|
|
|
| /*EMPTY*/
|
|
|
|
|
{
|
|
|
|
|
$$ = NULL;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2006-08-12 04:52:06 +02:00
|
|
|
returning_clause:
|
|
|
|
|
RETURNING target_list { $$ = $2; }
|
|
|
|
|
| /* EMPTY */ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
1997-10-25 07:56:41 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* QUERY:
|
|
|
|
|
* DELETE STATEMENTS
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
1997-09-01 08:00:35 +02:00
|
|
|
|
2010-10-16 01:53:59 +02:00
|
|
|
DeleteStmt: opt_with_clause DELETE_P FROM relation_expr_opt_alias
|
2007-06-11 03:16:30 +02:00
|
|
|
using_clause where_or_current_clause returning_clause
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
|
|
|
|
DeleteStmt *n = makeNode(DeleteStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-10-16 01:53:59 +02:00
|
|
|
n->relation = $4;
|
|
|
|
|
n->usingClause = $5;
|
|
|
|
|
n->whereClause = $6;
|
|
|
|
|
n->returningList = $7;
|
|
|
|
|
n->withClause = $1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
|
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2005-04-07 03:51:41 +02:00
|
|
|
using_clause:
|
2011-11-01 20:50:00 +01:00
|
|
|
USING from_list { $$ = $2; }
|
2005-04-07 03:51:41 +02:00
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
2009-01-12 09:54:27 +01:00
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* QUERY:
|
|
|
|
|
* LOCK TABLE
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
LockStmt: LOCK_P opt_table relation_expr_list opt_lock opt_nowait
|
1998-01-23 00:05:18 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
LockStmt *n = makeNode(LockStmt);
|
1998-12-18 10:10:39 +01:00
|
|
|
|
2002-03-21 17:02:16 +01:00
|
|
|
n->relations = $3;
|
1999-05-17 03:01:06 +02:00
|
|
|
n->mode = $4;
|
2004-03-11 02:47:41 +01:00
|
|
|
n->nowait = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1998-12-18 10:10:39 +01:00
|
|
|
}
|
1999-05-12 09:22:52 +02:00
|
|
|
;
|
1998-12-18 10:10:39 +01:00
|
|
|
|
2011-11-01 20:50:00 +01:00
|
|
|
opt_lock: IN_P lock_type MODE { $$ = $2; }
|
2002-06-18 19:56:41 +02:00
|
|
|
| /*EMPTY*/ { $$ = AccessExclusiveLock; }
|
1999-05-12 09:22:52 +02:00
|
|
|
;
|
1998-01-23 00:05:18 +01:00
|
|
|
|
2002-06-18 19:56:41 +02:00
|
|
|
lock_type: ACCESS SHARE { $$ = AccessShareLock; }
|
|
|
|
|
| ROW SHARE { $$ = RowShareLock; }
|
|
|
|
|
| ROW EXCLUSIVE { $$ = RowExclusiveLock; }
|
|
|
|
|
| SHARE UPDATE EXCLUSIVE { $$ = ShareUpdateExclusiveLock; }
|
|
|
|
|
| SHARE { $$ = ShareLock; }
|
|
|
|
|
| SHARE ROW EXCLUSIVE { $$ = ShareRowExclusiveLock; }
|
|
|
|
|
| EXCLUSIVE { $$ = ExclusiveLock; }
|
|
|
|
|
| ACCESS EXCLUSIVE { $$ = AccessExclusiveLock; }
|
1998-12-18 10:10:39 +01:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
opt_nowait: NOWAIT { $$ = true; }
|
|
|
|
|
| /*EMPTY*/ { $$ = false; }
|
2004-03-11 02:47:41 +01:00
|
|
|
;
|
|
|
|
|
|
2014-10-07 22:23:34 +02:00
|
|
|
opt_nowait_or_skip:
|
|
|
|
|
NOWAIT { $$ = LockWaitError; }
|
|
|
|
|
| SKIP LOCKED { $$ = LockWaitSkip; }
|
|
|
|
|
| /*EMPTY*/ { $$ = LockWaitBlock; }
|
|
|
|
|
;
|
|
|
|
|
|
1999-05-12 09:22:52 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* QUERY:
|
1998-01-09 21:06:08 +01:00
|
|
|
* UpdateStmt (UPDATE)
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2010-10-16 01:53:59 +02:00
|
|
|
UpdateStmt: opt_with_clause UPDATE relation_expr_opt_alias
|
2006-09-04 00:37:06 +02:00
|
|
|
SET set_clause_list
|
2006-09-02 22:34:47 +02:00
|
|
|
from_clause
|
2007-06-11 03:16:30 +02:00
|
|
|
where_or_current_clause
|
2006-09-02 22:34:47 +02:00
|
|
|
returning_clause
|
|
|
|
|
{
|
|
|
|
|
UpdateStmt *n = makeNode(UpdateStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-10-16 01:53:59 +02:00
|
|
|
n->relation = $3;
|
|
|
|
|
n->targetList = $5;
|
|
|
|
|
n->fromClause = $6;
|
|
|
|
|
n->whereClause = $7;
|
|
|
|
|
n->returningList = $8;
|
|
|
|
|
n->withClause = $1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2006-09-02 22:34:47 +02:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1997-09-01 08:00:35 +02:00
|
|
|
|
2006-09-04 00:37:06 +02:00
|
|
|
set_clause_list:
|
|
|
|
|
set_clause { $$ = $1; }
|
|
|
|
|
| set_clause_list ',' set_clause { $$ = list_concat($1,$3); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
set_clause:
|
Improve handling of "UPDATE ... SET (column_list) = row_constructor".
Previously, the right-hand side of a multiple-column assignment, if it
wasn't a sub-SELECT, had to be a simple parenthesized expression list,
because gram.y was responsible for "bursting" the construct into
independent column assignments. This had the minor defect that you
couldn't write ROW (though you should be able to, since the standard says
this is a row constructor), and the rather larger defect that unlike other
uses of row constructors, we would not expand a "foo.*" item into multiple
columns.
Fix that by changing the RHS to be just "a_expr" in the grammar, leaving
it to transformMultiAssignRef to separate the elements of a RowExpr;
which it will do only after performing standard transformation of the
RowExpr, so that "foo.*" behaves as expected.
The key reason we didn't do that before was the hard-wired handling of
DEFAULT tokens (SetToDefault nodes). This patch deals with that issue by
allowing DEFAULT in any a_expr and having parse analysis throw an error
if SetToDefault is found in an unexpected place. That's an improvement
anyway since the error can be more specific than just "syntax error".
The SQL standard suggests that the RHS could be any a_expr yielding a
suitable row value. This patch doesn't really move the goal posts in that
respect --- you're still limited to RowExpr or a sub-SELECT --- but it does
fix the grammar restriction, so it provides some tangible progress towards
a full implementation. And the limitation is now documented by an explicit
error message rather than an unhelpful "syntax error".
Discussion: <8542.1479742008@sss.pgh.pa.us>
2016-11-22 21:19:57 +01:00
|
|
|
set_target '=' a_expr
|
2006-09-04 00:37:06 +02:00
|
|
|
{
|
Improve handling of "UPDATE ... SET (column_list) = row_constructor".
Previously, the right-hand side of a multiple-column assignment, if it
wasn't a sub-SELECT, had to be a simple parenthesized expression list,
because gram.y was responsible for "bursting" the construct into
independent column assignments. This had the minor defect that you
couldn't write ROW (though you should be able to, since the standard says
this is a row constructor), and the rather larger defect that unlike other
uses of row constructors, we would not expand a "foo.*" item into multiple
columns.
Fix that by changing the RHS to be just "a_expr" in the grammar, leaving
it to transformMultiAssignRef to separate the elements of a RowExpr;
which it will do only after performing standard transformation of the
RowExpr, so that "foo.*" behaves as expected.
The key reason we didn't do that before was the hard-wired handling of
DEFAULT tokens (SetToDefault nodes). This patch deals with that issue by
allowing DEFAULT in any a_expr and having parse analysis throw an error
if SetToDefault is found in an unexpected place. That's an improvement
anyway since the error can be more specific than just "syntax error".
The SQL standard suggests that the RHS could be any a_expr yielding a
suitable row value. This patch doesn't really move the goal posts in that
respect --- you're still limited to RowExpr or a sub-SELECT --- but it does
fix the grammar restriction, so it provides some tangible progress towards
a full implementation. And the limitation is now documented by an explicit
error message rather than an unhelpful "syntax error".
Discussion: <8542.1479742008@sss.pgh.pa.us>
2016-11-22 21:19:57 +01:00
|
|
|
$1->val = (Node *) $3;
|
|
|
|
|
$$ = list_make1($1);
|
Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...
This SQL-standard feature allows a sub-SELECT yielding multiple columns
(but only one row) to be used to compute the new values of several columns
to be updated. While the same results can be had with an independent
sub-SELECT per column, such a workaround can require a great deal of
duplicated computation.
The standard actually says that the source for a multi-column assignment
could be any row-valued expression. The implementation used here is
tightly tied to our existing sub-SELECT support and can't handle other
cases; the Bison grammar would have some issues with them too. However,
I don't feel too bad about this since other cases can be converted into
sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could
be written "SET (a,b,c) = (SELECT * FROM row_valued_function(x))".
2014-06-18 19:22:25 +02:00
|
|
|
}
|
Improve handling of "UPDATE ... SET (column_list) = row_constructor".
Previously, the right-hand side of a multiple-column assignment, if it
wasn't a sub-SELECT, had to be a simple parenthesized expression list,
because gram.y was responsible for "bursting" the construct into
independent column assignments. This had the minor defect that you
couldn't write ROW (though you should be able to, since the standard says
this is a row constructor), and the rather larger defect that unlike other
uses of row constructors, we would not expand a "foo.*" item into multiple
columns.
Fix that by changing the RHS to be just "a_expr" in the grammar, leaving
it to transformMultiAssignRef to separate the elements of a RowExpr;
which it will do only after performing standard transformation of the
RowExpr, so that "foo.*" behaves as expected.
The key reason we didn't do that before was the hard-wired handling of
DEFAULT tokens (SetToDefault nodes). This patch deals with that issue by
allowing DEFAULT in any a_expr and having parse analysis throw an error
if SetToDefault is found in an unexpected place. That's an improvement
anyway since the error can be more specific than just "syntax error".
The SQL standard suggests that the RHS could be any a_expr yielding a
suitable row value. This patch doesn't really move the goal posts in that
respect --- you're still limited to RowExpr or a sub-SELECT --- but it does
fix the grammar restriction, so it provides some tangible progress towards
a full implementation. And the limitation is now documented by an explicit
error message rather than an unhelpful "syntax error".
Discussion: <8542.1479742008@sss.pgh.pa.us>
2016-11-22 21:19:57 +01:00
|
|
|
| '(' set_target_list ')' '=' a_expr
|
Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...
This SQL-standard feature allows a sub-SELECT yielding multiple columns
(but only one row) to be used to compute the new values of several columns
to be updated. While the same results can be had with an independent
sub-SELECT per column, such a workaround can require a great deal of
duplicated computation.
The standard actually says that the source for a multi-column assignment
could be any row-valued expression. The implementation used here is
tightly tied to our existing sub-SELECT support and can't handle other
cases; the Bison grammar would have some issues with them too. However,
I don't feel too bad about this since other cases can be converted into
sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could
be written "SET (a,b,c) = (SELECT * FROM row_valued_function(x))".
2014-06-18 19:22:25 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
int ncolumns = list_length($2);
|
|
|
|
|
int i = 1;
|
|
|
|
|
ListCell *col_cell;
|
Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...
This SQL-standard feature allows a sub-SELECT yielding multiple columns
(but only one row) to be used to compute the new values of several columns
to be updated. While the same results can be had with an independent
sub-SELECT per column, such a workaround can require a great deal of
duplicated computation.
The standard actually says that the source for a multi-column assignment
could be any row-valued expression. The implementation used here is
tightly tied to our existing sub-SELECT support and can't handle other
cases; the Bison grammar would have some issues with them too. However,
I don't feel too bad about this since other cases can be converted into
sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could
be written "SET (a,b,c) = (SELECT * FROM row_valued_function(x))".
2014-06-18 19:22:25 +02:00
|
|
|
|
|
|
|
|
/* Create a MultiAssignRef source for each target */
|
|
|
|
|
foreach(col_cell, $2)
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
ResTarget *res_col = (ResTarget *) lfirst(col_cell);
|
Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...
This SQL-standard feature allows a sub-SELECT yielding multiple columns
(but only one row) to be used to compute the new values of several columns
to be updated. While the same results can be had with an independent
sub-SELECT per column, such a workaround can require a great deal of
duplicated computation.
The standard actually says that the source for a multi-column assignment
could be any row-valued expression. The implementation used here is
tightly tied to our existing sub-SELECT support and can't handle other
cases; the Bison grammar would have some issues with them too. However,
I don't feel too bad about this since other cases can be converted into
sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could
be written "SET (a,b,c) = (SELECT * FROM row_valued_function(x))".
2014-06-18 19:22:25 +02:00
|
|
|
MultiAssignRef *r = makeNode(MultiAssignRef);
|
|
|
|
|
|
Improve handling of "UPDATE ... SET (column_list) = row_constructor".
Previously, the right-hand side of a multiple-column assignment, if it
wasn't a sub-SELECT, had to be a simple parenthesized expression list,
because gram.y was responsible for "bursting" the construct into
independent column assignments. This had the minor defect that you
couldn't write ROW (though you should be able to, since the standard says
this is a row constructor), and the rather larger defect that unlike other
uses of row constructors, we would not expand a "foo.*" item into multiple
columns.
Fix that by changing the RHS to be just "a_expr" in the grammar, leaving
it to transformMultiAssignRef to separate the elements of a RowExpr;
which it will do only after performing standard transformation of the
RowExpr, so that "foo.*" behaves as expected.
The key reason we didn't do that before was the hard-wired handling of
DEFAULT tokens (SetToDefault nodes). This patch deals with that issue by
allowing DEFAULT in any a_expr and having parse analysis throw an error
if SetToDefault is found in an unexpected place. That's an improvement
anyway since the error can be more specific than just "syntax error".
The SQL standard suggests that the RHS could be any a_expr yielding a
suitable row value. This patch doesn't really move the goal posts in that
respect --- you're still limited to RowExpr or a sub-SELECT --- but it does
fix the grammar restriction, so it provides some tangible progress towards
a full implementation. And the limitation is now documented by an explicit
error message rather than an unhelpful "syntax error".
Discussion: <8542.1479742008@sss.pgh.pa.us>
2016-11-22 21:19:57 +01:00
|
|
|
r->source = (Node *) $5;
|
Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...
This SQL-standard feature allows a sub-SELECT yielding multiple columns
(but only one row) to be used to compute the new values of several columns
to be updated. While the same results can be had with an independent
sub-SELECT per column, such a workaround can require a great deal of
duplicated computation.
The standard actually says that the source for a multi-column assignment
could be any row-valued expression. The implementation used here is
tightly tied to our existing sub-SELECT support and can't handle other
cases; the Bison grammar would have some issues with them too. However,
I don't feel too bad about this since other cases can be converted into
sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could
be written "SET (a,b,c) = (SELECT * FROM row_valued_function(x))".
2014-06-18 19:22:25 +02:00
|
|
|
r->colno = i;
|
|
|
|
|
r->ncolumns = ncolumns;
|
|
|
|
|
res_col->val = (Node *) r;
|
|
|
|
|
i++;
|
|
|
|
|
}
|
|
|
|
|
|
2006-09-04 00:37:06 +02:00
|
|
|
$$ = $2;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
set_target:
|
|
|
|
|
ColId opt_indirection
|
|
|
|
|
{
|
|
|
|
|
$$ = makeNode(ResTarget);
|
|
|
|
|
$$->name = $1;
|
2009-07-13 04:02:20 +02:00
|
|
|
$$->indirection = check_indirection($2, yyscanner);
|
2006-09-04 00:37:06 +02:00
|
|
|
$$->val = NULL; /* upper production sets this */
|
|
|
|
|
$$->location = @1;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
set_target_list:
|
|
|
|
|
set_target { $$ = list_make1($1); }
|
|
|
|
|
| set_target_list ',' set_target { $$ = lappend($1,$3); }
|
2006-09-02 22:52:01 +02:00
|
|
|
;
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2022-03-28 16:45:58 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* QUERY:
|
|
|
|
|
* MERGE
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
MergeStmt:
|
|
|
|
|
opt_with_clause MERGE INTO relation_expr_opt_alias
|
|
|
|
|
USING table_ref
|
|
|
|
|
ON a_expr
|
|
|
|
|
merge_when_list
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
MergeStmt *m = makeNode(MergeStmt);
|
2022-03-28 16:45:58 +02:00
|
|
|
|
|
|
|
|
m->withClause = $1;
|
|
|
|
|
m->relation = $4;
|
|
|
|
|
m->sourceRelation = $6;
|
|
|
|
|
m->joinCondition = $8;
|
|
|
|
|
m->mergeWhenClauses = $9;
|
|
|
|
|
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) m;
|
2022-03-28 16:45:58 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
merge_when_list:
|
|
|
|
|
merge_when_clause { $$ = list_make1($1); }
|
|
|
|
|
| merge_when_list merge_when_clause { $$ = lappend($1,$2); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
merge_when_clause:
|
|
|
|
|
WHEN MATCHED opt_merge_when_condition THEN merge_update
|
|
|
|
|
{
|
|
|
|
|
$5->matched = true;
|
|
|
|
|
$5->condition = $3;
|
|
|
|
|
|
|
|
|
|
$$ = (Node *) $5;
|
|
|
|
|
}
|
|
|
|
|
| WHEN MATCHED opt_merge_when_condition THEN merge_delete
|
|
|
|
|
{
|
|
|
|
|
$5->matched = true;
|
|
|
|
|
$5->condition = $3;
|
|
|
|
|
|
|
|
|
|
$$ = (Node *) $5;
|
|
|
|
|
}
|
|
|
|
|
| WHEN NOT MATCHED opt_merge_when_condition THEN merge_insert
|
|
|
|
|
{
|
|
|
|
|
$6->matched = false;
|
|
|
|
|
$6->condition = $4;
|
|
|
|
|
|
|
|
|
|
$$ = (Node *) $6;
|
|
|
|
|
}
|
|
|
|
|
| WHEN MATCHED opt_merge_when_condition THEN DO NOTHING
|
|
|
|
|
{
|
|
|
|
|
MergeWhenClause *m = makeNode(MergeWhenClause);
|
|
|
|
|
|
|
|
|
|
m->matched = true;
|
|
|
|
|
m->commandType = CMD_NOTHING;
|
|
|
|
|
m->condition = $3;
|
|
|
|
|
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) m;
|
2022-03-28 16:45:58 +02:00
|
|
|
}
|
|
|
|
|
| WHEN NOT MATCHED opt_merge_when_condition THEN DO NOTHING
|
|
|
|
|
{
|
|
|
|
|
MergeWhenClause *m = makeNode(MergeWhenClause);
|
|
|
|
|
|
|
|
|
|
m->matched = false;
|
|
|
|
|
m->commandType = CMD_NOTHING;
|
|
|
|
|
m->condition = $4;
|
|
|
|
|
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) m;
|
2022-03-28 16:45:58 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_merge_when_condition:
|
|
|
|
|
AND a_expr { $$ = $2; }
|
|
|
|
|
| { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
merge_update:
|
|
|
|
|
UPDATE SET set_clause_list
|
|
|
|
|
{
|
|
|
|
|
MergeWhenClause *n = makeNode(MergeWhenClause);
|
|
|
|
|
n->commandType = CMD_UPDATE;
|
|
|
|
|
n->override = OVERRIDING_NOT_SET;
|
|
|
|
|
n->targetList = $3;
|
|
|
|
|
n->values = NIL;
|
|
|
|
|
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
merge_delete:
|
|
|
|
|
DELETE_P
|
|
|
|
|
{
|
|
|
|
|
MergeWhenClause *n = makeNode(MergeWhenClause);
|
|
|
|
|
n->commandType = CMD_DELETE;
|
|
|
|
|
n->override = OVERRIDING_NOT_SET;
|
|
|
|
|
n->targetList = NIL;
|
|
|
|
|
n->values = NIL;
|
|
|
|
|
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
merge_insert:
|
|
|
|
|
INSERT merge_values_clause
|
|
|
|
|
{
|
|
|
|
|
MergeWhenClause *n = makeNode(MergeWhenClause);
|
|
|
|
|
n->commandType = CMD_INSERT;
|
|
|
|
|
n->override = OVERRIDING_NOT_SET;
|
|
|
|
|
n->targetList = NIL;
|
|
|
|
|
n->values = $2;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| INSERT OVERRIDING override_kind VALUE_P merge_values_clause
|
|
|
|
|
{
|
|
|
|
|
MergeWhenClause *n = makeNode(MergeWhenClause);
|
|
|
|
|
n->commandType = CMD_INSERT;
|
|
|
|
|
n->override = $3;
|
|
|
|
|
n->targetList = NIL;
|
|
|
|
|
n->values = $5;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| INSERT '(' insert_column_list ')' merge_values_clause
|
|
|
|
|
{
|
|
|
|
|
MergeWhenClause *n = makeNode(MergeWhenClause);
|
|
|
|
|
n->commandType = CMD_INSERT;
|
|
|
|
|
n->override = OVERRIDING_NOT_SET;
|
|
|
|
|
n->targetList = $3;
|
|
|
|
|
n->values = $5;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| INSERT '(' insert_column_list ')' OVERRIDING override_kind VALUE_P merge_values_clause
|
|
|
|
|
{
|
|
|
|
|
MergeWhenClause *n = makeNode(MergeWhenClause);
|
|
|
|
|
n->commandType = CMD_INSERT;
|
|
|
|
|
n->override = $6;
|
|
|
|
|
n->targetList = $3;
|
|
|
|
|
n->values = $8;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| INSERT DEFAULT VALUES
|
|
|
|
|
{
|
|
|
|
|
MergeWhenClause *n = makeNode(MergeWhenClause);
|
|
|
|
|
n->commandType = CMD_INSERT;
|
|
|
|
|
n->override = OVERRIDING_NOT_SET;
|
|
|
|
|
n->targetList = NIL;
|
|
|
|
|
n->values = NIL;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
merge_values_clause:
|
|
|
|
|
VALUES '(' expr_list ')'
|
|
|
|
|
{
|
|
|
|
|
$$ = $3;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* QUERY:
|
|
|
|
|
* CURSOR STATEMENTS
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
2009-11-11 21:31:26 +01:00
|
|
|
DeclareCursorStmt: DECLARE cursor_name cursor_options CURSOR opt_hold FOR SelectStmt
|
2002-06-17 22:27:43 +02:00
|
|
|
{
|
2003-03-10 04:53:52 +01:00
|
|
|
DeclareCursorStmt *n = makeNode(DeclareCursorStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
1997-09-08 05:20:18 +02:00
|
|
|
n->portalname = $2;
|
2007-04-16 03:14:58 +02:00
|
|
|
/* currently we always set FAST_PLAN option */
|
|
|
|
|
n->options = $3 | $5 | CURSOR_OPT_FAST_PLAN;
|
This patch implements holdable cursors, following the proposal
(materialization into a tuple store) discussed on pgsql-hackers earlier.
I've updated the documentation and the regression tests.
Notes on the implementation:
- I needed to change the tuple store API slightly -- it assumes that it
won't be used to hold data across transaction boundaries, so the temp
files that it uses for on-disk storage are automatically reclaimed at
end-of-transaction. I added a flag to tuplestore_begin_heap() to control
this behavior. Is changing the tuple store API in this fashion OK?
- in order to store executor results in a tuple store, I added a new
CommandDest. This works well for the most part, with one exception: the
current DestFunction API doesn't provide enough information to allow the
Executor to store results into an arbitrary tuple store (where the
particular tuple store to use is chosen by the call site of
ExecutorRun). To workaround this, I've temporarily hacked up a solution
that works, but is not ideal: since the receiveTuple DestFunction is
passed the portal name, we can use that to lookup the Portal data
structure for the cursor and then use that to get at the tuple store the
Portal is using. This unnecessarily ties the Portal code with the
tupleReceiver code, but it works...
The proper fix for this is probably to change the DestFunction API --
Tom suggested passing the full QueryDesc to the receiveTuple function.
In that case, callers of ExecutorRun could "subclass" QueryDesc to add
any additional fields that their particular CommandDest needed to get
access to. This approach would work, but I'd like to think about it for
a little bit longer before deciding which route to go. In the mean time,
the code works fine, so I don't think a fix is urgent.
- (semi-related) I added a NO SCROLL keyword to DECLARE CURSOR, and
adjusted the behavior of SCROLL in accordance with the discussion on
-hackers.
- (unrelated) Cleaned up some SGML markup in sql.sgml, copy.sgml
Neil Conway
2003-03-27 17:51:29 +01:00
|
|
|
n->query = $7;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
|
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2009-11-11 21:31:26 +01:00
|
|
|
cursor_name: name { $$ = $1; }
|
|
|
|
|
;
|
|
|
|
|
|
2003-03-10 04:53:52 +01:00
|
|
|
cursor_options: /*EMPTY*/ { $$ = 0; }
|
This patch implements holdable cursors, following the proposal
(materialization into a tuple store) discussed on pgsql-hackers earlier.
I've updated the documentation and the regression tests.
Notes on the implementation:
- I needed to change the tuple store API slightly -- it assumes that it
won't be used to hold data across transaction boundaries, so the temp
files that it uses for on-disk storage are automatically reclaimed at
end-of-transaction. I added a flag to tuplestore_begin_heap() to control
this behavior. Is changing the tuple store API in this fashion OK?
- in order to store executor results in a tuple store, I added a new
CommandDest. This works well for the most part, with one exception: the
current DestFunction API doesn't provide enough information to allow the
Executor to store results into an arbitrary tuple store (where the
particular tuple store to use is chosen by the call site of
ExecutorRun). To workaround this, I've temporarily hacked up a solution
that works, but is not ideal: since the receiveTuple DestFunction is
passed the portal name, we can use that to lookup the Portal data
structure for the cursor and then use that to get at the tuple store the
Portal is using. This unnecessarily ties the Portal code with the
tupleReceiver code, but it works...
The proper fix for this is probably to change the DestFunction API --
Tom suggested passing the full QueryDesc to the receiveTuple function.
In that case, callers of ExecutorRun could "subclass" QueryDesc to add
any additional fields that their particular CommandDest needed to get
access to. This approach would work, but I'd like to think about it for
a little bit longer before deciding which route to go. In the mean time,
the code works fine, so I don't think a fix is urgent.
- (semi-related) I added a NO SCROLL keyword to DECLARE CURSOR, and
adjusted the behavior of SCROLL in accordance with the discussion on
-hackers.
- (unrelated) Cleaned up some SGML markup in sql.sgml, copy.sgml
Neil Conway
2003-03-27 17:51:29 +01:00
|
|
|
| cursor_options NO SCROLL { $$ = $1 | CURSOR_OPT_NO_SCROLL; }
|
2003-03-10 04:53:52 +01:00
|
|
|
| cursor_options SCROLL { $$ = $1 | CURSOR_OPT_SCROLL; }
|
This patch implements holdable cursors, following the proposal
(materialization into a tuple store) discussed on pgsql-hackers earlier.
I've updated the documentation and the regression tests.
Notes on the implementation:
- I needed to change the tuple store API slightly -- it assumes that it
won't be used to hold data across transaction boundaries, so the temp
files that it uses for on-disk storage are automatically reclaimed at
end-of-transaction. I added a flag to tuplestore_begin_heap() to control
this behavior. Is changing the tuple store API in this fashion OK?
- in order to store executor results in a tuple store, I added a new
CommandDest. This works well for the most part, with one exception: the
current DestFunction API doesn't provide enough information to allow the
Executor to store results into an arbitrary tuple store (where the
particular tuple store to use is chosen by the call site of
ExecutorRun). To workaround this, I've temporarily hacked up a solution
that works, but is not ideal: since the receiveTuple DestFunction is
passed the portal name, we can use that to lookup the Portal data
structure for the cursor and then use that to get at the tuple store the
Portal is using. This unnecessarily ties the Portal code with the
tupleReceiver code, but it works...
The proper fix for this is probably to change the DestFunction API --
Tom suggested passing the full QueryDesc to the receiveTuple function.
In that case, callers of ExecutorRun could "subclass" QueryDesc to add
any additional fields that their particular CommandDest needed to get
access to. This approach would work, but I'd like to think about it for
a little bit longer before deciding which route to go. In the mean time,
the code works fine, so I don't think a fix is urgent.
- (semi-related) I added a NO SCROLL keyword to DECLARE CURSOR, and
adjusted the behavior of SCROLL in accordance with the discussion on
-hackers.
- (unrelated) Cleaned up some SGML markup in sql.sgml, copy.sgml
Neil Conway
2003-03-27 17:51:29 +01:00
|
|
|
| cursor_options BINARY { $$ = $1 | CURSOR_OPT_BINARY; }
|
2021-04-07 07:49:27 +02:00
|
|
|
| cursor_options ASENSITIVE { $$ = $1 | CURSOR_OPT_ASENSITIVE; }
|
2003-03-10 04:53:52 +01:00
|
|
|
| cursor_options INSENSITIVE { $$ = $1 | CURSOR_OPT_INSENSITIVE; }
|
1998-09-13 06:19:33 +02:00
|
|
|
;
|
|
|
|
|
|
2007-04-16 03:14:58 +02:00
|
|
|
opt_hold: /* EMPTY */ { $$ = 0; }
|
|
|
|
|
| WITH HOLD { $$ = CURSOR_OPT_HOLD; }
|
|
|
|
|
| WITHOUT HOLD { $$ = 0; }
|
2003-04-02 01:42:55 +02:00
|
|
|
;
|
This patch implements holdable cursors, following the proposal
(materialization into a tuple store) discussed on pgsql-hackers earlier.
I've updated the documentation and the regression tests.
Notes on the implementation:
- I needed to change the tuple store API slightly -- it assumes that it
won't be used to hold data across transaction boundaries, so the temp
files that it uses for on-disk storage are automatically reclaimed at
end-of-transaction. I added a flag to tuplestore_begin_heap() to control
this behavior. Is changing the tuple store API in this fashion OK?
- in order to store executor results in a tuple store, I added a new
CommandDest. This works well for the most part, with one exception: the
current DestFunction API doesn't provide enough information to allow the
Executor to store results into an arbitrary tuple store (where the
particular tuple store to use is chosen by the call site of
ExecutorRun). To workaround this, I've temporarily hacked up a solution
that works, but is not ideal: since the receiveTuple DestFunction is
passed the portal name, we can use that to lookup the Portal data
structure for the cursor and then use that to get at the tuple store the
Portal is using. This unnecessarily ties the Portal code with the
tupleReceiver code, but it works...
The proper fix for this is probably to change the DestFunction API --
Tom suggested passing the full QueryDesc to the receiveTuple function.
In that case, callers of ExecutorRun could "subclass" QueryDesc to add
any additional fields that their particular CommandDest needed to get
access to. This approach would work, but I'd like to think about it for
a little bit longer before deciding which route to go. In the mean time,
the code works fine, so I don't think a fix is urgent.
- (semi-related) I added a NO SCROLL keyword to DECLARE CURSOR, and
adjusted the behavior of SCROLL in accordance with the discussion on
-hackers.
- (unrelated) Cleaned up some SGML markup in sql.sgml, copy.sgml
Neil Conway
2003-03-27 17:51:29 +01:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* QUERY:
|
|
|
|
|
* SELECT STATEMENTS
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
1999-07-20 02:18:01 +02:00
|
|
|
|
2000-11-05 01:15:54 +01:00
|
|
|
/* A complete SELECT statement looks like this.
|
|
|
|
|
*
|
|
|
|
|
* The rule returns either a single SelectStmt node or a tree of them,
|
|
|
|
|
* representing a set-operation tree.
|
|
|
|
|
*
|
2001-01-15 21:36:36 +01:00
|
|
|
* There is an ambiguity when a sub-SELECT is within an a_expr and there
|
|
|
|
|
* are excess parentheses: do the parentheses belong to the sub-SELECT or
|
2009-07-12 19:12:34 +02:00
|
|
|
* to the surrounding a_expr? We don't really care, but bison wants to know.
|
2001-01-15 21:36:36 +01:00
|
|
|
* To resolve the ambiguity, we are careful to define the grammar so that
|
|
|
|
|
* the decision is staved off as long as possible: as long as we can keep
|
|
|
|
|
* absorbing parentheses into the sub-SELECT, we will do so, and only when
|
|
|
|
|
* it's no longer possible to do that will we decide that parens belong to
|
2002-06-17 22:27:43 +02:00
|
|
|
* the expression. For example, in "SELECT (((SELECT 2)) + 3)" the extra
|
2001-01-15 21:36:36 +01:00
|
|
|
* parentheses are treated as part of the sub-select. The necessity of doing
|
2002-06-17 22:27:43 +02:00
|
|
|
* it that way is shown by "SELECT (((SELECT 2)) UNION SELECT 2)". Had we
|
2001-01-15 21:36:36 +01:00
|
|
|
* parsed "((SELECT 2))" as an a_expr, it'd be too late to go back to the
|
|
|
|
|
* SELECT viewpoint when we see the UNION.
|
|
|
|
|
*
|
|
|
|
|
* This approach is implemented by defining a nonterminal select_with_parens,
|
|
|
|
|
* which represents a SELECT with at least one outer layer of parentheses,
|
|
|
|
|
* and being careful to use select_with_parens, never '(' SelectStmt ')',
|
|
|
|
|
* in the expression grammar. We will then have shift-reduce conflicts
|
|
|
|
|
* which we can resolve in favor of always treating '(' <select> ')' as
|
|
|
|
|
* a select_with_parens. To resolve the conflicts, the productions that
|
|
|
|
|
* conflict with the select_with_parens productions are manually given
|
|
|
|
|
* precedences lower than the precedence of ')', thereby ensuring that we
|
|
|
|
|
* shift ')' (and then reduce to select_with_parens) rather than trying to
|
|
|
|
|
* reduce the inner <select> nonterminal to something else. We use UMINUS
|
|
|
|
|
* precedence for this, which is a fairly arbitrary choice.
|
|
|
|
|
*
|
|
|
|
|
* To be able to define select_with_parens itself without ambiguity, we need
|
|
|
|
|
* a nonterminal select_no_parens that represents a SELECT structure with no
|
|
|
|
|
* outermost parentheses. This is a little bit tedious, but it works.
|
|
|
|
|
*
|
|
|
|
|
* In non-expression contexts, we use SelectStmt which can represent a SELECT
|
|
|
|
|
* with or without outer parentheses.
|
1999-02-23 08:42:41 +01:00
|
|
|
*/
|
|
|
|
|
|
2001-01-15 21:36:36 +01:00
|
|
|
SelectStmt: select_no_parens %prec UMINUS
|
2002-06-17 22:27:43 +02:00
|
|
|
| select_with_parens %prec UMINUS
|
2001-01-15 21:36:36 +01:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
select_with_parens:
|
|
|
|
|
'(' select_no_parens ')' { $$ = $2; }
|
|
|
|
|
| '(' select_with_parens ')' { $$ = $2; }
|
2000-11-05 01:15:54 +01:00
|
|
|
;
|
Hi!
INTERSECT and EXCEPT is available for postgresql-v6.4!
The patch against v6.4 is included at the end of the current text
(in uuencoded form!)
I also included the text of my Master's Thesis. (a postscript
version). I hope that you find something of it useful and would be
happy if parts of it find their way into the PostgreSQL documentation
project (If so, tell me, then I send the sources of the document!)
The contents of the document are:
-) The first chapter might be of less interest as it gives only an
overview on SQL.
-) The second chapter gives a description on much of PostgreSQL's
features (like user defined types etc. and how to use these features)
-) The third chapter starts with an overview of PostgreSQL's internal
structure with focus on the stages a query has to pass (i.e. parser,
planner/optimizer, executor). Then a detailed description of the
implementation of the Having clause and the Intersect/Except logic is
given.
Originally I worked on v6.3.2 but never found time enough to prepare
and post a patch. Now I applied the changes to v6.4 to get Intersect
and Except working with the new version. Chapter 3 of my documentation
deals with the changes against v6.3.2, so keep that in mind when
comparing the parts of the code printed there with the patched sources
of v6.4.
Here are some remarks on the patch. There are some things that have
still to be done but at the moment I don't have time to do them
myself. (I'm doing my military service at the moment) Sorry for that
:-(
-) I used a rewrite technique for the implementation of the Except/Intersect
logic which rewrites the query to a semantically equivalent query before
it is handed to the rewrite system (for views, rules etc.), planner,
executor etc.
-) In v6.3.2 the types of the attributes of two select statements
connected by the UNION keyword had to match 100%. In v6.4 the types
only need to be familiar (i.e. int and float can be mixed). Since this
feature did not exist when I worked on Intersect/Except it
does not work correctly for Except/Intersect queries WHEN USED IN
COMBINATION WITH UNIONS! (i.e. sometimes the wrong type is used for the
resulting table. This is because until now the types of the attributes of
the first select statement have been used for the resulting table.
When Intersects and/or Excepts are used in combination with Unions it
might happen, that the first select statement of the original query
appears at another position in the query which will be executed. The reason
for this is the technique used for the implementation of
Except/Intersect which does a query rewrite!)
NOTE: It is NOT broken for pure UNION queries and pure INTERSECT/EXCEPT
queries!!!
-) I had to add the field intersect_clause to some data structures
but did not find time to implement printfuncs for the new field.
This does NOT break the debug modes but when an Except/Intersect
is used the query debug output will be the already rewritten query.
-) Massive changes to the grammar rules for SELECT and INSERT statements
have been necessary (see comments in gram.y and documentation for
deatails) in order to be able to use mixed queries like
(SELECT ... UNION (SELECT ... EXCEPT SELECT)) INTERSECT SELECT...;
-) When using UNION/EXCEPT/INTERSECT you will get:
NOTICE: equal: "Don't know if nodes of type xxx are equal".
I did not have time to add comparsion support for all the needed nodes,
but the default behaviour of the function equal met my requirements.
I did not dare to supress this message!
That's the reason why the regression test for union will fail: These
messages are also included in the union.out file!
-) Somebody of you changed the union_planner() function for v6.4
(I copied the targetlist to new_tlist and that was removed and
replaced by a cleanup of the original targetlist). These chnages
violated some having queries executed against views so I changed
it back again. I did not have time to examine the differences between the
two versions but now it works :-)
If you want to find out, try the file queries/view_having.sql on
both versions and compare the results . Two queries won't produce a
correct result with your version.
regards
Stefan
1999-01-18 01:10:17 +01:00
|
|
|
|
2002-08-28 16:35:37 +02:00
|
|
|
/*
|
2008-10-04 23:56:55 +02:00
|
|
|
* This rule parses the equivalent of the standard's <query expression>.
|
|
|
|
|
* The duplicative productions are annoying, but hard to get rid of without
|
|
|
|
|
* creating shift/reduce conflicts.
|
|
|
|
|
*
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
* The locking clause (FOR UPDATE etc) may be before or after LIMIT/OFFSET.
|
2002-08-28 16:35:37 +02:00
|
|
|
* In <=7.2.X, LIMIT/OFFSET had to be after FOR UPDATE
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
* We now support both orderings, but prefer LIMIT/OFFSET before the locking
|
|
|
|
|
* clause.
|
2002-08-28 16:35:37 +02:00
|
|
|
* 2002-08-28 bjm
|
|
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
select_no_parens:
|
|
|
|
|
simple_select { $$ = $1; }
|
2002-08-28 16:35:37 +02:00
|
|
|
| select_clause sort_clause
|
2002-06-17 22:27:43 +02:00
|
|
|
{
|
2006-04-30 20:30:40 +02:00
|
|
|
insertSelectOptions((SelectStmt *) $1, $2, NIL,
|
2020-04-07 22:22:13 +02:00
|
|
|
NULL, NULL,
|
2009-07-13 04:02:20 +02:00
|
|
|
yyscanner);
|
2002-06-17 22:27:43 +02:00
|
|
|
$$ = $1;
|
|
|
|
|
}
|
2005-04-28 23:47:18 +02:00
|
|
|
| select_clause opt_sort_clause for_locking_clause opt_select_limit
|
2002-06-17 22:27:43 +02:00
|
|
|
{
|
2002-08-28 16:35:37 +02:00
|
|
|
insertSelectOptions((SelectStmt *) $1, $2, $3,
|
2020-04-07 22:22:13 +02:00
|
|
|
$4,
|
2009-07-13 04:02:20 +02:00
|
|
|
NULL,
|
|
|
|
|
yyscanner);
|
2002-06-17 22:27:43 +02:00
|
|
|
$$ = $1;
|
|
|
|
|
}
|
2005-04-28 23:47:18 +02:00
|
|
|
| select_clause opt_sort_clause select_limit opt_for_locking_clause
|
2002-06-17 22:27:43 +02:00
|
|
|
{
|
2002-08-28 16:35:37 +02:00
|
|
|
insertSelectOptions((SelectStmt *) $1, $2, $4,
|
2020-04-07 22:22:13 +02:00
|
|
|
$3,
|
2009-07-13 04:02:20 +02:00
|
|
|
NULL,
|
|
|
|
|
yyscanner);
|
2002-06-17 22:27:43 +02:00
|
|
|
$$ = $1;
|
|
|
|
|
}
|
2009-07-06 04:58:40 +02:00
|
|
|
| with_clause select_clause
|
2008-10-04 23:56:55 +02:00
|
|
|
{
|
|
|
|
|
insertSelectOptions((SelectStmt *) $2, NULL, NIL,
|
2020-04-07 22:22:13 +02:00
|
|
|
NULL,
|
2009-07-13 04:02:20 +02:00
|
|
|
$1,
|
|
|
|
|
yyscanner);
|
2008-10-04 23:56:55 +02:00
|
|
|
$$ = $2;
|
|
|
|
|
}
|
|
|
|
|
| with_clause select_clause sort_clause
|
|
|
|
|
{
|
|
|
|
|
insertSelectOptions((SelectStmt *) $2, $3, NIL,
|
2020-04-07 22:22:13 +02:00
|
|
|
NULL,
|
2009-07-13 04:02:20 +02:00
|
|
|
$1,
|
|
|
|
|
yyscanner);
|
2008-10-04 23:56:55 +02:00
|
|
|
$$ = $2;
|
|
|
|
|
}
|
|
|
|
|
| with_clause select_clause opt_sort_clause for_locking_clause opt_select_limit
|
|
|
|
|
{
|
|
|
|
|
insertSelectOptions((SelectStmt *) $2, $3, $4,
|
2020-04-07 22:22:13 +02:00
|
|
|
$5,
|
2009-07-13 04:02:20 +02:00
|
|
|
$1,
|
|
|
|
|
yyscanner);
|
2008-10-04 23:56:55 +02:00
|
|
|
$$ = $2;
|
|
|
|
|
}
|
|
|
|
|
| with_clause select_clause opt_sort_clause select_limit opt_for_locking_clause
|
|
|
|
|
{
|
|
|
|
|
insertSelectOptions((SelectStmt *) $2, $3, $5,
|
2020-04-07 22:22:13 +02:00
|
|
|
$4,
|
2009-07-13 04:02:20 +02:00
|
|
|
$1,
|
|
|
|
|
yyscanner);
|
2008-10-04 23:56:55 +02:00
|
|
|
$$ = $2;
|
|
|
|
|
}
|
2000-10-28 21:41:00 +02:00
|
|
|
;
|
Okay, here's my attempt at fixing the problems with parentheses in
subqueries. It passes the normal 'runcheck' tests, and I've tried
a few simple things like
select 1 as foo union (((((select 2))))) order by foo;
There are a few things that it doesn't do that have been talked
about here at least a little:
1) It doesn't allow things like "IN(((select 1)))" -- the select
here has to be at the top level. This is not new.
2) It does NOT preserve the odd syntax I found when I started looking
at this, where a SELECT statement could begin with parentheses. Thus,
(SELECT a from foo) order by a;
fails.
I have preserved the ability, used in the regression tests, to
have a single select statement in what appears to be a RuleActionMulti
(but wasn't -- the parens were part of select_clause syntax).
In my version, this is a special form.
This may cause some discussion: I have differentiated the two kinds
of RuleActionMulti. Perhaps nobody knew there were two kinds, because
I don't think the second form appears in the regression tests. This
one uses square brackets instead of parentheses, but originally was
otherwise the same as the one in parentheses. In this version of
gram.y, the square bracket form treats SELECT statements the same
as the other allowed statements. As discussed before on this list,
psql cannot make sense out of the results of such a thing, but an
application might. And I have designs on just such an application.
++ kevin o'gorman
2000-10-28 17:44:04 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
select_clause:
|
|
|
|
|
simple_select { $$ = $1; }
|
|
|
|
|
| select_with_parens { $$ = $1; }
|
2000-10-05 21:11:39 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-11-05 01:15:54 +01:00
|
|
|
/*
|
|
|
|
|
* This rule parses SELECT statements that can appear within set operations,
|
|
|
|
|
* including UNION, INTERSECT and EXCEPT. '(' and ')' can be used to specify
|
2002-06-17 22:27:43 +02:00
|
|
|
* the ordering of the set operations. Without '(' and ')' we want the
|
2000-11-05 01:15:54 +01:00
|
|
|
* operations to be ordered per the precedence specs at the head of this file.
|
|
|
|
|
*
|
|
|
|
|
* As with select_no_parens, simple_select cannot have outer parentheses,
|
|
|
|
|
* but can have parenthesized subclauses.
|
|
|
|
|
*
|
2021-01-22 22:26:22 +01:00
|
|
|
* It might appear that we could fold the first two alternatives into one
|
|
|
|
|
* by using opt_distinct_clause. However, that causes a shift/reduce conflict
|
|
|
|
|
* against INSERT ... SELECT ... ON CONFLICT. We avoid the ambiguity by
|
|
|
|
|
* requiring SELECT DISTINCT [ON] to be followed by a non-empty target_list.
|
|
|
|
|
*
|
2013-04-20 17:04:41 +02:00
|
|
|
* Note that sort clauses cannot be included at this level --- SQL requires
|
2000-11-05 01:15:54 +01:00
|
|
|
* SELECT foo UNION SELECT bar ORDER BY baz
|
|
|
|
|
* to be parsed as
|
|
|
|
|
* (SELECT foo UNION SELECT bar) ORDER BY baz
|
|
|
|
|
* not
|
|
|
|
|
* SELECT foo UNION (SELECT bar ORDER BY baz)
|
2008-10-04 23:56:55 +02:00
|
|
|
* Likewise for WITH, FOR UPDATE and LIMIT. Therefore, those clauses are
|
|
|
|
|
* described as part of the select_no_parens production, not simple_select.
|
|
|
|
|
* This does not limit functionality, because you can reintroduce these
|
|
|
|
|
* clauses inside parentheses.
|
2000-11-05 01:15:54 +01:00
|
|
|
*
|
|
|
|
|
* NOTE: only the leftmost component SelectStmt should have INTO.
|
|
|
|
|
* However, this is not checked by the grammar; parse analysis must check it.
|
|
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
simple_select:
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
SELECT opt_all_clause opt_target_list
|
|
|
|
|
into_clause from_clause where_clause
|
|
|
|
|
group_clause having_clause window_clause
|
|
|
|
|
{
|
|
|
|
|
SelectStmt *n = makeNode(SelectStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
n->targetList = $3;
|
|
|
|
|
n->intoClause = $4;
|
|
|
|
|
n->fromClause = $5;
|
|
|
|
|
n->whereClause = $6;
|
Implement GROUP BY DISTINCT
With grouping sets, it's possible that some of the grouping sets are
duplicate. This is especially common with CUBE and ROLLUP clauses. For
example GROUP BY CUBE (a,b), CUBE (b,c) is equivalent to
GROUP BY GROUPING SETS (
(a, b, c),
(a, b, c),
(a, b, c),
(a, b),
(a, b),
(a, b),
(a),
(a),
(a),
(c, a),
(c, a),
(c, a),
(c),
(b, c),
(b),
()
)
Some of the grouping sets are calculated multiple times, which is mostly
unnecessary. This commit implements a new GROUP BY DISTINCT feature, as
defined in the SQL standard, which eliminates the duplicate sets.
Author: Vik Fearing
Reviewed-by: Erik Rijkers, Georgios Kokolatos, Tomas Vondra
Discussion: https://postgr.es/m/bf3805a8-d7d1-ae61-fece-761b7ff41ecc@postgresfriends.org
2021-03-18 17:45:38 +01:00
|
|
|
n->groupClause = ($7)->list;
|
|
|
|
|
n->groupDistinct = ($7)->distinct;
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
n->havingClause = $8;
|
|
|
|
|
n->windowClause = $9;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
}
|
|
|
|
|
| SELECT distinct_clause target_list
|
2002-06-17 22:27:43 +02:00
|
|
|
into_clause from_clause where_clause
|
2008-12-28 19:54:01 +01:00
|
|
|
group_clause having_clause window_clause
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
1998-01-09 21:06:08 +01:00
|
|
|
SelectStmt *n = makeNode(SelectStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2000-01-27 19:11:50 +01:00
|
|
|
n->distinctClause = $2;
|
1997-09-08 05:20:18 +02:00
|
|
|
n->targetList = $3;
|
2007-04-28 00:05:49 +02:00
|
|
|
n->intoClause = $4;
|
1997-09-08 05:20:18 +02:00
|
|
|
n->fromClause = $5;
|
|
|
|
|
n->whereClause = $6;
|
Implement GROUP BY DISTINCT
With grouping sets, it's possible that some of the grouping sets are
duplicate. This is especially common with CUBE and ROLLUP clauses. For
example GROUP BY CUBE (a,b), CUBE (b,c) is equivalent to
GROUP BY GROUPING SETS (
(a, b, c),
(a, b, c),
(a, b, c),
(a, b),
(a, b),
(a, b),
(a),
(a),
(a),
(c, a),
(c, a),
(c, a),
(c),
(b, c),
(b),
()
)
Some of the grouping sets are calculated multiple times, which is mostly
unnecessary. This commit implements a new GROUP BY DISTINCT feature, as
defined in the SQL standard, which eliminates the duplicate sets.
Author: Vik Fearing
Reviewed-by: Erik Rijkers, Georgios Kokolatos, Tomas Vondra
Discussion: https://postgr.es/m/bf3805a8-d7d1-ae61-fece-761b7ff41ecc@postgresfriends.org
2021-03-18 17:45:38 +01:00
|
|
|
n->groupClause = ($7)->list;
|
|
|
|
|
n->groupDistinct = ($7)->distinct;
|
1997-09-08 05:20:18 +02:00
|
|
|
n->havingClause = $8;
|
2008-12-28 19:54:01 +01:00
|
|
|
n->windowClause = $9;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2006-08-02 03:59:48 +02:00
|
|
|
| values_clause { $$ = $1; }
|
2008-11-21 12:47:55 +01:00
|
|
|
| TABLE relation_expr
|
2008-11-20 15:04:46 +01:00
|
|
|
{
|
2008-11-21 12:47:55 +01:00
|
|
|
/* same as SELECT * FROM relation_expr */
|
2022-05-13 07:17:29 +02:00
|
|
|
ColumnRef *cr = makeNode(ColumnRef);
|
|
|
|
|
ResTarget *rt = makeNode(ResTarget);
|
2008-11-20 15:04:46 +01:00
|
|
|
SelectStmt *n = makeNode(SelectStmt);
|
|
|
|
|
|
|
|
|
|
cr->fields = list_make1(makeNode(A_Star));
|
|
|
|
|
cr->location = -1;
|
|
|
|
|
|
|
|
|
|
rt->name = NULL;
|
|
|
|
|
rt->indirection = NIL;
|
2022-05-13 07:17:29 +02:00
|
|
|
rt->val = (Node *) cr;
|
2008-11-20 15:04:46 +01:00
|
|
|
rt->location = -1;
|
|
|
|
|
|
|
|
|
|
n->targetList = list_make1(rt);
|
|
|
|
|
n->fromClause = list_make1($2);
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2008-11-20 15:04:46 +01:00
|
|
|
}
|
Implement GROUP BY DISTINCT
With grouping sets, it's possible that some of the grouping sets are
duplicate. This is especially common with CUBE and ROLLUP clauses. For
example GROUP BY CUBE (a,b), CUBE (b,c) is equivalent to
GROUP BY GROUPING SETS (
(a, b, c),
(a, b, c),
(a, b, c),
(a, b),
(a, b),
(a, b),
(a),
(a),
(a),
(c, a),
(c, a),
(c, a),
(c),
(b, c),
(b),
()
)
Some of the grouping sets are calculated multiple times, which is mostly
unnecessary. This commit implements a new GROUP BY DISTINCT feature, as
defined in the SQL standard, which eliminates the duplicate sets.
Author: Vik Fearing
Reviewed-by: Erik Rijkers, Georgios Kokolatos, Tomas Vondra
Discussion: https://postgr.es/m/bf3805a8-d7d1-ae61-fece-761b7ff41ecc@postgresfriends.org
2021-03-18 17:45:38 +01:00
|
|
|
| select_clause UNION set_quantifier select_clause
|
2002-06-17 22:27:43 +02:00
|
|
|
{
|
Implement GROUP BY DISTINCT
With grouping sets, it's possible that some of the grouping sets are
duplicate. This is especially common with CUBE and ROLLUP clauses. For
example GROUP BY CUBE (a,b), CUBE (b,c) is equivalent to
GROUP BY GROUPING SETS (
(a, b, c),
(a, b, c),
(a, b, c),
(a, b),
(a, b),
(a, b),
(a),
(a),
(a),
(c, a),
(c, a),
(c, a),
(c),
(b, c),
(b),
()
)
Some of the grouping sets are calculated multiple times, which is mostly
unnecessary. This commit implements a new GROUP BY DISTINCT feature, as
defined in the SQL standard, which eliminates the duplicate sets.
Author: Vik Fearing
Reviewed-by: Erik Rijkers, Georgios Kokolatos, Tomas Vondra
Discussion: https://postgr.es/m/bf3805a8-d7d1-ae61-fece-761b7ff41ecc@postgresfriends.org
2021-03-18 17:45:38 +01:00
|
|
|
$$ = makeSetOp(SETOP_UNION, $3 == SET_QUANTIFIER_ALL, $1, $4);
|
2002-06-17 22:27:43 +02:00
|
|
|
}
|
Implement GROUP BY DISTINCT
With grouping sets, it's possible that some of the grouping sets are
duplicate. This is especially common with CUBE and ROLLUP clauses. For
example GROUP BY CUBE (a,b), CUBE (b,c) is equivalent to
GROUP BY GROUPING SETS (
(a, b, c),
(a, b, c),
(a, b, c),
(a, b),
(a, b),
(a, b),
(a),
(a),
(a),
(c, a),
(c, a),
(c, a),
(c),
(b, c),
(b),
()
)
Some of the grouping sets are calculated multiple times, which is mostly
unnecessary. This commit implements a new GROUP BY DISTINCT feature, as
defined in the SQL standard, which eliminates the duplicate sets.
Author: Vik Fearing
Reviewed-by: Erik Rijkers, Georgios Kokolatos, Tomas Vondra
Discussion: https://postgr.es/m/bf3805a8-d7d1-ae61-fece-761b7ff41ecc@postgresfriends.org
2021-03-18 17:45:38 +01:00
|
|
|
| select_clause INTERSECT set_quantifier select_clause
|
2002-06-17 22:27:43 +02:00
|
|
|
{
|
Implement GROUP BY DISTINCT
With grouping sets, it's possible that some of the grouping sets are
duplicate. This is especially common with CUBE and ROLLUP clauses. For
example GROUP BY CUBE (a,b), CUBE (b,c) is equivalent to
GROUP BY GROUPING SETS (
(a, b, c),
(a, b, c),
(a, b, c),
(a, b),
(a, b),
(a, b),
(a),
(a),
(a),
(c, a),
(c, a),
(c, a),
(c),
(b, c),
(b),
()
)
Some of the grouping sets are calculated multiple times, which is mostly
unnecessary. This commit implements a new GROUP BY DISTINCT feature, as
defined in the SQL standard, which eliminates the duplicate sets.
Author: Vik Fearing
Reviewed-by: Erik Rijkers, Georgios Kokolatos, Tomas Vondra
Discussion: https://postgr.es/m/bf3805a8-d7d1-ae61-fece-761b7ff41ecc@postgresfriends.org
2021-03-18 17:45:38 +01:00
|
|
|
$$ = makeSetOp(SETOP_INTERSECT, $3 == SET_QUANTIFIER_ALL, $1, $4);
|
2002-06-17 22:27:43 +02:00
|
|
|
}
|
Implement GROUP BY DISTINCT
With grouping sets, it's possible that some of the grouping sets are
duplicate. This is especially common with CUBE and ROLLUP clauses. For
example GROUP BY CUBE (a,b), CUBE (b,c) is equivalent to
GROUP BY GROUPING SETS (
(a, b, c),
(a, b, c),
(a, b, c),
(a, b),
(a, b),
(a, b),
(a),
(a),
(a),
(c, a),
(c, a),
(c, a),
(c),
(b, c),
(b),
()
)
Some of the grouping sets are calculated multiple times, which is mostly
unnecessary. This commit implements a new GROUP BY DISTINCT feature, as
defined in the SQL standard, which eliminates the duplicate sets.
Author: Vik Fearing
Reviewed-by: Erik Rijkers, Georgios Kokolatos, Tomas Vondra
Discussion: https://postgr.es/m/bf3805a8-d7d1-ae61-fece-761b7ff41ecc@postgresfriends.org
2021-03-18 17:45:38 +01:00
|
|
|
| select_clause EXCEPT set_quantifier select_clause
|
2002-06-17 22:27:43 +02:00
|
|
|
{
|
Implement GROUP BY DISTINCT
With grouping sets, it's possible that some of the grouping sets are
duplicate. This is especially common with CUBE and ROLLUP clauses. For
example GROUP BY CUBE (a,b), CUBE (b,c) is equivalent to
GROUP BY GROUPING SETS (
(a, b, c),
(a, b, c),
(a, b, c),
(a, b),
(a, b),
(a, b),
(a),
(a),
(a),
(c, a),
(c, a),
(c, a),
(c),
(b, c),
(b),
()
)
Some of the grouping sets are calculated multiple times, which is mostly
unnecessary. This commit implements a new GROUP BY DISTINCT feature, as
defined in the SQL standard, which eliminates the duplicate sets.
Author: Vik Fearing
Reviewed-by: Erik Rijkers, Georgios Kokolatos, Tomas Vondra
Discussion: https://postgr.es/m/bf3805a8-d7d1-ae61-fece-761b7ff41ecc@postgresfriends.org
2021-03-18 17:45:38 +01:00
|
|
|
$$ = makeSetOp(SETOP_EXCEPT, $3 == SET_QUANTIFIER_ALL, $1, $4);
|
2002-06-17 22:27:43 +02:00
|
|
|
}
|
2002-06-17 07:40:32 +02:00
|
|
|
;
|
1997-09-01 08:00:35 +02:00
|
|
|
|
2008-10-04 23:56:55 +02:00
|
|
|
/*
|
|
|
|
|
* SQL standard WITH clause looks like:
|
|
|
|
|
*
|
|
|
|
|
* WITH [ RECURSIVE ] <query name> [ (<column>,...) ]
|
|
|
|
|
* AS (query) [ SEARCH or CYCLE clause ]
|
|
|
|
|
*
|
Improve parser's one-extra-token lookahead mechanism.
There are a couple of places in our grammar that fail to be strict LALR(1),
by requiring more than a single token of lookahead to decide what to do.
Up to now we've dealt with that by using a filter between the lexer and
parser that merges adjacent tokens into one in the places where two tokens
of lookahead are necessary. But that creates a number of user-visible
anomalies, for instance that you can't name a CTE "ordinality" because
"WITH ordinality AS ..." triggers folding of WITH and ORDINALITY into one
token. I realized that there's a better way.
In this patch, we still do the lookahead basically as before, but we never
merge the second token into the first; we replace just the first token by
a special lookahead symbol when one of the lookahead pairs is seen.
This requires a couple extra productions in the grammar, but it involves
fewer special tokens, so that the grammar tables come out a bit smaller
than before. The filter logic is no slower than before, perhaps a bit
faster.
I also fixed the filter logic so that when backing up after a lookahead,
the current token's terminator is correctly restored; this eliminates some
weird behavior in error message issuance, as is shown by the one change in
existing regression test outputs.
I believe that this patch entirely eliminates odd behaviors caused by
lookahead for WITH. It doesn't really improve the situation for NULLS
followed by FIRST/LAST unfortunately: those sequences still act like a
reserved word, even though there are cases where they should be seen as two
ordinary identifiers, eg "SELECT nulls first FROM ...". I experimented
with additional grammar hacks but couldn't find any simple solution for
that. Still, this is better than before, and it seems much more likely
that we *could* somehow solve the NULLS case on the basis of this filter
behavior than the previous one.
2015-02-24 23:53:42 +01:00
|
|
|
* Recognizing WITH_LA here allows a CTE to be named TIME or ORDINALITY.
|
2008-10-04 23:56:55 +02:00
|
|
|
*/
|
|
|
|
|
with_clause:
|
|
|
|
|
WITH cte_list
|
|
|
|
|
{
|
|
|
|
|
$$ = makeNode(WithClause);
|
|
|
|
|
$$->ctes = $2;
|
|
|
|
|
$$->recursive = false;
|
|
|
|
|
$$->location = @1;
|
|
|
|
|
}
|
Improve parser's one-extra-token lookahead mechanism.
There are a couple of places in our grammar that fail to be strict LALR(1),
by requiring more than a single token of lookahead to decide what to do.
Up to now we've dealt with that by using a filter between the lexer and
parser that merges adjacent tokens into one in the places where two tokens
of lookahead are necessary. But that creates a number of user-visible
anomalies, for instance that you can't name a CTE "ordinality" because
"WITH ordinality AS ..." triggers folding of WITH and ORDINALITY into one
token. I realized that there's a better way.
In this patch, we still do the lookahead basically as before, but we never
merge the second token into the first; we replace just the first token by
a special lookahead symbol when one of the lookahead pairs is seen.
This requires a couple extra productions in the grammar, but it involves
fewer special tokens, so that the grammar tables come out a bit smaller
than before. The filter logic is no slower than before, perhaps a bit
faster.
I also fixed the filter logic so that when backing up after a lookahead,
the current token's terminator is correctly restored; this eliminates some
weird behavior in error message issuance, as is shown by the one change in
existing regression test outputs.
I believe that this patch entirely eliminates odd behaviors caused by
lookahead for WITH. It doesn't really improve the situation for NULLS
followed by FIRST/LAST unfortunately: those sequences still act like a
reserved word, even though there are cases where they should be seen as two
ordinary identifiers, eg "SELECT nulls first FROM ...". I experimented
with additional grammar hacks but couldn't find any simple solution for
that. Still, this is better than before, and it seems much more likely
that we *could* somehow solve the NULLS case on the basis of this filter
behavior than the previous one.
2015-02-24 23:53:42 +01:00
|
|
|
| WITH_LA cte_list
|
|
|
|
|
{
|
|
|
|
|
$$ = makeNode(WithClause);
|
|
|
|
|
$$->ctes = $2;
|
|
|
|
|
$$->recursive = false;
|
|
|
|
|
$$->location = @1;
|
|
|
|
|
}
|
2008-10-04 23:56:55 +02:00
|
|
|
| WITH RECURSIVE cte_list
|
|
|
|
|
{
|
|
|
|
|
$$ = makeNode(WithClause);
|
|
|
|
|
$$->ctes = $3;
|
|
|
|
|
$$->recursive = true;
|
|
|
|
|
$$->location = @1;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
cte_list:
|
|
|
|
|
common_table_expr { $$ = list_make1($1); }
|
|
|
|
|
| cte_list ',' common_table_expr { $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
2021-02-01 13:54:59 +01:00
|
|
|
common_table_expr: name opt_name_list AS opt_materialized '(' PreparableStmt ')' opt_search_clause opt_cycle_clause
|
2008-10-04 23:56:55 +02:00
|
|
|
{
|
|
|
|
|
CommonTableExpr *n = makeNode(CommonTableExpr);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-10-04 23:56:55 +02:00
|
|
|
n->ctename = $1;
|
|
|
|
|
n->aliascolnames = $2;
|
Allow user control of CTE materialization, and change the default behavior.
Historically we've always materialized the full output of a CTE query,
treating WITH as an optimization fence (so that, for example, restrictions
from the outer query cannot be pushed into it). This is appropriate when
the CTE query is INSERT/UPDATE/DELETE, or is recursive; but when the CTE
query is non-recursive and side-effect-free, there's no hazard of changing
the query results by pushing restrictions down.
Another argument for materialization is that it can avoid duplicate
computation of an expensive WITH query --- but that only applies if
the WITH query is called more than once in the outer query. Even then
it could still be a net loss, if each call has restrictions that
would allow just a small part of the WITH query to be computed.
Hence, let's change the behavior for WITH queries that are non-recursive
and side-effect-free. By default, we will inline them into the outer
query (removing the optimization fence) if they are called just once.
If they are called more than once, we will keep the old behavior by
default, but the user can override this and force inlining by specifying
NOT MATERIALIZED. Lastly, the user can force the old behavior by
specifying MATERIALIZED; this would mainly be useful when the query had
deliberately been employing WITH as an optimization fence to prevent a
poor choice of plan.
Andreas Karlsson, Andrew Gierth, David Fetter
Discussion: https://postgr.es/m/87sh48ffhb.fsf@news-spur.riddles.org.uk
2019-02-16 22:11:12 +01:00
|
|
|
n->ctematerialized = $4;
|
|
|
|
|
n->ctequery = $6;
|
2021-02-01 13:54:59 +01:00
|
|
|
n->search_clause = castNode(CTESearchClause, $8);
|
|
|
|
|
n->cycle_clause = castNode(CTECycleClause, $9);
|
2008-10-04 23:56:55 +02:00
|
|
|
n->location = @1;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
Allow user control of CTE materialization, and change the default behavior.
Historically we've always materialized the full output of a CTE query,
treating WITH as an optimization fence (so that, for example, restrictions
from the outer query cannot be pushed into it). This is appropriate when
the CTE query is INSERT/UPDATE/DELETE, or is recursive; but when the CTE
query is non-recursive and side-effect-free, there's no hazard of changing
the query results by pushing restrictions down.
Another argument for materialization is that it can avoid duplicate
computation of an expensive WITH query --- but that only applies if
the WITH query is called more than once in the outer query. Even then
it could still be a net loss, if each call has restrictions that
would allow just a small part of the WITH query to be computed.
Hence, let's change the behavior for WITH queries that are non-recursive
and side-effect-free. By default, we will inline them into the outer
query (removing the optimization fence) if they are called just once.
If they are called more than once, we will keep the old behavior by
default, but the user can override this and force inlining by specifying
NOT MATERIALIZED. Lastly, the user can force the old behavior by
specifying MATERIALIZED; this would mainly be useful when the query had
deliberately been employing WITH as an optimization fence to prevent a
poor choice of plan.
Andreas Karlsson, Andrew Gierth, David Fetter
Discussion: https://postgr.es/m/87sh48ffhb.fsf@news-spur.riddles.org.uk
2019-02-16 22:11:12 +01:00
|
|
|
opt_materialized:
|
|
|
|
|
MATERIALIZED { $$ = CTEMaterializeAlways; }
|
|
|
|
|
| NOT MATERIALIZED { $$ = CTEMaterializeNever; }
|
|
|
|
|
| /*EMPTY*/ { $$ = CTEMaterializeDefault; }
|
|
|
|
|
;
|
|
|
|
|
|
2021-02-01 13:54:59 +01:00
|
|
|
opt_search_clause:
|
|
|
|
|
SEARCH DEPTH FIRST_P BY columnList SET ColId
|
|
|
|
|
{
|
|
|
|
|
CTESearchClause *n = makeNode(CTESearchClause);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-02-01 13:54:59 +01:00
|
|
|
n->search_col_list = $5;
|
|
|
|
|
n->search_breadth_first = false;
|
|
|
|
|
n->search_seq_column = $7;
|
|
|
|
|
n->location = @1;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| SEARCH BREADTH FIRST_P BY columnList SET ColId
|
|
|
|
|
{
|
|
|
|
|
CTESearchClause *n = makeNode(CTESearchClause);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-02-01 13:54:59 +01:00
|
|
|
n->search_col_list = $5;
|
|
|
|
|
n->search_breadth_first = true;
|
|
|
|
|
n->search_seq_column = $7;
|
|
|
|
|
n->location = @1;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| /*EMPTY*/
|
|
|
|
|
{
|
|
|
|
|
$$ = NULL;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_cycle_clause:
|
|
|
|
|
CYCLE columnList SET ColId TO AexprConst DEFAULT AexprConst USING ColId
|
|
|
|
|
{
|
|
|
|
|
CTECycleClause *n = makeNode(CTECycleClause);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-02-01 13:54:59 +01:00
|
|
|
n->cycle_col_list = $2;
|
|
|
|
|
n->cycle_mark_column = $4;
|
|
|
|
|
n->cycle_mark_value = $6;
|
|
|
|
|
n->cycle_mark_default = $8;
|
|
|
|
|
n->cycle_path_column = $10;
|
|
|
|
|
n->location = @1;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2021-02-27 08:11:14 +01:00
|
|
|
| CYCLE columnList SET ColId USING ColId
|
|
|
|
|
{
|
|
|
|
|
CTECycleClause *n = makeNode(CTECycleClause);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2021-02-27 08:11:14 +01:00
|
|
|
n->cycle_col_list = $2;
|
|
|
|
|
n->cycle_mark_column = $4;
|
|
|
|
|
n->cycle_mark_value = makeBoolAConst(true, -1);
|
|
|
|
|
n->cycle_mark_default = makeBoolAConst(false, -1);
|
|
|
|
|
n->cycle_path_column = $6;
|
|
|
|
|
n->location = @1;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2021-02-01 13:54:59 +01:00
|
|
|
| /*EMPTY*/
|
|
|
|
|
{
|
|
|
|
|
$$ = NULL;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2010-10-16 01:53:59 +02:00
|
|
|
opt_with_clause:
|
|
|
|
|
with_clause { $$ = $1; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
into_clause:
|
2007-02-20 18:32:18 +01:00
|
|
|
INTO OptTempTableName
|
|
|
|
|
{
|
|
|
|
|
$$ = makeNode(IntoClause);
|
|
|
|
|
$$->rel = $2;
|
|
|
|
|
$$->colNames = NIL;
|
|
|
|
|
$$->options = NIL;
|
|
|
|
|
$$->onCommit = ONCOMMIT_NOOP;
|
|
|
|
|
$$->tableSpaceName = NULL;
|
Clean up the mess around EXPLAIN and materialized views.
Revert the matview-related changes in explain.c's API, as per recent
complaint from Robert Haas. The reason for these appears to have been
principally some ill-considered choices around having intorel_startup do
what ought to be parse-time checking, plus a poor arrangement for passing
it the view parsetree it needs to store into pg_rewrite when creating a
materialized view. Do the latter by having parse analysis stick a copy
into the IntoClause, instead of doing it at runtime. (On the whole,
I seriously question the choice to represent CREATE MATERIALIZED VIEW as a
variant of SELECT INTO/CREATE TABLE AS, because that means injecting even
more complexity into what was already a horrid legacy kluge. However,
I didn't go so far as to rethink that choice ... yet.)
I also moved several error checks into matview parse analysis, and
made the check for external Params in a matview more accurate.
In passing, clean things up a bit more around interpretOidsOption(),
and fix things so that we can use that to force no-oids for views,
sequences, etc, thereby eliminating the need to cons up "oids = false"
options when creating them.
catversion bump due to change in IntoClause. (I wonder though if we
really need readfuncs/outfuncs support for IntoClause anymore.)
2013-04-13 01:25:20 +02:00
|
|
|
$$->viewQuery = NULL;
|
2011-11-25 05:21:06 +01:00
|
|
|
$$->skipData = false;
|
2007-02-20 18:32:18 +01:00
|
|
|
}
|
|
|
|
|
| /*EMPTY*/
|
|
|
|
|
{ $$ = NULL; }
|
2000-03-01 06:18:20 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Redundancy here is needed to avoid shift/reduce conflicts,
|
|
|
|
|
* since TEMP is not a reserved word. See also OptTemp.
|
|
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
OptTempTableName:
|
|
|
|
|
TEMPORARY opt_table qualified_name
|
2002-06-17 07:40:32 +02:00
|
|
|
{
|
2002-03-21 17:02:16 +01:00
|
|
|
$$ = $3;
|
2010-12-13 18:34:26 +01:00
|
|
|
$$->relpersistence = RELPERSISTENCE_TEMP;
|
2002-03-21 17:02:16 +01:00
|
|
|
}
|
|
|
|
|
| TEMP opt_table qualified_name
|
2002-06-17 07:40:32 +02:00
|
|
|
{
|
2002-03-21 17:02:16 +01:00
|
|
|
$$ = $3;
|
2010-12-13 18:34:26 +01:00
|
|
|
$$->relpersistence = RELPERSISTENCE_TEMP;
|
2002-03-21 17:02:16 +01:00
|
|
|
}
|
|
|
|
|
| LOCAL TEMPORARY opt_table qualified_name
|
2002-06-17 07:40:32 +02:00
|
|
|
{
|
2002-03-21 17:02:16 +01:00
|
|
|
$$ = $4;
|
2010-12-13 18:34:26 +01:00
|
|
|
$$->relpersistence = RELPERSISTENCE_TEMP;
|
2002-03-21 17:02:16 +01:00
|
|
|
}
|
|
|
|
|
| LOCAL TEMP opt_table qualified_name
|
2002-06-17 07:40:32 +02:00
|
|
|
{
|
2002-03-21 17:02:16 +01:00
|
|
|
$$ = $4;
|
2010-12-13 18:34:26 +01:00
|
|
|
$$->relpersistence = RELPERSISTENCE_TEMP;
|
2002-03-21 17:02:16 +01:00
|
|
|
}
|
|
|
|
|
| GLOBAL TEMPORARY opt_table qualified_name
|
2000-03-01 06:18:20 +01:00
|
|
|
{
|
2012-06-13 23:48:42 +02:00
|
|
|
ereport(WARNING,
|
|
|
|
|
(errmsg("GLOBAL is deprecated in temporary table creation"),
|
|
|
|
|
parser_errposition(@1)));
|
2002-03-21 17:02:16 +01:00
|
|
|
$$ = $4;
|
2010-12-13 18:34:26 +01:00
|
|
|
$$->relpersistence = RELPERSISTENCE_TEMP;
|
2000-03-01 06:18:20 +01:00
|
|
|
}
|
2002-03-21 17:02:16 +01:00
|
|
|
| GLOBAL TEMP opt_table qualified_name
|
2000-03-01 06:18:20 +01:00
|
|
|
{
|
2012-06-13 23:48:42 +02:00
|
|
|
ereport(WARNING,
|
|
|
|
|
(errmsg("GLOBAL is deprecated in temporary table creation"),
|
|
|
|
|
parser_errposition(@1)));
|
2002-03-21 17:02:16 +01:00
|
|
|
$$ = $4;
|
2010-12-13 18:34:26 +01:00
|
|
|
$$->relpersistence = RELPERSISTENCE_TEMP;
|
2002-03-21 17:02:16 +01:00
|
|
|
}
|
2010-12-29 12:48:53 +01:00
|
|
|
| UNLOGGED opt_table qualified_name
|
|
|
|
|
{
|
|
|
|
|
$$ = $3;
|
|
|
|
|
$$->relpersistence = RELPERSISTENCE_UNLOGGED;
|
|
|
|
|
}
|
2002-03-21 17:02:16 +01:00
|
|
|
| TABLE qualified_name
|
2002-06-17 07:40:32 +02:00
|
|
|
{
|
2002-03-21 17:02:16 +01:00
|
|
|
$$ = $2;
|
2010-12-13 18:34:26 +01:00
|
|
|
$$->relpersistence = RELPERSISTENCE_PERMANENT;
|
2002-03-21 17:02:16 +01:00
|
|
|
}
|
|
|
|
|
| qualified_name
|
2002-06-17 07:40:32 +02:00
|
|
|
{
|
2002-03-21 17:02:16 +01:00
|
|
|
$$ = $1;
|
2010-12-13 18:34:26 +01:00
|
|
|
$$->relpersistence = RELPERSISTENCE_PERMANENT;
|
2000-03-01 06:18:20 +01:00
|
|
|
}
|
1998-03-18 17:50:25 +01:00
|
|
|
;
|
|
|
|
|
|
2020-11-12 07:48:36 +01:00
|
|
|
opt_table: TABLE
|
|
|
|
|
| /*EMPTY*/
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
Implement GROUP BY DISTINCT
With grouping sets, it's possible that some of the grouping sets are
duplicate. This is especially common with CUBE and ROLLUP clauses. For
example GROUP BY CUBE (a,b), CUBE (b,c) is equivalent to
GROUP BY GROUPING SETS (
(a, b, c),
(a, b, c),
(a, b, c),
(a, b),
(a, b),
(a, b),
(a),
(a),
(a),
(c, a),
(c, a),
(c, a),
(c),
(b, c),
(b),
()
)
Some of the grouping sets are calculated multiple times, which is mostly
unnecessary. This commit implements a new GROUP BY DISTINCT feature, as
defined in the SQL standard, which eliminates the duplicate sets.
Author: Vik Fearing
Reviewed-by: Erik Rijkers, Georgios Kokolatos, Tomas Vondra
Discussion: https://postgr.es/m/bf3805a8-d7d1-ae61-fece-761b7ff41ecc@postgresfriends.org
2021-03-18 17:45:38 +01:00
|
|
|
set_quantifier:
|
|
|
|
|
ALL { $$ = SET_QUANTIFIER_ALL; }
|
|
|
|
|
| DISTINCT { $$ = SET_QUANTIFIER_DISTINCT; }
|
|
|
|
|
| /*EMPTY*/ { $$ = SET_QUANTIFIER_DEFAULT; }
|
1997-11-17 17:37:24 +01:00
|
|
|
;
|
|
|
|
|
|
2000-01-27 19:11:50 +01:00
|
|
|
/* We use (NIL) as a placeholder to indicate that all target expressions
|
|
|
|
|
* should be placed in the DISTINCT list during parsetree analysis.
|
|
|
|
|
*/
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
distinct_clause:
|
2004-05-31 01:40:41 +02:00
|
|
|
DISTINCT { $$ = list_make1(NIL); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| DISTINCT ON '(' expr_list ')' { $$ = $4; }
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_all_clause:
|
2020-11-12 07:48:36 +01:00
|
|
|
ALL
|
|
|
|
|
| /*EMPTY*/
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2021-01-22 22:26:22 +01:00
|
|
|
opt_distinct_clause:
|
|
|
|
|
distinct_clause { $$ = $1; }
|
|
|
|
|
| opt_all_clause { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
2002-08-28 16:35:37 +02:00
|
|
|
opt_sort_clause:
|
2021-01-22 22:26:22 +01:00
|
|
|
sort_clause { $$ = $1; }
|
2002-08-28 16:35:37 +02:00
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
sort_clause:
|
|
|
|
|
ORDER BY sortby_list { $$ = $3; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
sortby_list:
|
2004-05-31 01:40:41 +02:00
|
|
|
sortby { $$ = list_make1($1); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| sortby_list ',' sortby { $$ = lappend($1, $3); }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2007-01-09 03:14:16 +01:00
|
|
|
sortby: a_expr USING qual_all_Op opt_nulls_order
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2003-08-17 21:58:06 +02:00
|
|
|
$$ = makeNode(SortBy);
|
1998-08-05 06:49:19 +02:00
|
|
|
$$->node = $1;
|
2007-01-09 03:14:16 +01:00
|
|
|
$$->sortby_dir = SORTBY_USING;
|
|
|
|
|
$$->sortby_nulls = $4;
|
2003-08-17 21:58:06 +02:00
|
|
|
$$->useOp = $3;
|
2008-09-01 22:42:46 +02:00
|
|
|
$$->location = @3;
|
2003-08-17 21:58:06 +02:00
|
|
|
}
|
2007-03-17 20:27:12 +01:00
|
|
|
| a_expr opt_asc_desc opt_nulls_order
|
2003-08-17 21:58:06 +02:00
|
|
|
{
|
|
|
|
|
$$ = makeNode(SortBy);
|
|
|
|
|
$$->node = $1;
|
2007-03-17 20:27:12 +01:00
|
|
|
$$->sortby_dir = $2;
|
2007-01-09 03:14:16 +01:00
|
|
|
$$->sortby_nulls = $3;
|
2003-08-17 21:58:06 +02:00
|
|
|
$$->useOp = NIL;
|
2008-09-01 22:42:46 +02:00
|
|
|
$$->location = -1; /* no operator */
|
2003-08-17 21:58:06 +02:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1999-02-08 15:14:32 +01:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
select_limit:
|
2020-04-07 22:22:13 +02:00
|
|
|
limit_clause offset_clause
|
|
|
|
|
{
|
|
|
|
|
$$ = $1;
|
|
|
|
|
($$)->limitOffset = $2;
|
|
|
|
|
}
|
|
|
|
|
| offset_clause limit_clause
|
|
|
|
|
{
|
|
|
|
|
$$ = $2;
|
|
|
|
|
($$)->limitOffset = $1;
|
|
|
|
|
}
|
|
|
|
|
| limit_clause
|
|
|
|
|
{
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
|
|
|
|
| offset_clause
|
|
|
|
|
{
|
|
|
|
|
SelectLimit *n = (SelectLimit *) palloc(sizeof(SelectLimit));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2020-04-07 22:22:13 +02:00
|
|
|
n->limitOffset = $1;
|
|
|
|
|
n->limitCount = NULL;
|
|
|
|
|
n->limitOption = LIMIT_OPTION_COUNT;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2009-08-19 01:40:20 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_select_limit:
|
|
|
|
|
select_limit { $$ = $1; }
|
2020-04-07 22:22:13 +02:00
|
|
|
| /* EMPTY */ { $$ = NULL; }
|
2009-08-19 01:40:20 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
limit_clause:
|
|
|
|
|
LIMIT select_limit_value
|
2020-04-07 22:22:13 +02:00
|
|
|
{
|
|
|
|
|
SelectLimit *n = (SelectLimit *) palloc(sizeof(SelectLimit));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2020-04-07 22:22:13 +02:00
|
|
|
n->limitOffset = NULL;
|
|
|
|
|
n->limitCount = $2;
|
|
|
|
|
n->limitOption = LIMIT_OPTION_COUNT;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| LIMIT select_limit_value ',' select_offset_value
|
2003-07-03 21:07:54 +02:00
|
|
|
{
|
|
|
|
|
/* Disabled because it was too confusing, bjm 2002-02-18 */
|
2003-07-19 22:20:53 +02:00
|
|
|
ereport(ERROR,
|
2003-09-10 01:22:21 +02:00
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
2003-07-19 22:20:53 +02:00
|
|
|
errmsg("LIMIT #,# syntax is not supported"),
|
2008-09-01 22:42:46 +02:00
|
|
|
errhint("Use separate LIMIT and OFFSET clauses."),
|
2009-07-13 04:02:20 +02:00
|
|
|
parser_errposition(@1)));
|
2003-07-03 21:07:54 +02:00
|
|
|
}
|
2009-08-19 01:40:20 +02:00
|
|
|
/* SQL:2008 syntax */
|
2018-05-21 18:02:17 +02:00
|
|
|
/* to avoid shift/reduce conflicts, handle the optional value with
|
|
|
|
|
* a separate production rather than an opt_ expression. The fact
|
|
|
|
|
* that ONLY is fully reserved means that this way, we defer any
|
|
|
|
|
* decision about what rule reduces ROW or ROWS to the point where
|
|
|
|
|
* we can see the ONLY token in the lookahead slot.
|
|
|
|
|
*/
|
|
|
|
|
| FETCH first_or_next select_fetch_first_value row_or_rows ONLY
|
2020-04-07 22:22:13 +02:00
|
|
|
{
|
|
|
|
|
SelectLimit *n = (SelectLimit *) palloc(sizeof(SelectLimit));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2020-04-07 22:22:13 +02:00
|
|
|
n->limitOffset = NULL;
|
|
|
|
|
n->limitCount = $3;
|
|
|
|
|
n->limitOption = LIMIT_OPTION_COUNT;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| FETCH first_or_next select_fetch_first_value row_or_rows WITH TIES
|
|
|
|
|
{
|
|
|
|
|
SelectLimit *n = (SelectLimit *) palloc(sizeof(SelectLimit));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2020-04-07 22:22:13 +02:00
|
|
|
n->limitOffset = NULL;
|
|
|
|
|
n->limitCount = $3;
|
|
|
|
|
n->limitOption = LIMIT_OPTION_WITH_TIES;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2018-05-21 18:02:17 +02:00
|
|
|
| FETCH first_or_next row_or_rows ONLY
|
2020-04-07 22:22:13 +02:00
|
|
|
{
|
|
|
|
|
SelectLimit *n = (SelectLimit *) palloc(sizeof(SelectLimit));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2020-04-07 22:22:13 +02:00
|
|
|
n->limitOffset = NULL;
|
|
|
|
|
n->limitCount = makeIntConst(1, -1);
|
|
|
|
|
n->limitOption = LIMIT_OPTION_COUNT;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2020-05-19 01:28:46 +02:00
|
|
|
| FETCH first_or_next row_or_rows WITH TIES
|
|
|
|
|
{
|
|
|
|
|
SelectLimit *n = (SelectLimit *) palloc(sizeof(SelectLimit));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2020-05-19 01:28:46 +02:00
|
|
|
n->limitOffset = NULL;
|
|
|
|
|
n->limitCount = makeIntConst(1, -1);
|
|
|
|
|
n->limitOption = LIMIT_OPTION_WITH_TIES;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2000-11-05 01:15:54 +01:00
|
|
|
;
|
|
|
|
|
|
2009-08-19 01:40:20 +02:00
|
|
|
offset_clause:
|
|
|
|
|
OFFSET select_offset_value
|
|
|
|
|
{ $$ = $2; }
|
|
|
|
|
/* SQL:2008 syntax */
|
2018-05-21 18:02:17 +02:00
|
|
|
| OFFSET select_fetch_first_value row_or_rows
|
2009-08-19 01:40:20 +02:00
|
|
|
{ $$ = $2; }
|
1999-02-08 15:14:32 +01:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
select_limit_value:
|
2003-07-03 21:07:54 +02:00
|
|
|
a_expr { $$ = $1; }
|
2002-06-17 22:27:43 +02:00
|
|
|
| ALL
|
|
|
|
|
{
|
|
|
|
|
/* LIMIT ALL is represented as a NULL constant */
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeNullAConst(@1);
|
2002-06-17 22:27:43 +02:00
|
|
|
}
|
1999-02-08 15:14:32 +01:00
|
|
|
;
|
|
|
|
|
|
2009-08-19 01:40:20 +02:00
|
|
|
select_offset_value:
|
|
|
|
|
a_expr { $$ = $1; }
|
|
|
|
|
;
|
|
|
|
|
|
2008-10-22 13:00:34 +02:00
|
|
|
/*
|
|
|
|
|
* Allowing full expressions without parentheses causes various parsing
|
2018-05-21 18:02:17 +02:00
|
|
|
* problems with the trailing ROW/ROWS key words. SQL spec only calls for
|
|
|
|
|
* <simple value specification>, which is either a literal or a parameter (but
|
|
|
|
|
* an <SQL parameter reference> could be an identifier, bringing up conflicts
|
|
|
|
|
* with ROW/ROWS). We solve this by leveraging the presence of ONLY (see above)
|
|
|
|
|
* to determine whether the expression is missing rather than trying to make it
|
|
|
|
|
* optional in this rule.
|
|
|
|
|
*
|
|
|
|
|
* c_expr covers almost all the spec-required cases (and more), but it doesn't
|
|
|
|
|
* cover signed numeric literals, which are allowed by the spec. So we include
|
|
|
|
|
* those here explicitly. We need FCONST as well as ICONST because values that
|
|
|
|
|
* don't fit in the platform's "long", but do fit in bigint, should still be
|
|
|
|
|
* accepted here. (This is possible in 64-bit Windows as well as all 32-bit
|
|
|
|
|
* builds.)
|
2008-10-22 13:00:34 +02:00
|
|
|
*/
|
2018-05-21 18:02:17 +02:00
|
|
|
select_fetch_first_value:
|
|
|
|
|
c_expr { $$ = $1; }
|
|
|
|
|
| '+' I_or_F_const
|
|
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "+", NULL, $2, @1); }
|
|
|
|
|
| '-' I_or_F_const
|
|
|
|
|
{ $$ = doNegate($2, @1); }
|
1999-02-08 15:14:32 +01:00
|
|
|
;
|
2000-11-05 01:15:54 +01:00
|
|
|
|
2018-05-21 18:02:17 +02:00
|
|
|
I_or_F_const:
|
|
|
|
|
Iconst { $$ = makeIntConst($1,@1); }
|
|
|
|
|
| FCONST { $$ = makeFloatConst($1,@1); }
|
2008-10-22 13:00:34 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/* noise words */
|
2009-08-19 01:40:20 +02:00
|
|
|
row_or_rows: ROW { $$ = 0; }
|
|
|
|
|
| ROWS { $$ = 0; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
first_or_next: FIRST_P { $$ = 0; }
|
|
|
|
|
| NEXT { $$ = 0; }
|
|
|
|
|
;
|
2008-10-22 13:00:34 +02:00
|
|
|
|
|
|
|
|
|
Support GROUPING SETS, CUBE and ROLLUP.
This SQL standard functionality allows to aggregate data by different
GROUP BY clauses at once. Each grouping set returns rows with columns
grouped by in other sets set to NULL.
This could previously be achieved by doing each grouping as a separate
query, conjoined by UNION ALLs. Besides being considerably more concise,
grouping sets will in many cases be faster, requiring only one scan over
the underlying data.
The current implementation of grouping sets only supports using sorting
for input. Individual sets that share a sort order are computed in one
pass. If there are sets that don't share a sort order, additional sort &
aggregation steps are performed. These additional passes are sourced by
the previous sort step; thus avoiding repeated scans of the source data.
The code is structured in a way that adding support for purely using
hash aggregation or a mix of hashing and sorting is possible. Sorting
was chosen to be supported first, as it is the most generic method of
implementation.
Instead of, as in an earlier versions of the patch, representing the
chain of sort and aggregation steps as full blown planner and executor
nodes, all but the first sort are performed inside the aggregation node
itself. This avoids the need to do some unusual gymnastics to handle
having to return aggregated and non-aggregated tuples from underlying
nodes, as well as having to shut down underlying nodes early to limit
memory usage. The optimizer still builds Sort/Agg node to describe each
phase, but they're not part of the plan tree, but instead additional
data for the aggregation node. They're a convenient and preexisting way
to describe aggregation and sorting. The first (and possibly only) sort
step is still performed as a separate execution step. That retains
similarity with existing group by plans, makes rescans fairly simple,
avoids very deep plans (leading to slow explains) and easily allows to
avoid the sorting step if the underlying data is sorted by other means.
A somewhat ugly side of this patch is having to deal with a grammar
ambiguity between the new CUBE keyword and the cube extension/functions
named cube (and rollup). To avoid breaking existing deployments of the
cube extension it has not been renamed, neither has cube been made a
reserved keyword. Instead precedence hacking is used to make GROUP BY
cube(..) refer to the CUBE grouping sets feature, and not the function
cube(). To actually group by a function cube(), unlikely as that might
be, the function name has to be quoted.
Needs a catversion bump because stored rules may change.
Author: Andrew Gierth and Atri Sharma, with contributions from Andres Freund
Reviewed-By: Andres Freund, Noah Misch, Tom Lane, Svenne Krap, Tomas
Vondra, Erik Rijkers, Marti Raudsepp, Pavel Stehule
Discussion: CAOeZVidmVRe2jU6aMk_5qkxnB7dfmPROzM7Ur8JPW5j8Y5X-Lw@mail.gmail.com
2015-05-16 03:40:59 +02:00
|
|
|
/*
|
|
|
|
|
* This syntax for group_clause tries to follow the spec quite closely.
|
|
|
|
|
* However, the spec allows only column references, not expressions,
|
|
|
|
|
* which introduces an ambiguity between implicit row constructors
|
|
|
|
|
* (a,b) and lists of column references.
|
|
|
|
|
*
|
|
|
|
|
* We handle this by using the a_expr production for what the spec calls
|
|
|
|
|
* <ordinary grouping set>, which in the spec represents either one column
|
|
|
|
|
* reference or a parenthesized list of column references. Then, we check the
|
|
|
|
|
* top node of the a_expr to see if it's an implicit RowExpr, and if so, just
|
|
|
|
|
* grab and use the list, discarding the node. (this is done in parse analysis,
|
|
|
|
|
* not here)
|
|
|
|
|
*
|
|
|
|
|
* (we abuse the row_format field of RowExpr to distinguish implicit and
|
|
|
|
|
* explicit row constructors; it's debatable if anyone sanely wants to use them
|
|
|
|
|
* in a group clause, but if they have a reason to, we make it possible.)
|
|
|
|
|
*
|
|
|
|
|
* Each item in the group_clause list is either an expression tree or a
|
|
|
|
|
* GroupingSet node of some type.
|
|
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
group_clause:
|
Implement GROUP BY DISTINCT
With grouping sets, it's possible that some of the grouping sets are
duplicate. This is especially common with CUBE and ROLLUP clauses. For
example GROUP BY CUBE (a,b), CUBE (b,c) is equivalent to
GROUP BY GROUPING SETS (
(a, b, c),
(a, b, c),
(a, b, c),
(a, b),
(a, b),
(a, b),
(a),
(a),
(a),
(c, a),
(c, a),
(c, a),
(c),
(b, c),
(b),
()
)
Some of the grouping sets are calculated multiple times, which is mostly
unnecessary. This commit implements a new GROUP BY DISTINCT feature, as
defined in the SQL standard, which eliminates the duplicate sets.
Author: Vik Fearing
Reviewed-by: Erik Rijkers, Georgios Kokolatos, Tomas Vondra
Discussion: https://postgr.es/m/bf3805a8-d7d1-ae61-fece-761b7ff41ecc@postgresfriends.org
2021-03-18 17:45:38 +01:00
|
|
|
GROUP_P BY set_quantifier group_by_list
|
|
|
|
|
{
|
|
|
|
|
GroupClause *n = (GroupClause *) palloc(sizeof(GroupClause));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Implement GROUP BY DISTINCT
With grouping sets, it's possible that some of the grouping sets are
duplicate. This is especially common with CUBE and ROLLUP clauses. For
example GROUP BY CUBE (a,b), CUBE (b,c) is equivalent to
GROUP BY GROUPING SETS (
(a, b, c),
(a, b, c),
(a, b, c),
(a, b),
(a, b),
(a, b),
(a),
(a),
(a),
(c, a),
(c, a),
(c, a),
(c),
(b, c),
(b),
()
)
Some of the grouping sets are calculated multiple times, which is mostly
unnecessary. This commit implements a new GROUP BY DISTINCT feature, as
defined in the SQL standard, which eliminates the duplicate sets.
Author: Vik Fearing
Reviewed-by: Erik Rijkers, Georgios Kokolatos, Tomas Vondra
Discussion: https://postgr.es/m/bf3805a8-d7d1-ae61-fece-761b7ff41ecc@postgresfriends.org
2021-03-18 17:45:38 +01:00
|
|
|
n->distinct = $3 == SET_QUANTIFIER_DISTINCT;
|
|
|
|
|
n->list = $4;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| /*EMPTY*/
|
|
|
|
|
{
|
|
|
|
|
GroupClause *n = (GroupClause *) palloc(sizeof(GroupClause));
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Implement GROUP BY DISTINCT
With grouping sets, it's possible that some of the grouping sets are
duplicate. This is especially common with CUBE and ROLLUP clauses. For
example GROUP BY CUBE (a,b), CUBE (b,c) is equivalent to
GROUP BY GROUPING SETS (
(a, b, c),
(a, b, c),
(a, b, c),
(a, b),
(a, b),
(a, b),
(a),
(a),
(a),
(c, a),
(c, a),
(c, a),
(c),
(b, c),
(b),
()
)
Some of the grouping sets are calculated multiple times, which is mostly
unnecessary. This commit implements a new GROUP BY DISTINCT feature, as
defined in the SQL standard, which eliminates the duplicate sets.
Author: Vik Fearing
Reviewed-by: Erik Rijkers, Georgios Kokolatos, Tomas Vondra
Discussion: https://postgr.es/m/bf3805a8-d7d1-ae61-fece-761b7ff41ecc@postgresfriends.org
2021-03-18 17:45:38 +01:00
|
|
|
n->distinct = false;
|
|
|
|
|
n->list = NIL;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
Support GROUPING SETS, CUBE and ROLLUP.
This SQL standard functionality allows to aggregate data by different
GROUP BY clauses at once. Each grouping set returns rows with columns
grouped by in other sets set to NULL.
This could previously be achieved by doing each grouping as a separate
query, conjoined by UNION ALLs. Besides being considerably more concise,
grouping sets will in many cases be faster, requiring only one scan over
the underlying data.
The current implementation of grouping sets only supports using sorting
for input. Individual sets that share a sort order are computed in one
pass. If there are sets that don't share a sort order, additional sort &
aggregation steps are performed. These additional passes are sourced by
the previous sort step; thus avoiding repeated scans of the source data.
The code is structured in a way that adding support for purely using
hash aggregation or a mix of hashing and sorting is possible. Sorting
was chosen to be supported first, as it is the most generic method of
implementation.
Instead of, as in an earlier versions of the patch, representing the
chain of sort and aggregation steps as full blown planner and executor
nodes, all but the first sort are performed inside the aggregation node
itself. This avoids the need to do some unusual gymnastics to handle
having to return aggregated and non-aggregated tuples from underlying
nodes, as well as having to shut down underlying nodes early to limit
memory usage. The optimizer still builds Sort/Agg node to describe each
phase, but they're not part of the plan tree, but instead additional
data for the aggregation node. They're a convenient and preexisting way
to describe aggregation and sorting. The first (and possibly only) sort
step is still performed as a separate execution step. That retains
similarity with existing group by plans, makes rescans fairly simple,
avoids very deep plans (leading to slow explains) and easily allows to
avoid the sorting step if the underlying data is sorted by other means.
A somewhat ugly side of this patch is having to deal with a grammar
ambiguity between the new CUBE keyword and the cube extension/functions
named cube (and rollup). To avoid breaking existing deployments of the
cube extension it has not been renamed, neither has cube been made a
reserved keyword. Instead precedence hacking is used to make GROUP BY
cube(..) refer to the CUBE grouping sets feature, and not the function
cube(). To actually group by a function cube(), unlikely as that might
be, the function name has to be quoted.
Needs a catversion bump because stored rules may change.
Author: Andrew Gierth and Atri Sharma, with contributions from Andres Freund
Reviewed-By: Andres Freund, Noah Misch, Tom Lane, Svenne Krap, Tomas
Vondra, Erik Rijkers, Marti Raudsepp, Pavel Stehule
Discussion: CAOeZVidmVRe2jU6aMk_5qkxnB7dfmPROzM7Ur8JPW5j8Y5X-Lw@mail.gmail.com
2015-05-16 03:40:59 +02:00
|
|
|
group_by_list:
|
|
|
|
|
group_by_item { $$ = list_make1($1); }
|
|
|
|
|
| group_by_list ',' group_by_item { $$ = lappend($1,$3); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
group_by_item:
|
|
|
|
|
a_expr { $$ = $1; }
|
|
|
|
|
| empty_grouping_set { $$ = $1; }
|
|
|
|
|
| cube_clause { $$ = $1; }
|
|
|
|
|
| rollup_clause { $$ = $1; }
|
|
|
|
|
| grouping_sets_clause { $$ = $1; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
empty_grouping_set:
|
|
|
|
|
'(' ')'
|
|
|
|
|
{
|
|
|
|
|
$$ = (Node *) makeGroupingSet(GROUPING_SET_EMPTY, NIL, @1);
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* These hacks rely on setting precedence of CUBE and ROLLUP below that of '(',
|
|
|
|
|
* so that they shift in these rules rather than reducing the conflicting
|
|
|
|
|
* unreserved_keyword rule.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
rollup_clause:
|
|
|
|
|
ROLLUP '(' expr_list ')'
|
|
|
|
|
{
|
|
|
|
|
$$ = (Node *) makeGroupingSet(GROUPING_SET_ROLLUP, $3, @1);
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
cube_clause:
|
|
|
|
|
CUBE '(' expr_list ')'
|
|
|
|
|
{
|
|
|
|
|
$$ = (Node *) makeGroupingSet(GROUPING_SET_CUBE, $3, @1);
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
grouping_sets_clause:
|
|
|
|
|
GROUPING SETS '(' group_by_list ')'
|
|
|
|
|
{
|
|
|
|
|
$$ = (Node *) makeGroupingSet(GROUPING_SET_SETS, $4, @1);
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
having_clause:
|
|
|
|
|
HAVING a_expr { $$ = $2; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2005-04-28 23:47:18 +02:00
|
|
|
for_locking_clause:
|
2006-04-30 20:30:40 +02:00
|
|
|
for_locking_items { $$ = $1; }
|
|
|
|
|
| FOR READ ONLY { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_for_locking_clause:
|
|
|
|
|
for_locking_clause { $$ = $1; }
|
|
|
|
|
| /* EMPTY */ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
for_locking_items:
|
|
|
|
|
for_locking_item { $$ = list_make1($1); }
|
|
|
|
|
| for_locking_items for_locking_item { $$ = lappend($1, $2); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
for_locking_item:
|
2014-10-07 22:23:34 +02:00
|
|
|
for_locking_strength locked_rels_list opt_nowait_or_skip
|
2005-08-01 22:31:16 +02:00
|
|
|
{
|
|
|
|
|
LockingClause *n = makeNode(LockingClause);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
n->lockedRels = $2;
|
|
|
|
|
n->strength = $1;
|
2014-10-07 22:23:34 +02:00
|
|
|
n->waitPolicy = $3;
|
2005-08-01 22:31:16 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
1999-02-23 08:42:41 +01:00
|
|
|
;
|
|
|
|
|
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
for_locking_strength:
|
2020-11-11 17:37:18 +01:00
|
|
|
FOR UPDATE { $$ = LCS_FORUPDATE; }
|
|
|
|
|
| FOR NO KEY UPDATE { $$ = LCS_FORNOKEYUPDATE; }
|
|
|
|
|
| FOR SHARE { $$ = LCS_FORSHARE; }
|
|
|
|
|
| FOR KEY SHARE { $$ = LCS_FORKEYSHARE; }
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
;
|
|
|
|
|
|
2005-08-01 22:31:16 +02:00
|
|
|
locked_rels_list:
|
2008-09-01 22:42:46 +02:00
|
|
|
OF qualified_name_list { $$ = $2; }
|
2005-08-01 22:31:16 +02:00
|
|
|
| /* EMPTY */ { $$ = NIL; }
|
1999-01-05 16:46:25 +01:00
|
|
|
;
|
1997-10-25 07:56:41 +02:00
|
|
|
|
2006-08-02 03:59:48 +02:00
|
|
|
|
Improve handling of "UPDATE ... SET (column_list) = row_constructor".
Previously, the right-hand side of a multiple-column assignment, if it
wasn't a sub-SELECT, had to be a simple parenthesized expression list,
because gram.y was responsible for "bursting" the construct into
independent column assignments. This had the minor defect that you
couldn't write ROW (though you should be able to, since the standard says
this is a row constructor), and the rather larger defect that unlike other
uses of row constructors, we would not expand a "foo.*" item into multiple
columns.
Fix that by changing the RHS to be just "a_expr" in the grammar, leaving
it to transformMultiAssignRef to separate the elements of a RowExpr;
which it will do only after performing standard transformation of the
RowExpr, so that "foo.*" behaves as expected.
The key reason we didn't do that before was the hard-wired handling of
DEFAULT tokens (SetToDefault nodes). This patch deals with that issue by
allowing DEFAULT in any a_expr and having parse analysis throw an error
if SetToDefault is found in an unexpected place. That's an improvement
anyway since the error can be more specific than just "syntax error".
The SQL standard suggests that the RHS could be any a_expr yielding a
suitable row value. This patch doesn't really move the goal posts in that
respect --- you're still limited to RowExpr or a sub-SELECT --- but it does
fix the grammar restriction, so it provides some tangible progress towards
a full implementation. And the limitation is now documented by an explicit
error message rather than an unhelpful "syntax error".
Discussion: <8542.1479742008@sss.pgh.pa.us>
2016-11-22 21:19:57 +01:00
|
|
|
/*
|
|
|
|
|
* We should allow ROW '(' expr_list ')' too, but that seems to require
|
|
|
|
|
* making VALUES a fully reserved word, which will probably break more apps
|
|
|
|
|
* than allowing the noise-word is worth.
|
|
|
|
|
*/
|
2006-08-02 03:59:48 +02:00
|
|
|
values_clause:
|
Improve handling of "UPDATE ... SET (column_list) = row_constructor".
Previously, the right-hand side of a multiple-column assignment, if it
wasn't a sub-SELECT, had to be a simple parenthesized expression list,
because gram.y was responsible for "bursting" the construct into
independent column assignments. This had the minor defect that you
couldn't write ROW (though you should be able to, since the standard says
this is a row constructor), and the rather larger defect that unlike other
uses of row constructors, we would not expand a "foo.*" item into multiple
columns.
Fix that by changing the RHS to be just "a_expr" in the grammar, leaving
it to transformMultiAssignRef to separate the elements of a RowExpr;
which it will do only after performing standard transformation of the
RowExpr, so that "foo.*" behaves as expected.
The key reason we didn't do that before was the hard-wired handling of
DEFAULT tokens (SetToDefault nodes). This patch deals with that issue by
allowing DEFAULT in any a_expr and having parse analysis throw an error
if SetToDefault is found in an unexpected place. That's an improvement
anyway since the error can be more specific than just "syntax error".
The SQL standard suggests that the RHS could be any a_expr yielding a
suitable row value. This patch doesn't really move the goal posts in that
respect --- you're still limited to RowExpr or a sub-SELECT --- but it does
fix the grammar restriction, so it provides some tangible progress towards
a full implementation. And the limitation is now documented by an explicit
error message rather than an unhelpful "syntax error".
Discussion: <8542.1479742008@sss.pgh.pa.us>
2016-11-22 21:19:57 +01:00
|
|
|
VALUES '(' expr_list ')'
|
2006-08-02 03:59:48 +02:00
|
|
|
{
|
|
|
|
|
SelectStmt *n = makeNode(SelectStmt);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Improve handling of "UPDATE ... SET (column_list) = row_constructor".
Previously, the right-hand side of a multiple-column assignment, if it
wasn't a sub-SELECT, had to be a simple parenthesized expression list,
because gram.y was responsible for "bursting" the construct into
independent column assignments. This had the minor defect that you
couldn't write ROW (though you should be able to, since the standard says
this is a row constructor), and the rather larger defect that unlike other
uses of row constructors, we would not expand a "foo.*" item into multiple
columns.
Fix that by changing the RHS to be just "a_expr" in the grammar, leaving
it to transformMultiAssignRef to separate the elements of a RowExpr;
which it will do only after performing standard transformation of the
RowExpr, so that "foo.*" behaves as expected.
The key reason we didn't do that before was the hard-wired handling of
DEFAULT tokens (SetToDefault nodes). This patch deals with that issue by
allowing DEFAULT in any a_expr and having parse analysis throw an error
if SetToDefault is found in an unexpected place. That's an improvement
anyway since the error can be more specific than just "syntax error".
The SQL standard suggests that the RHS could be any a_expr yielding a
suitable row value. This patch doesn't really move the goal posts in that
respect --- you're still limited to RowExpr or a sub-SELECT --- but it does
fix the grammar restriction, so it provides some tangible progress towards
a full implementation. And the limitation is now documented by an explicit
error message rather than an unhelpful "syntax error".
Discussion: <8542.1479742008@sss.pgh.pa.us>
2016-11-22 21:19:57 +01:00
|
|
|
n->valuesLists = list_make1($3);
|
2006-08-02 03:59:48 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
Improve handling of "UPDATE ... SET (column_list) = row_constructor".
Previously, the right-hand side of a multiple-column assignment, if it
wasn't a sub-SELECT, had to be a simple parenthesized expression list,
because gram.y was responsible for "bursting" the construct into
independent column assignments. This had the minor defect that you
couldn't write ROW (though you should be able to, since the standard says
this is a row constructor), and the rather larger defect that unlike other
uses of row constructors, we would not expand a "foo.*" item into multiple
columns.
Fix that by changing the RHS to be just "a_expr" in the grammar, leaving
it to transformMultiAssignRef to separate the elements of a RowExpr;
which it will do only after performing standard transformation of the
RowExpr, so that "foo.*" behaves as expected.
The key reason we didn't do that before was the hard-wired handling of
DEFAULT tokens (SetToDefault nodes). This patch deals with that issue by
allowing DEFAULT in any a_expr and having parse analysis throw an error
if SetToDefault is found in an unexpected place. That's an improvement
anyway since the error can be more specific than just "syntax error".
The SQL standard suggests that the RHS could be any a_expr yielding a
suitable row value. This patch doesn't really move the goal posts in that
respect --- you're still limited to RowExpr or a sub-SELECT --- but it does
fix the grammar restriction, so it provides some tangible progress towards
a full implementation. And the limitation is now documented by an explicit
error message rather than an unhelpful "syntax error".
Discussion: <8542.1479742008@sss.pgh.pa.us>
2016-11-22 21:19:57 +01:00
|
|
|
| values_clause ',' '(' expr_list ')'
|
2006-08-02 03:59:48 +02:00
|
|
|
{
|
|
|
|
|
SelectStmt *n = (SelectStmt *) $1;
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Improve handling of "UPDATE ... SET (column_list) = row_constructor".
Previously, the right-hand side of a multiple-column assignment, if it
wasn't a sub-SELECT, had to be a simple parenthesized expression list,
because gram.y was responsible for "bursting" the construct into
independent column assignments. This had the minor defect that you
couldn't write ROW (though you should be able to, since the standard says
this is a row constructor), and the rather larger defect that unlike other
uses of row constructors, we would not expand a "foo.*" item into multiple
columns.
Fix that by changing the RHS to be just "a_expr" in the grammar, leaving
it to transformMultiAssignRef to separate the elements of a RowExpr;
which it will do only after performing standard transformation of the
RowExpr, so that "foo.*" behaves as expected.
The key reason we didn't do that before was the hard-wired handling of
DEFAULT tokens (SetToDefault nodes). This patch deals with that issue by
allowing DEFAULT in any a_expr and having parse analysis throw an error
if SetToDefault is found in an unexpected place. That's an improvement
anyway since the error can be more specific than just "syntax error".
The SQL standard suggests that the RHS could be any a_expr yielding a
suitable row value. This patch doesn't really move the goal posts in that
respect --- you're still limited to RowExpr or a sub-SELECT --- but it does
fix the grammar restriction, so it provides some tangible progress towards
a full implementation. And the limitation is now documented by an explicit
error message rather than an unhelpful "syntax error".
Discussion: <8542.1479742008@sss.pgh.pa.us>
2016-11-22 21:19:57 +01:00
|
|
|
n->valuesLists = lappend(n->valuesLists, $4);
|
2006-08-02 03:59:48 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*****************************************************************************
|
1997-09-01 08:00:35 +02:00
|
|
|
*
|
1997-09-08 05:20:18 +02:00
|
|
|
* clauses common to all Optimizable Stmts:
|
2000-02-15 04:26:38 +01:00
|
|
|
* from_clause - allow list of both JOIN expressions and table names
|
|
|
|
|
* where_clause - qualifications for joins or restrictions
|
1997-09-01 08:00:35 +02:00
|
|
|
*
|
1996-07-09 08:22:35 +02:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
from_clause:
|
|
|
|
|
FROM from_list { $$ = $2; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-18 02:28:11 +02:00
|
|
|
from_list:
|
2004-05-31 01:40:41 +02:00
|
|
|
table_ref { $$ = list_make1($1); }
|
2002-06-18 02:28:11 +02:00
|
|
|
| from_list ',' table_ref { $$ = lappend($1, $3); }
|
1999-02-23 08:42:41 +01:00
|
|
|
;
|
|
|
|
|
|
2000-09-12 23:07:18 +02:00
|
|
|
/*
|
2012-08-08 01:02:54 +02:00
|
|
|
* table_ref is where an alias clause can be attached.
|
2000-09-12 23:07:18 +02:00
|
|
|
*/
|
2012-08-08 01:02:54 +02:00
|
|
|
table_ref: relation_expr opt_alias_clause
|
2000-02-15 04:26:38 +01:00
|
|
|
{
|
2002-03-21 17:02:16 +01:00
|
|
|
$1->alias = $2;
|
2000-09-12 23:07:18 +02:00
|
|
|
$$ = (Node *) $1;
|
2000-02-15 04:26:38 +01:00
|
|
|
}
|
Redesign tablesample method API, and do extensive code review.
The original implementation of TABLESAMPLE modeled the tablesample method
API on index access methods, which wasn't a good choice because, without
specialized DDL commands, there's no way to build an extension that can
implement a TSM. (Raw inserts into system catalogs are not an acceptable
thing to do, because we can't undo them during DROP EXTENSION, nor will
pg_upgrade behave sanely.) Instead adopt an API more like procedural
language handlers or foreign data wrappers, wherein the only SQL-level
support object needed is a single handler function identified by having
a special return type. This lets us get rid of the supporting catalog
altogether, so that no custom DDL support is needed for the feature.
Adjust the API so that it can support non-constant tablesample arguments
(the original coding assumed we could evaluate the argument expressions at
ExecInitSampleScan time, which is undesirable even if it weren't outright
unsafe), and discourage sampling methods from looking at invisible tuples.
Make sure that the BERNOULLI and SYSTEM methods are genuinely repeatable
within and across queries, as required by the SQL standard, and deal more
honestly with methods that can't support that requirement.
Make a full code-review pass over the tablesample additions, and fix
assorted bugs, omissions, infelicities, and cosmetic issues (such as
failure to put the added code stanzas in a consistent ordering).
Improve EXPLAIN's output of tablesample plans, too.
Back-patch to 9.5 so that we don't have to support the original API
in production.
2015-07-25 20:39:00 +02:00
|
|
|
| relation_expr opt_alias_clause tablesample_clause
|
2015-05-15 20:37:10 +02:00
|
|
|
{
|
Redesign tablesample method API, and do extensive code review.
The original implementation of TABLESAMPLE modeled the tablesample method
API on index access methods, which wasn't a good choice because, without
specialized DDL commands, there's no way to build an extension that can
implement a TSM. (Raw inserts into system catalogs are not an acceptable
thing to do, because we can't undo them during DROP EXTENSION, nor will
pg_upgrade behave sanely.) Instead adopt an API more like procedural
language handlers or foreign data wrappers, wherein the only SQL-level
support object needed is a single handler function identified by having
a special return type. This lets us get rid of the supporting catalog
altogether, so that no custom DDL support is needed for the feature.
Adjust the API so that it can support non-constant tablesample arguments
(the original coding assumed we could evaluate the argument expressions at
ExecInitSampleScan time, which is undesirable even if it weren't outright
unsafe), and discourage sampling methods from looking at invisible tuples.
Make sure that the BERNOULLI and SYSTEM methods are genuinely repeatable
within and across queries, as required by the SQL standard, and deal more
honestly with methods that can't support that requirement.
Make a full code-review pass over the tablesample additions, and fix
assorted bugs, omissions, infelicities, and cosmetic issues (such as
failure to put the added code stanzas in a consistent ordering).
Improve EXPLAIN's output of tablesample plans, too.
Back-patch to 9.5 so that we don't have to support the original API
in production.
2015-07-25 20:39:00 +02:00
|
|
|
RangeTableSample *n = (RangeTableSample *) $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Redesign tablesample method API, and do extensive code review.
The original implementation of TABLESAMPLE modeled the tablesample method
API on index access methods, which wasn't a good choice because, without
specialized DDL commands, there's no way to build an extension that can
implement a TSM. (Raw inserts into system catalogs are not an acceptable
thing to do, because we can't undo them during DROP EXTENSION, nor will
pg_upgrade behave sanely.) Instead adopt an API more like procedural
language handlers or foreign data wrappers, wherein the only SQL-level
support object needed is a single handler function identified by having
a special return type. This lets us get rid of the supporting catalog
altogether, so that no custom DDL support is needed for the feature.
Adjust the API so that it can support non-constant tablesample arguments
(the original coding assumed we could evaluate the argument expressions at
ExecInitSampleScan time, which is undesirable even if it weren't outright
unsafe), and discourage sampling methods from looking at invisible tuples.
Make sure that the BERNOULLI and SYSTEM methods are genuinely repeatable
within and across queries, as required by the SQL standard, and deal more
honestly with methods that can't support that requirement.
Make a full code-review pass over the tablesample additions, and fix
assorted bugs, omissions, infelicities, and cosmetic issues (such as
failure to put the added code stanzas in a consistent ordering).
Improve EXPLAIN's output of tablesample plans, too.
Back-patch to 9.5 so that we don't have to support the original API
in production.
2015-07-25 20:39:00 +02:00
|
|
|
$1->alias = $2;
|
|
|
|
|
/* relation_expr goes inside the RangeTableSample node */
|
|
|
|
|
n->relation = (Node *) $1;
|
|
|
|
|
$$ = (Node *) n;
|
2015-05-15 20:37:10 +02:00
|
|
|
}
|
2012-08-08 01:02:54 +02:00
|
|
|
| func_table func_alias_clause
|
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 21:48:11 +02:00
|
|
|
{
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
RangeFunction *n = (RangeFunction *) $1;
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-08-08 01:02:54 +02:00
|
|
|
n->alias = linitial($2);
|
|
|
|
|
n->coldeflist = lsecond($2);
|
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 21:48:11 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2012-08-08 01:02:54 +02:00
|
|
|
| LATERAL_P func_table func_alias_clause
|
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 21:48:11 +02:00
|
|
|
{
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
RangeFunction *n = (RangeFunction *) $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-08-08 01:02:54 +02:00
|
|
|
n->lateral = true;
|
|
|
|
|
n->alias = linitial($3);
|
|
|
|
|
n->coldeflist = lsecond($3);
|
2002-05-12 22:10:05 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2017-03-08 16:39:37 +01:00
|
|
|
| xmltable opt_alias_clause
|
|
|
|
|
{
|
|
|
|
|
RangeTableFunc *n = (RangeTableFunc *) $1;
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-03-08 16:39:37 +01:00
|
|
|
n->alias = $2;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| LATERAL_P xmltable opt_alias_clause
|
|
|
|
|
{
|
|
|
|
|
RangeTableFunc *n = (RangeTableFunc *) $2;
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-03-08 16:39:37 +01:00
|
|
|
n->lateral = true;
|
|
|
|
|
n->alias = $3;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2012-08-08 01:02:54 +02:00
|
|
|
| select_with_parens opt_alias_clause
|
2001-01-20 18:37:52 +01:00
|
|
|
{
|
2012-08-08 01:02:54 +02:00
|
|
|
RangeSubselect *n = makeNode(RangeSubselect);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-08-08 01:02:54 +02:00
|
|
|
n->lateral = false;
|
|
|
|
|
n->subquery = $1;
|
|
|
|
|
n->alias = $2;
|
|
|
|
|
$$ = (Node *) n;
|
2001-01-20 18:37:52 +01:00
|
|
|
}
|
2012-08-08 01:02:54 +02:00
|
|
|
| LATERAL_P select_with_parens opt_alias_clause
|
2000-02-15 04:26:38 +01:00
|
|
|
{
|
2000-09-12 23:07:18 +02:00
|
|
|
RangeSubselect *n = makeNode(RangeSubselect);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2012-08-08 01:02:54 +02:00
|
|
|
n->lateral = true;
|
|
|
|
|
n->subquery = $2;
|
|
|
|
|
n->alias = $3;
|
2000-09-12 23:07:18 +02:00
|
|
|
$$ = (Node *) n;
|
2000-02-15 04:26:38 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| joined_table
|
2000-02-15 04:26:38 +01:00
|
|
|
{
|
2000-09-12 23:07:18 +02:00
|
|
|
$$ = (Node *) $1;
|
2000-02-15 04:26:38 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| '(' joined_table ')' alias_clause
|
2000-02-15 04:26:38 +01:00
|
|
|
{
|
2000-09-12 23:07:18 +02:00
|
|
|
$2->alias = $4;
|
|
|
|
|
$$ = (Node *) $2;
|
1999-02-23 08:42:41 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2002-05-12 22:10:05 +02:00
|
|
|
|
2000-09-12 23:07:18 +02:00
|
|
|
/*
|
|
|
|
|
* It may seem silly to separate joined_table from table_ref, but there is
|
2013-04-20 17:04:41 +02:00
|
|
|
* method in SQL's madness: if you don't do it this way you get reduce-
|
2000-09-12 23:07:18 +02:00
|
|
|
* reduce conflicts, because it's not clear to the parser generator whether
|
|
|
|
|
* to expect alias_clause after ')' or not. For the same reason we must
|
|
|
|
|
* treat 'JOIN' and 'join_type JOIN' separately, rather than allowing
|
|
|
|
|
* join_type to expand to empty; if we try it, the parser generator can't
|
|
|
|
|
* figure out when to reduce an empty join_type right after table_ref.
|
|
|
|
|
*
|
1999-02-23 08:42:41 +01:00
|
|
|
* Note that a CROSS JOIN is the same as an unqualified
|
2000-02-15 04:26:38 +01:00
|
|
|
* INNER JOIN, and an INNER JOIN/ON has the same shape
|
|
|
|
|
* but a qualification expression to limit membership.
|
1999-02-23 08:42:41 +01:00
|
|
|
* A NATURAL JOIN implicitly matches column names between
|
2000-02-15 04:26:38 +01:00
|
|
|
* tables and the shape is determined by which columns are
|
|
|
|
|
* in common. We'll collect columns during the later transformations.
|
1999-02-23 08:42:41 +01:00
|
|
|
*/
|
2000-09-12 23:07:18 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
joined_table:
|
|
|
|
|
'(' joined_table ')'
|
2000-09-12 23:07:18 +02:00
|
|
|
{
|
|
|
|
|
$$ = $2;
|
|
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| table_ref CROSS JOIN table_ref
|
1999-02-23 08:42:41 +01:00
|
|
|
{
|
2000-09-12 23:07:18 +02:00
|
|
|
/* CROSS JOIN is same as unqualified inner join */
|
2022-05-13 07:17:29 +02:00
|
|
|
JoinExpr *n = makeNode(JoinExpr);
|
|
|
|
|
|
2000-09-12 23:07:18 +02:00
|
|
|
n->jointype = JOIN_INNER;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->isNatural = false;
|
2000-09-12 23:07:18 +02:00
|
|
|
n->larg = $1;
|
|
|
|
|
n->rarg = $4;
|
2009-07-16 08:33:46 +02:00
|
|
|
n->usingClause = NIL;
|
2021-03-31 17:09:24 +02:00
|
|
|
n->join_using_alias = NULL;
|
2000-09-12 23:07:18 +02:00
|
|
|
n->quals = NULL;
|
2000-02-15 04:26:38 +01:00
|
|
|
$$ = n;
|
1999-02-23 08:42:41 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| table_ref join_type JOIN table_ref join_qual
|
1999-02-23 08:42:41 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
JoinExpr *n = makeNode(JoinExpr);
|
|
|
|
|
|
2000-09-12 23:07:18 +02:00
|
|
|
n->jointype = $2;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->isNatural = false;
|
2000-09-12 23:07:18 +02:00
|
|
|
n->larg = $1;
|
|
|
|
|
n->rarg = $4;
|
|
|
|
|
if ($5 != NULL && IsA($5, List))
|
2021-03-31 17:09:24 +02:00
|
|
|
{
|
|
|
|
|
/* USING clause */
|
|
|
|
|
n->usingClause = linitial_node(List, castNode(List, $5));
|
|
|
|
|
n->join_using_alias = lsecond_node(Alias, castNode(List, $5));
|
|
|
|
|
}
|
2000-09-12 23:07:18 +02:00
|
|
|
else
|
2021-03-31 17:09:24 +02:00
|
|
|
{
|
|
|
|
|
/* ON clause */
|
|
|
|
|
n->quals = $5;
|
|
|
|
|
}
|
2000-02-15 04:26:38 +01:00
|
|
|
$$ = n;
|
1999-02-23 08:42:41 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| table_ref JOIN table_ref join_qual
|
1999-02-23 08:42:41 +01:00
|
|
|
{
|
2000-09-12 23:07:18 +02:00
|
|
|
/* letting join_type reduce to empty doesn't work */
|
2022-05-13 07:17:29 +02:00
|
|
|
JoinExpr *n = makeNode(JoinExpr);
|
|
|
|
|
|
2000-09-12 23:07:18 +02:00
|
|
|
n->jointype = JOIN_INNER;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->isNatural = false;
|
2000-09-12 23:07:18 +02:00
|
|
|
n->larg = $1;
|
|
|
|
|
n->rarg = $3;
|
|
|
|
|
if ($4 != NULL && IsA($4, List))
|
2021-03-31 17:09:24 +02:00
|
|
|
{
|
|
|
|
|
/* USING clause */
|
|
|
|
|
n->usingClause = linitial_node(List, castNode(List, $4));
|
|
|
|
|
n->join_using_alias = lsecond_node(Alias, castNode(List, $4));
|
|
|
|
|
}
|
2000-09-12 23:07:18 +02:00
|
|
|
else
|
2021-03-31 17:09:24 +02:00
|
|
|
{
|
|
|
|
|
/* ON clause */
|
|
|
|
|
n->quals = $4;
|
|
|
|
|
}
|
2000-09-12 23:07:18 +02:00
|
|
|
$$ = n;
|
1999-02-23 08:42:41 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| table_ref NATURAL join_type JOIN table_ref
|
1999-02-23 08:42:41 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
JoinExpr *n = makeNode(JoinExpr);
|
|
|
|
|
|
2000-09-12 23:07:18 +02:00
|
|
|
n->jointype = $3;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->isNatural = true;
|
2000-09-12 23:07:18 +02:00
|
|
|
n->larg = $1;
|
|
|
|
|
n->rarg = $5;
|
2009-07-16 08:33:46 +02:00
|
|
|
n->usingClause = NIL; /* figure out which columns later... */
|
2021-03-31 17:09:24 +02:00
|
|
|
n->join_using_alias = NULL;
|
2000-09-12 23:07:18 +02:00
|
|
|
n->quals = NULL; /* fill later */
|
|
|
|
|
$$ = n;
|
1999-02-23 08:42:41 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| table_ref NATURAL JOIN table_ref
|
1999-02-23 08:42:41 +01:00
|
|
|
{
|
2000-09-12 23:07:18 +02:00
|
|
|
/* letting join_type reduce to empty doesn't work */
|
2022-05-13 07:17:29 +02:00
|
|
|
JoinExpr *n = makeNode(JoinExpr);
|
|
|
|
|
|
2000-09-12 23:07:18 +02:00
|
|
|
n->jointype = JOIN_INNER;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->isNatural = true;
|
2000-09-12 23:07:18 +02:00
|
|
|
n->larg = $1;
|
|
|
|
|
n->rarg = $4;
|
2009-07-16 08:33:46 +02:00
|
|
|
n->usingClause = NIL; /* figure out which columns later... */
|
2021-03-31 17:09:24 +02:00
|
|
|
n->join_using_alias = NULL;
|
2000-09-12 23:07:18 +02:00
|
|
|
n->quals = NULL; /* fill later */
|
2000-02-15 04:26:38 +01:00
|
|
|
$$ = n;
|
2000-09-12 23:07:18 +02:00
|
|
|
}
|
|
|
|
|
;
|
2000-02-15 04:26:38 +01:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
alias_clause:
|
|
|
|
|
AS ColId '(' name_list ')'
|
2000-09-12 23:07:18 +02:00
|
|
|
{
|
2002-03-21 17:02:16 +01:00
|
|
|
$$ = makeNode(Alias);
|
|
|
|
|
$$->aliasname = $2;
|
|
|
|
|
$$->colnames = $4;
|
2000-09-12 23:07:18 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| AS ColId
|
2000-09-12 23:07:18 +02:00
|
|
|
{
|
2002-03-21 17:02:16 +01:00
|
|
|
$$ = makeNode(Alias);
|
|
|
|
|
$$->aliasname = $2;
|
2000-09-12 23:07:18 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| ColId '(' name_list ')'
|
2000-09-12 23:07:18 +02:00
|
|
|
{
|
2002-03-21 17:02:16 +01:00
|
|
|
$$ = makeNode(Alias);
|
|
|
|
|
$$->aliasname = $1;
|
|
|
|
|
$$->colnames = $3;
|
2000-09-12 23:07:18 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| ColId
|
2000-09-12 23:07:18 +02:00
|
|
|
{
|
2002-03-21 17:02:16 +01:00
|
|
|
$$ = makeNode(Alias);
|
|
|
|
|
$$->aliasname = $1;
|
1999-02-23 08:42:41 +01:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
2012-08-08 01:02:54 +02:00
|
|
|
opt_alias_clause: alias_clause { $$ = $1; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
2021-03-31 17:09:24 +02:00
|
|
|
/*
|
|
|
|
|
* The alias clause after JOIN ... USING only accepts the AS ColId spelling,
|
|
|
|
|
* per SQL standard. (The grammar could parse the other variants, but they
|
|
|
|
|
* don't seem to be useful, and it might lead to parser problems in the
|
|
|
|
|
* future.)
|
|
|
|
|
*/
|
|
|
|
|
opt_alias_clause_for_join_using:
|
|
|
|
|
AS ColId
|
|
|
|
|
{
|
|
|
|
|
$$ = makeNode(Alias);
|
|
|
|
|
$$->aliasname = $2;
|
|
|
|
|
/* the column name list will be inserted later */
|
|
|
|
|
}
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
2012-08-08 01:02:54 +02:00
|
|
|
/*
|
|
|
|
|
* func_alias_clause can include both an Alias and a coldeflist, so we make it
|
|
|
|
|
* return a 2-element list that gets disassembled by calling production.
|
|
|
|
|
*/
|
|
|
|
|
func_alias_clause:
|
|
|
|
|
alias_clause
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make2($1, NIL);
|
|
|
|
|
}
|
|
|
|
|
| AS '(' TableFuncElementList ')'
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make2(NULL, $3);
|
|
|
|
|
}
|
|
|
|
|
| AS ColId '(' TableFuncElementList ')'
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
Alias *a = makeNode(Alias);
|
|
|
|
|
|
2012-08-08 01:02:54 +02:00
|
|
|
a->aliasname = $2;
|
|
|
|
|
$$ = list_make2(a, $4);
|
|
|
|
|
}
|
|
|
|
|
| ColId '(' TableFuncElementList ')'
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
Alias *a = makeNode(Alias);
|
|
|
|
|
|
2012-08-08 01:02:54 +02:00
|
|
|
a->aliasname = $1;
|
|
|
|
|
$$ = list_make2(a, $3);
|
|
|
|
|
}
|
|
|
|
|
| /*EMPTY*/
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make2(NULL, NIL);
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2020-11-12 07:48:36 +01:00
|
|
|
join_type: FULL opt_outer { $$ = JOIN_FULL; }
|
|
|
|
|
| LEFT opt_outer { $$ = JOIN_LEFT; }
|
|
|
|
|
| RIGHT opt_outer { $$ = JOIN_RIGHT; }
|
2002-06-17 22:27:43 +02:00
|
|
|
| INNER_P { $$ = JOIN_INNER; }
|
2000-02-15 04:26:38 +01:00
|
|
|
;
|
|
|
|
|
|
2000-09-12 23:07:18 +02:00
|
|
|
/* OUTER is just noise... */
|
2020-11-12 07:48:36 +01:00
|
|
|
opt_outer: OUTER_P
|
|
|
|
|
| /*EMPTY*/
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
1999-02-23 08:42:41 +01:00
|
|
|
/* JOIN qualification clauses
|
|
|
|
|
* Possibilities are:
|
2021-03-31 17:09:24 +02:00
|
|
|
* USING ( column list ) [ AS alias ]
|
|
|
|
|
* allows only unqualified column names,
|
2002-06-17 22:27:43 +02:00
|
|
|
* which must match between tables.
|
|
|
|
|
* ON expr allows more general qualifications.
|
2000-09-12 23:07:18 +02:00
|
|
|
*
|
2021-03-31 17:09:24 +02:00
|
|
|
* We return USING as a two-element List (the first item being a sub-List
|
|
|
|
|
* of the common column names, and the second either an Alias item or NULL).
|
|
|
|
|
* An ON-expr will not be a List, so it can be told apart that way.
|
1999-02-23 08:42:41 +01:00
|
|
|
*/
|
|
|
|
|
|
2021-03-31 17:09:24 +02:00
|
|
|
join_qual: USING '(' name_list ')' opt_alias_clause_for_join_using
|
|
|
|
|
{
|
|
|
|
|
$$ = (Node *) list_make2($3, $5);
|
|
|
|
|
}
|
|
|
|
|
| ON a_expr
|
|
|
|
|
{
|
|
|
|
|
$$ = $2;
|
|
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
relation_expr:
|
|
|
|
|
qualified_name
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2016-12-23 13:35:01 +01:00
|
|
|
/* inheritance query, implicitly */
|
2002-03-21 17:02:16 +01:00
|
|
|
$$ = $1;
|
2016-12-23 19:35:11 +01:00
|
|
|
$$->inh = true;
|
2002-03-21 17:02:16 +01:00
|
|
|
$$->alias = NULL;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
| extended_relation_expr
|
|
|
|
|
{
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
extended_relation_expr:
|
|
|
|
|
qualified_name '*'
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2016-12-23 19:35:11 +01:00
|
|
|
/* inheritance query, explicitly */
|
2002-03-21 17:02:16 +01:00
|
|
|
$$ = $1;
|
2016-12-23 19:35:11 +01:00
|
|
|
$$->inh = true;
|
2002-03-21 17:02:16 +01:00
|
|
|
$$->alias = NULL;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| ONLY qualified_name
|
2000-08-06 20:06:44 +02:00
|
|
|
{
|
2000-06-09 03:44:34 +02:00
|
|
|
/* no inheritance */
|
2002-03-21 17:02:16 +01:00
|
|
|
$$ = $2;
|
2016-12-23 19:35:11 +01:00
|
|
|
$$->inh = false;
|
2002-03-21 17:02:16 +01:00
|
|
|
$$->alias = NULL;
|
2002-06-17 22:27:43 +02:00
|
|
|
}
|
2002-08-04 08:51:23 +02:00
|
|
|
| ONLY '(' qualified_name ')'
|
|
|
|
|
{
|
|
|
|
|
/* no inheritance, SQL99-style syntax */
|
|
|
|
|
$$ = $3;
|
2016-12-23 19:35:11 +01:00
|
|
|
$$->inh = false;
|
2002-08-04 08:51:23 +02:00
|
|
|
$$->alias = NULL;
|
|
|
|
|
}
|
2000-08-06 20:06:44 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-05-12 22:10:05 +02:00
|
|
|
|
2009-01-12 09:54:27 +01:00
|
|
|
relation_expr_list:
|
|
|
|
|
relation_expr { $$ = list_make1($1); }
|
|
|
|
|
| relation_expr_list ',' relation_expr { $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
2006-01-22 21:03:16 +01:00
|
|
|
/*
|
|
|
|
|
* Given "UPDATE foo set set ...", we have to decide without looking any
|
|
|
|
|
* further ahead whether the first "set" is an alias or the UPDATE's SET
|
|
|
|
|
* keyword. Since "set" is allowed as a column name both interpretations
|
|
|
|
|
* are feasible. We resolve the shift/reduce conflict by giving the first
|
|
|
|
|
* relation_expr_opt_alias production a higher precedence than the SET token
|
|
|
|
|
* has, causing the parser to prefer to reduce, in effect assuming that the
|
|
|
|
|
* SET is not an alias.
|
|
|
|
|
*/
|
|
|
|
|
relation_expr_opt_alias: relation_expr %prec UMINUS
|
2006-01-22 06:20:35 +01:00
|
|
|
{
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
2006-01-22 21:03:16 +01:00
|
|
|
| relation_expr ColId
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
Alias *alias = makeNode(Alias);
|
|
|
|
|
|
2006-01-22 21:03:16 +01:00
|
|
|
alias->aliasname = $2;
|
|
|
|
|
$1->alias = alias;
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
|
|
|
|
| relation_expr AS ColId
|
2006-01-22 06:20:35 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
Alias *alias = makeNode(Alias);
|
|
|
|
|
|
2006-01-22 06:20:35 +01:00
|
|
|
alias->aliasname = $3;
|
|
|
|
|
$1->alias = alias;
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
Redesign tablesample method API, and do extensive code review.
The original implementation of TABLESAMPLE modeled the tablesample method
API on index access methods, which wasn't a good choice because, without
specialized DDL commands, there's no way to build an extension that can
implement a TSM. (Raw inserts into system catalogs are not an acceptable
thing to do, because we can't undo them during DROP EXTENSION, nor will
pg_upgrade behave sanely.) Instead adopt an API more like procedural
language handlers or foreign data wrappers, wherein the only SQL-level
support object needed is a single handler function identified by having
a special return type. This lets us get rid of the supporting catalog
altogether, so that no custom DDL support is needed for the feature.
Adjust the API so that it can support non-constant tablesample arguments
(the original coding assumed we could evaluate the argument expressions at
ExecInitSampleScan time, which is undesirable even if it weren't outright
unsafe), and discourage sampling methods from looking at invisible tuples.
Make sure that the BERNOULLI and SYSTEM methods are genuinely repeatable
within and across queries, as required by the SQL standard, and deal more
honestly with methods that can't support that requirement.
Make a full code-review pass over the tablesample additions, and fix
assorted bugs, omissions, infelicities, and cosmetic issues (such as
failure to put the added code stanzas in a consistent ordering).
Improve EXPLAIN's output of tablesample plans, too.
Back-patch to 9.5 so that we don't have to support the original API
in production.
2015-07-25 20:39:00 +02:00
|
|
|
/*
|
|
|
|
|
* TABLESAMPLE decoration in a FROM item
|
|
|
|
|
*/
|
2015-05-15 20:37:10 +02:00
|
|
|
tablesample_clause:
|
Redesign tablesample method API, and do extensive code review.
The original implementation of TABLESAMPLE modeled the tablesample method
API on index access methods, which wasn't a good choice because, without
specialized DDL commands, there's no way to build an extension that can
implement a TSM. (Raw inserts into system catalogs are not an acceptable
thing to do, because we can't undo them during DROP EXTENSION, nor will
pg_upgrade behave sanely.) Instead adopt an API more like procedural
language handlers or foreign data wrappers, wherein the only SQL-level
support object needed is a single handler function identified by having
a special return type. This lets us get rid of the supporting catalog
altogether, so that no custom DDL support is needed for the feature.
Adjust the API so that it can support non-constant tablesample arguments
(the original coding assumed we could evaluate the argument expressions at
ExecInitSampleScan time, which is undesirable even if it weren't outright
unsafe), and discourage sampling methods from looking at invisible tuples.
Make sure that the BERNOULLI and SYSTEM methods are genuinely repeatable
within and across queries, as required by the SQL standard, and deal more
honestly with methods that can't support that requirement.
Make a full code-review pass over the tablesample additions, and fix
assorted bugs, omissions, infelicities, and cosmetic issues (such as
failure to put the added code stanzas in a consistent ordering).
Improve EXPLAIN's output of tablesample plans, too.
Back-patch to 9.5 so that we don't have to support the original API
in production.
2015-07-25 20:39:00 +02:00
|
|
|
TABLESAMPLE func_name '(' expr_list ')' opt_repeatable_clause
|
2015-05-15 20:37:10 +02:00
|
|
|
{
|
|
|
|
|
RangeTableSample *n = makeNode(RangeTableSample);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Redesign tablesample method API, and do extensive code review.
The original implementation of TABLESAMPLE modeled the tablesample method
API on index access methods, which wasn't a good choice because, without
specialized DDL commands, there's no way to build an extension that can
implement a TSM. (Raw inserts into system catalogs are not an acceptable
thing to do, because we can't undo them during DROP EXTENSION, nor will
pg_upgrade behave sanely.) Instead adopt an API more like procedural
language handlers or foreign data wrappers, wherein the only SQL-level
support object needed is a single handler function identified by having
a special return type. This lets us get rid of the supporting catalog
altogether, so that no custom DDL support is needed for the feature.
Adjust the API so that it can support non-constant tablesample arguments
(the original coding assumed we could evaluate the argument expressions at
ExecInitSampleScan time, which is undesirable even if it weren't outright
unsafe), and discourage sampling methods from looking at invisible tuples.
Make sure that the BERNOULLI and SYSTEM methods are genuinely repeatable
within and across queries, as required by the SQL standard, and deal more
honestly with methods that can't support that requirement.
Make a full code-review pass over the tablesample additions, and fix
assorted bugs, omissions, infelicities, and cosmetic issues (such as
failure to put the added code stanzas in a consistent ordering).
Improve EXPLAIN's output of tablesample plans, too.
Back-patch to 9.5 so that we don't have to support the original API
in production.
2015-07-25 20:39:00 +02:00
|
|
|
/* n->relation will be filled in later */
|
2015-05-15 20:37:10 +02:00
|
|
|
n->method = $2;
|
|
|
|
|
n->args = $4;
|
|
|
|
|
n->repeatable = $6;
|
Redesign tablesample method API, and do extensive code review.
The original implementation of TABLESAMPLE modeled the tablesample method
API on index access methods, which wasn't a good choice because, without
specialized DDL commands, there's no way to build an extension that can
implement a TSM. (Raw inserts into system catalogs are not an acceptable
thing to do, because we can't undo them during DROP EXTENSION, nor will
pg_upgrade behave sanely.) Instead adopt an API more like procedural
language handlers or foreign data wrappers, wherein the only SQL-level
support object needed is a single handler function identified by having
a special return type. This lets us get rid of the supporting catalog
altogether, so that no custom DDL support is needed for the feature.
Adjust the API so that it can support non-constant tablesample arguments
(the original coding assumed we could evaluate the argument expressions at
ExecInitSampleScan time, which is undesirable even if it weren't outright
unsafe), and discourage sampling methods from looking at invisible tuples.
Make sure that the BERNOULLI and SYSTEM methods are genuinely repeatable
within and across queries, as required by the SQL standard, and deal more
honestly with methods that can't support that requirement.
Make a full code-review pass over the tablesample additions, and fix
assorted bugs, omissions, infelicities, and cosmetic issues (such as
failure to put the added code stanzas in a consistent ordering).
Improve EXPLAIN's output of tablesample plans, too.
Back-patch to 9.5 so that we don't have to support the original API
in production.
2015-07-25 20:39:00 +02:00
|
|
|
n->location = @2;
|
2015-05-15 20:37:10 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_repeatable_clause:
|
|
|
|
|
REPEATABLE '(' a_expr ')' { $$ = (Node *) $3; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
/*
|
|
|
|
|
* func_table represents a function invocation in a FROM list. It can be
|
2013-12-10 15:34:37 +01:00
|
|
|
* a plain function call, like "foo(...)", or a ROWS FROM expression with
|
|
|
|
|
* one or more function calls, "ROWS FROM (foo(...), bar(...))",
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
* optionally with WITH ORDINALITY attached.
|
2013-12-10 15:34:37 +01:00
|
|
|
* In the ROWS FROM syntax, a column definition list can be given for each
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
* function, for example:
|
2013-12-10 15:34:37 +01:00
|
|
|
* ROWS FROM (foo() AS (foo_res_a text, foo_res_b text),
|
|
|
|
|
* bar() AS (bar_res_a text, bar_res_b text))
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
* It's also possible to attach a column definition list to the RangeFunction
|
|
|
|
|
* as a whole, but that's handled by the table_ref production.
|
|
|
|
|
*/
|
|
|
|
|
func_table: func_expr_windowless opt_ordinality
|
|
|
|
|
{
|
|
|
|
|
RangeFunction *n = makeNode(RangeFunction);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
n->lateral = false;
|
|
|
|
|
n->ordinality = $2;
|
2013-12-10 15:34:37 +01:00
|
|
|
n->is_rowsfrom = false;
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
n->functions = list_make1(list_make2($1, NIL));
|
|
|
|
|
/* alias and coldeflist are set by table_ref production */
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2013-12-10 15:34:37 +01:00
|
|
|
| ROWS FROM '(' rowsfrom_list ')' opt_ordinality
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
{
|
|
|
|
|
RangeFunction *n = makeNode(RangeFunction);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
n->lateral = false;
|
2013-12-10 15:34:37 +01:00
|
|
|
n->ordinality = $6;
|
|
|
|
|
n->is_rowsfrom = true;
|
|
|
|
|
n->functions = $4;
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
/* alias and coldeflist are set by table_ref production */
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2013-12-10 15:34:37 +01:00
|
|
|
rowsfrom_item: func_expr_windowless opt_col_def_list
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
{ $$ = list_make2($1, $2); }
|
|
|
|
|
;
|
|
|
|
|
|
2013-12-10 15:34:37 +01:00
|
|
|
rowsfrom_list:
|
|
|
|
|
rowsfrom_item { $$ = list_make1($1); }
|
|
|
|
|
| rowsfrom_list ',' rowsfrom_item { $$ = lappend($1, $3); }
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_col_def_list: AS '(' TableFuncElementList ')' { $$ = $3; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
Improve parser's one-extra-token lookahead mechanism.
There are a couple of places in our grammar that fail to be strict LALR(1),
by requiring more than a single token of lookahead to decide what to do.
Up to now we've dealt with that by using a filter between the lexer and
parser that merges adjacent tokens into one in the places where two tokens
of lookahead are necessary. But that creates a number of user-visible
anomalies, for instance that you can't name a CTE "ordinality" because
"WITH ordinality AS ..." triggers folding of WITH and ORDINALITY into one
token. I realized that there's a better way.
In this patch, we still do the lookahead basically as before, but we never
merge the second token into the first; we replace just the first token by
a special lookahead symbol when one of the lookahead pairs is seen.
This requires a couple extra productions in the grammar, but it involves
fewer special tokens, so that the grammar tables come out a bit smaller
than before. The filter logic is no slower than before, perhaps a bit
faster.
I also fixed the filter logic so that when backing up after a lookahead,
the current token's terminator is correctly restored; this eliminates some
weird behavior in error message issuance, as is shown by the one change in
existing regression test outputs.
I believe that this patch entirely eliminates odd behaviors caused by
lookahead for WITH. It doesn't really improve the situation for NULLS
followed by FIRST/LAST unfortunately: those sequences still act like a
reserved word, even though there are cases where they should be seen as two
ordinary identifiers, eg "SELECT nulls first FROM ...". I experimented
with additional grammar hacks but couldn't find any simple solution for
that. Still, this is better than before, and it seems much more likely
that we *could* somehow solve the NULLS case on the basis of this filter
behavior than the previous one.
2015-02-24 23:53:42 +01:00
|
|
|
opt_ordinality: WITH_LA ORDINALITY { $$ = true; }
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
| /*EMPTY*/ { $$ = false; }
|
2002-05-12 22:10:05 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
where_clause:
|
|
|
|
|
WHERE a_expr { $$ = $2; }
|
2002-06-18 19:56:41 +02:00
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2007-06-11 03:16:30 +02:00
|
|
|
/* variant for UPDATE and DELETE */
|
|
|
|
|
where_or_current_clause:
|
|
|
|
|
WHERE a_expr { $$ = $2; }
|
2011-02-18 11:16:16 +01:00
|
|
|
| WHERE CURRENT_P OF cursor_name
|
2007-06-11 03:16:30 +02:00
|
|
|
{
|
|
|
|
|
CurrentOfExpr *n = makeNode(CurrentOfExpr);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-06-12 00:22:42 +02:00
|
|
|
/* cvarno is filled in by parse analysis */
|
2007-06-11 03:16:30 +02:00
|
|
|
n->cursor_name = $4;
|
2007-06-12 00:22:42 +02:00
|
|
|
n->cursor_param = 0;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2007-06-11 03:16:30 +02:00
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
1997-09-20 18:11:44 +02:00
|
|
|
|
2010-09-26 13:41:03 +02:00
|
|
|
OptTableFuncElementList:
|
|
|
|
|
TableFuncElementList { $$ = $1; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
2002-08-05 04:30:50 +02:00
|
|
|
TableFuncElementList:
|
2002-08-29 02:17:06 +02:00
|
|
|
TableFuncElement
|
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 21:48:11 +02:00
|
|
|
{
|
2004-05-31 01:40:41 +02:00
|
|
|
$$ = list_make1($1);
|
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 21:48:11 +02:00
|
|
|
}
|
2002-08-29 02:17:06 +02:00
|
|
|
| TableFuncElementList ',' TableFuncElement
|
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 21:48:11 +02:00
|
|
|
{
|
2002-08-29 02:17:06 +02:00
|
|
|
$$ = lappend($1, $3);
|
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 21:48:11 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
TableFuncElement: ColId Typename opt_collate_clause
|
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 21:48:11 +02:00
|
|
|
{
|
|
|
|
|
ColumnDef *n = makeNode(ColumnDef);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
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 21:48:11 +02:00
|
|
|
n->colname = $1;
|
2009-07-16 08:33:46 +02:00
|
|
|
n->typeName = $2;
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
n->inhcount = 0;
|
2002-09-22 21:42:52 +02:00
|
|
|
n->is_local = true;
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
n->is_not_null = false;
|
|
|
|
|
n->is_from_type = false;
|
|
|
|
|
n->storage = 0;
|
|
|
|
|
n->raw_default = NULL;
|
|
|
|
|
n->cooked_default = NULL;
|
|
|
|
|
n->collClause = (CollateClause *) $3;
|
|
|
|
|
n->collOid = InvalidOid;
|
|
|
|
|
n->constraints = NIL;
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
n->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
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 21:48:11 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2017-03-08 16:39:37 +01:00
|
|
|
/*
|
|
|
|
|
* XMLTABLE
|
|
|
|
|
*/
|
|
|
|
|
xmltable:
|
|
|
|
|
XMLTABLE '(' c_expr xmlexists_argument COLUMNS xmltable_column_list ')'
|
|
|
|
|
{
|
|
|
|
|
RangeTableFunc *n = makeNode(RangeTableFunc);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-03-08 16:39:37 +01:00
|
|
|
n->rowexpr = $3;
|
|
|
|
|
n->docexpr = $4;
|
|
|
|
|
n->columns = $6;
|
|
|
|
|
n->namespaces = NIL;
|
|
|
|
|
n->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-03-08 16:39:37 +01:00
|
|
|
}
|
|
|
|
|
| XMLTABLE '(' XMLNAMESPACES '(' xml_namespace_list ')' ','
|
|
|
|
|
c_expr xmlexists_argument COLUMNS xmltable_column_list ')'
|
|
|
|
|
{
|
|
|
|
|
RangeTableFunc *n = makeNode(RangeTableFunc);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2017-03-08 16:39:37 +01:00
|
|
|
n->rowexpr = $8;
|
|
|
|
|
n->docexpr = $9;
|
|
|
|
|
n->columns = $11;
|
|
|
|
|
n->namespaces = $5;
|
|
|
|
|
n->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2017-03-08 16:39:37 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
xmltable_column_list: xmltable_column_el { $$ = list_make1($1); }
|
|
|
|
|
| xmltable_column_list ',' xmltable_column_el { $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
xmltable_column_el:
|
|
|
|
|
ColId Typename
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
RangeTableFuncCol *fc = makeNode(RangeTableFuncCol);
|
2017-03-08 16:39:37 +01:00
|
|
|
|
|
|
|
|
fc->colname = $1;
|
|
|
|
|
fc->for_ordinality = false;
|
|
|
|
|
fc->typeName = $2;
|
|
|
|
|
fc->is_not_null = false;
|
|
|
|
|
fc->colexpr = NULL;
|
|
|
|
|
fc->coldefexpr = NULL;
|
|
|
|
|
fc->location = @1;
|
|
|
|
|
|
|
|
|
|
$$ = (Node *) fc;
|
|
|
|
|
}
|
|
|
|
|
| ColId Typename xmltable_column_option_list
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
RangeTableFuncCol *fc = makeNode(RangeTableFuncCol);
|
|
|
|
|
ListCell *option;
|
|
|
|
|
bool nullability_seen = false;
|
2017-03-08 16:39:37 +01:00
|
|
|
|
|
|
|
|
fc->colname = $1;
|
|
|
|
|
fc->typeName = $2;
|
|
|
|
|
fc->for_ordinality = false;
|
|
|
|
|
fc->is_not_null = false;
|
|
|
|
|
fc->colexpr = NULL;
|
|
|
|
|
fc->coldefexpr = NULL;
|
|
|
|
|
fc->location = @1;
|
|
|
|
|
|
|
|
|
|
foreach(option, $3)
|
|
|
|
|
{
|
|
|
|
|
DefElem *defel = (DefElem *) lfirst(option);
|
|
|
|
|
|
|
|
|
|
if (strcmp(defel->defname, "default") == 0)
|
|
|
|
|
{
|
|
|
|
|
if (fc->coldefexpr != NULL)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("only one DEFAULT value is allowed"),
|
|
|
|
|
parser_errposition(defel->location)));
|
|
|
|
|
fc->coldefexpr = defel->arg;
|
|
|
|
|
}
|
|
|
|
|
else if (strcmp(defel->defname, "path") == 0)
|
|
|
|
|
{
|
|
|
|
|
if (fc->colexpr != NULL)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("only one PATH value per column is allowed"),
|
|
|
|
|
parser_errposition(defel->location)));
|
|
|
|
|
fc->colexpr = defel->arg;
|
|
|
|
|
}
|
|
|
|
|
else if (strcmp(defel->defname, "is_not_null") == 0)
|
|
|
|
|
{
|
|
|
|
|
if (nullability_seen)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("conflicting or redundant NULL / NOT NULL declarations for column \"%s\"", fc->colname),
|
|
|
|
|
parser_errposition(defel->location)));
|
2022-01-14 10:46:49 +01:00
|
|
|
fc->is_not_null = boolVal(defel->arg);
|
2017-03-08 16:39:37 +01:00
|
|
|
nullability_seen = true;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("unrecognized column option \"%s\"",
|
|
|
|
|
defel->defname),
|
|
|
|
|
parser_errposition(defel->location)));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
$$ = (Node *) fc;
|
|
|
|
|
}
|
|
|
|
|
| ColId FOR ORDINALITY
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
RangeTableFuncCol *fc = makeNode(RangeTableFuncCol);
|
2017-03-08 16:39:37 +01:00
|
|
|
|
|
|
|
|
fc->colname = $1;
|
|
|
|
|
fc->for_ordinality = true;
|
|
|
|
|
/* other fields are ignored, initialized by makeNode */
|
|
|
|
|
fc->location = @1;
|
|
|
|
|
|
|
|
|
|
$$ = (Node *) fc;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
xmltable_column_option_list:
|
|
|
|
|
xmltable_column_option_el
|
|
|
|
|
{ $$ = list_make1($1); }
|
|
|
|
|
| xmltable_column_option_list xmltable_column_option_el
|
|
|
|
|
{ $$ = lappend($1, $2); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
xmltable_column_option_el:
|
|
|
|
|
IDENT b_expr
|
|
|
|
|
{ $$ = makeDefElem($1, $2, @1); }
|
|
|
|
|
| DEFAULT b_expr
|
|
|
|
|
{ $$ = makeDefElem("default", $2, @1); }
|
|
|
|
|
| NOT NULL_P
|
2022-01-14 10:46:49 +01:00
|
|
|
{ $$ = makeDefElem("is_not_null", (Node *) makeBoolean(true), @1); }
|
2017-03-08 16:39:37 +01:00
|
|
|
| NULL_P
|
2022-01-14 10:46:49 +01:00
|
|
|
{ $$ = makeDefElem("is_not_null", (Node *) makeBoolean(false), @1); }
|
2017-03-08 16:39:37 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
xml_namespace_list:
|
|
|
|
|
xml_namespace_el
|
|
|
|
|
{ $$ = list_make1($1); }
|
|
|
|
|
| xml_namespace_list ',' xml_namespace_el
|
|
|
|
|
{ $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
xml_namespace_el:
|
|
|
|
|
b_expr AS ColLabel
|
|
|
|
|
{
|
|
|
|
|
$$ = makeNode(ResTarget);
|
|
|
|
|
$$->name = $3;
|
|
|
|
|
$$->indirection = NIL;
|
|
|
|
|
$$->val = $1;
|
|
|
|
|
$$->location = @1;
|
|
|
|
|
}
|
|
|
|
|
| DEFAULT b_expr
|
|
|
|
|
{
|
|
|
|
|
$$ = makeNode(ResTarget);
|
|
|
|
|
$$->name = NULL;
|
|
|
|
|
$$->indirection = NIL;
|
|
|
|
|
$$->val = $2;
|
|
|
|
|
$$->location = @1;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
1997-10-25 07:56:41 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* Type syntax
|
2013-04-20 17:04:41 +02:00
|
|
|
* SQL introduces a large amount of type-specific syntax.
|
1997-10-25 07:56:41 +02:00
|
|
|
* Define individual clauses to handle these cases, and use
|
|
|
|
|
* the generic case to handle regular type-extensible Postgres syntax.
|
|
|
|
|
* - thomas 1997-10-10
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
Typename: SimpleTypename opt_array_bounds
|
1997-10-25 07:56:41 +02:00
|
|
|
{
|
|
|
|
|
$$ = $1;
|
|
|
|
|
$$->arrayBounds = $2;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2003-02-05 21:16:42 +01:00
|
|
|
| SETOF SimpleTypename opt_array_bounds
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
1997-10-25 07:56:41 +02:00
|
|
|
$$ = $2;
|
2003-02-05 21:16:42 +01:00
|
|
|
$$->arrayBounds = $3;
|
2017-08-16 06:22:32 +02:00
|
|
|
$$->setof = true;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2008-10-29 12:24:53 +01:00
|
|
|
/* SQL standard syntax, currently only one-dimensional */
|
2003-04-09 01:20:04 +02:00
|
|
|
| SimpleTypename ARRAY '[' Iconst ']'
|
|
|
|
|
{
|
|
|
|
|
$$ = $1;
|
2004-05-31 01:40:41 +02:00
|
|
|
$$->arrayBounds = list_make1(makeInteger($4));
|
2003-04-09 01:20:04 +02:00
|
|
|
}
|
|
|
|
|
| SETOF SimpleTypename ARRAY '[' Iconst ']'
|
|
|
|
|
{
|
|
|
|
|
$$ = $2;
|
2004-05-31 01:40:41 +02:00
|
|
|
$$->arrayBounds = list_make1(makeInteger($5));
|
2017-08-16 06:22:32 +02:00
|
|
|
$$->setof = true;
|
2003-04-09 01:20:04 +02:00
|
|
|
}
|
2008-10-29 12:24:53 +01:00
|
|
|
| SimpleTypename ARRAY
|
|
|
|
|
{
|
|
|
|
|
$$ = $1;
|
|
|
|
|
$$->arrayBounds = list_make1(makeInteger(-1));
|
|
|
|
|
}
|
|
|
|
|
| SETOF SimpleTypename ARRAY
|
|
|
|
|
{
|
|
|
|
|
$$ = $2;
|
|
|
|
|
$$->arrayBounds = list_make1(makeInteger(-1));
|
2017-08-16 06:22:32 +02:00
|
|
|
$$->setof = true;
|
2008-10-29 12:24:53 +01:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
opt_array_bounds:
|
|
|
|
|
opt_array_bounds '[' ']'
|
|
|
|
|
{ $$ = lappend($1, makeInteger(-1)); }
|
|
|
|
|
| opt_array_bounds '[' Iconst ']'
|
|
|
|
|
{ $$ = lappend($1, makeInteger($3)); }
|
|
|
|
|
| /*EMPTY*/
|
|
|
|
|
{ $$ = NIL; }
|
2000-09-12 23:07:18 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
SimpleTypename:
|
2002-08-04 08:51:23 +02:00
|
|
|
GenericType { $$ = $1; }
|
|
|
|
|
| Numeric { $$ = $1; }
|
|
|
|
|
| Bit { $$ = $1; }
|
|
|
|
|
| Character { $$ = $1; }
|
|
|
|
|
| ConstDatetime { $$ = $1; }
|
2002-06-17 22:27:43 +02:00
|
|
|
| ConstInterval opt_interval
|
2001-10-18 19:30:21 +02:00
|
|
|
{
|
|
|
|
|
$$ = $1;
|
2008-09-11 17:27:30 +02:00
|
|
|
$$->typmods = $2;
|
2001-10-18 19:30:21 +02:00
|
|
|
}
|
2014-10-18 16:31:00 +02:00
|
|
|
| ConstInterval '(' Iconst ')'
|
2001-10-18 19:30:21 +02:00
|
|
|
{
|
|
|
|
|
$$ = $1;
|
2014-10-18 16:31:00 +02:00
|
|
|
$$->typmods = list_make2(makeIntConst(INTERVAL_FULL_RANGE, -1),
|
|
|
|
|
makeIntConst($3, @3));
|
2002-03-29 20:06:29 +01:00
|
|
|
}
|
2000-07-14 17:43:57 +02:00
|
|
|
;
|
|
|
|
|
|
2002-08-04 08:51:23 +02:00
|
|
|
/* We have a separate ConstTypename to allow defaulting fixed-length
|
|
|
|
|
* types such as CHAR() and BIT() to an unspecified length.
|
|
|
|
|
* SQL9x requires that these default to a length of one, but this
|
|
|
|
|
* makes no sense for constructs like CHAR 'hi' and BIT '0101',
|
|
|
|
|
* where there is an obvious better choice to make.
|
|
|
|
|
* Note that ConstInterval is not included here since it must
|
2012-04-24 04:43:09 +02:00
|
|
|
* be pushed up higher in the rules to accommodate the postfix
|
2006-12-30 22:21:56 +01:00
|
|
|
* options (e.g. INTERVAL '1' YEAR). Likewise, we have to handle
|
2019-07-01 03:00:23 +02:00
|
|
|
* the generic-type-name case in AexprConst to avoid premature
|
2006-12-30 22:21:56 +01:00
|
|
|
* reduce/reduce conflicts against function names.
|
2002-08-04 08:51:23 +02:00
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
ConstTypename:
|
2006-12-30 22:21:56 +01:00
|
|
|
Numeric { $$ = $1; }
|
2002-08-04 08:51:23 +02:00
|
|
|
| ConstBit { $$ = $1; }
|
|
|
|
|
| ConstCharacter { $$ = $1; }
|
|
|
|
|
| ConstDatetime { $$ = $1; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1997-09-01 08:00:35 +02:00
|
|
|
|
2006-12-30 22:21:56 +01:00
|
|
|
/*
|
|
|
|
|
* GenericType covers all type names that don't have special syntax mandated
|
|
|
|
|
* by the standard, including qualified names. We also allow type modifiers.
|
|
|
|
|
* To avoid parsing conflicts against function invocations, the modifiers
|
|
|
|
|
* have to be shown as expr_list here, but parse analysis will only accept
|
2007-06-15 22:56:52 +02:00
|
|
|
* constants for them.
|
2006-12-30 22:21:56 +01:00
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
GenericType:
|
2006-12-30 22:21:56 +01:00
|
|
|
type_function_name opt_type_modifiers
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2002-05-03 02:32:19 +02:00
|
|
|
$$ = makeTypeName($1);
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->typmods = $2;
|
|
|
|
|
$$->location = @1;
|
|
|
|
|
}
|
|
|
|
|
| type_function_name attrs opt_type_modifiers
|
|
|
|
|
{
|
|
|
|
|
$$ = makeTypeNameFromNameList(lcons(makeString($1), $2));
|
|
|
|
|
$$->typmods = $3;
|
2006-03-14 23:48:25 +01:00
|
|
|
$$->location = @1;
|
1997-10-25 07:56:41 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2006-12-30 22:21:56 +01:00
|
|
|
opt_type_modifiers: '(' expr_list ')' { $$ = $2; }
|
|
|
|
|
| /* EMPTY */ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/*
|
2013-04-20 17:04:41 +02:00
|
|
|
* SQL numeric data types
|
1997-10-25 07:56:41 +02:00
|
|
|
*/
|
2003-05-15 18:35:30 +02:00
|
|
|
Numeric: INT_P
|
2002-05-03 02:32:19 +02:00
|
|
|
{
|
|
|
|
|
$$ = SystemTypeName("int4");
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->location = @1;
|
2002-05-03 02:32:19 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| INTEGER
|
2002-05-03 02:32:19 +02:00
|
|
|
{
|
|
|
|
|
$$ = SystemTypeName("int4");
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->location = @1;
|
2002-05-03 02:32:19 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| SMALLINT
|
2002-05-03 02:32:19 +02:00
|
|
|
{
|
|
|
|
|
$$ = SystemTypeName("int2");
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->location = @1;
|
2002-05-03 02:32:19 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| BIGINT
|
2002-05-03 02:32:19 +02:00
|
|
|
{
|
|
|
|
|
$$ = SystemTypeName("int8");
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->location = @1;
|
2002-05-03 02:32:19 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| REAL
|
2002-05-03 02:32:19 +02:00
|
|
|
{
|
|
|
|
|
$$ = SystemTypeName("float4");
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->location = @1;
|
2002-05-03 02:32:19 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| FLOAT_P opt_float
|
1997-10-25 07:56:41 +02:00
|
|
|
{
|
2002-05-03 02:32:19 +02:00
|
|
|
$$ = $2;
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->location = @1;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2003-05-15 18:35:30 +02:00
|
|
|
| DOUBLE_P PRECISION
|
1998-02-11 05:09:54 +01:00
|
|
|
{
|
2002-05-03 02:32:19 +02:00
|
|
|
$$ = SystemTypeName("float8");
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->location = @1;
|
1998-02-11 05:09:54 +01:00
|
|
|
}
|
2006-12-30 22:21:56 +01:00
|
|
|
| DECIMAL_P opt_type_modifiers
|
2000-02-15 04:26:38 +01:00
|
|
|
{
|
2002-05-03 02:32:19 +02:00
|
|
|
$$ = SystemTypeName("numeric");
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->typmods = $2;
|
|
|
|
|
$$->location = @1;
|
2000-02-15 04:26:38 +01:00
|
|
|
}
|
2006-12-30 22:21:56 +01:00
|
|
|
| DEC opt_type_modifiers
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2002-05-03 02:32:19 +02:00
|
|
|
$$ = SystemTypeName("numeric");
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->typmods = $2;
|
|
|
|
|
$$->location = @1;
|
1997-10-25 07:56:41 +02:00
|
|
|
}
|
2006-12-30 22:21:56 +01:00
|
|
|
| NUMERIC opt_type_modifiers
|
1997-10-25 07:56:41 +02:00
|
|
|
{
|
2002-05-03 02:32:19 +02:00
|
|
|
$$ = SystemTypeName("numeric");
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->typmods = $2;
|
|
|
|
|
$$->location = @1;
|
1997-10-25 07:56:41 +02:00
|
|
|
}
|
2003-05-15 18:35:30 +02:00
|
|
|
| BOOLEAN_P
|
2002-05-03 02:32:19 +02:00
|
|
|
{
|
|
|
|
|
$$ = SystemTypeName("bool");
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->location = @1;
|
2002-05-03 02:32:19 +02:00
|
|
|
}
|
1997-10-25 07:56:41 +02:00
|
|
|
;
|
1997-09-08 05:20:18 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
opt_float: '(' Iconst ')'
|
1997-10-25 07:56:41 +02:00
|
|
|
{
|
2006-12-30 22:21:56 +01:00
|
|
|
/*
|
|
|
|
|
* Check FLOAT() precision limits assuming IEEE floating
|
|
|
|
|
* types - thomas 1997-09-18
|
|
|
|
|
*/
|
1997-10-25 07:56:41 +02:00
|
|
|
if ($2 < 1)
|
2003-07-19 22:20:53 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
2008-09-01 22:42:46 +02:00
|
|
|
errmsg("precision for type float must be at least 1 bit"),
|
2009-07-13 04:02:20 +02:00
|
|
|
parser_errposition(@2)));
|
2003-06-18 01:12:36 +02:00
|
|
|
else if ($2 <= 24)
|
2002-05-03 02:32:19 +02:00
|
|
|
$$ = SystemTypeName("float4");
|
2003-06-18 01:12:36 +02:00
|
|
|
else if ($2 <= 53)
|
2002-05-03 02:32:19 +02:00
|
|
|
$$ = SystemTypeName("float8");
|
1997-10-25 07:56:41 +02:00
|
|
|
else
|
2003-07-19 22:20:53 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
2008-09-01 22:42:46 +02:00
|
|
|
errmsg("precision for type float must be less than 54 bits"),
|
2009-07-13 04:02:20 +02:00
|
|
|
parser_errposition(@2)));
|
1997-10-25 07:56:41 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| /*EMPTY*/
|
1997-10-25 07:56:41 +02:00
|
|
|
{
|
2002-05-03 02:32:19 +02:00
|
|
|
$$ = SystemTypeName("float8");
|
1997-10-25 07:56:41 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2000-03-21 07:00:41 +01:00
|
|
|
/*
|
2013-04-20 17:04:41 +02:00
|
|
|
* SQL bit-field data types
|
2000-03-21 07:00:41 +01:00
|
|
|
* The following implements BIT() and BIT VARYING().
|
|
|
|
|
*/
|
2002-08-04 08:51:23 +02:00
|
|
|
Bit: BitWithLength
|
|
|
|
|
{
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
|
|
|
|
| BitWithoutLength
|
|
|
|
|
{
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2003-02-05 21:16:42 +01:00
|
|
|
/* ConstBit is like Bit except "BIT" defaults to unspecified length */
|
|
|
|
|
/* See notes for ConstCharacter, which addresses same issue for "CHAR" */
|
2002-08-04 08:51:23 +02:00
|
|
|
ConstBit: BitWithLength
|
|
|
|
|
{
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
|
|
|
|
| BitWithoutLength
|
|
|
|
|
{
|
|
|
|
|
$$ = $1;
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->typmods = NIL;
|
2002-08-04 08:51:23 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
BitWithLength:
|
2006-12-30 22:21:56 +01:00
|
|
|
BIT opt_varying '(' expr_list ')'
|
2000-03-21 07:00:41 +01:00
|
|
|
{
|
2002-05-03 02:32:19 +02:00
|
|
|
char *typname;
|
|
|
|
|
|
|
|
|
|
typname = $2 ? "varbit" : "bit";
|
|
|
|
|
$$ = SystemTypeName(typname);
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->typmods = $4;
|
|
|
|
|
$$->location = @1;
|
2000-03-21 07:00:41 +01:00
|
|
|
}
|
2002-08-04 08:51:23 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
BitWithoutLength:
|
|
|
|
|
BIT opt_varying
|
2000-03-21 07:00:41 +01:00
|
|
|
{
|
2001-11-12 22:04:46 +01:00
|
|
|
/* bit defaults to bit(1), varbit to no limit */
|
2002-05-03 02:32:19 +02:00
|
|
|
if ($2)
|
|
|
|
|
{
|
|
|
|
|
$$ = SystemTypeName("varbit");
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
$$ = SystemTypeName("bit");
|
2008-08-29 01:09:48 +02:00
|
|
|
$$->typmods = list_make1(makeIntConst(1, -1));
|
2002-05-03 02:32:19 +02:00
|
|
|
}
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->location = @1;
|
2000-03-21 07:00:41 +01:00
|
|
|
}
|
2002-03-21 17:02:16 +01:00
|
|
|
;
|
2000-03-21 07:00:41 +01:00
|
|
|
|
|
|
|
|
|
2000-01-20 03:24:50 +01:00
|
|
|
/*
|
2013-04-20 17:04:41 +02:00
|
|
|
* SQL character data types
|
1997-10-25 07:56:41 +02:00
|
|
|
* The following implements CHAR() and VARCHAR().
|
|
|
|
|
*/
|
2002-08-04 08:51:23 +02:00
|
|
|
Character: CharacterWithLength
|
|
|
|
|
{
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
|
|
|
|
| CharacterWithoutLength
|
|
|
|
|
{
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
ConstCharacter: CharacterWithLength
|
|
|
|
|
{
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
|
|
|
|
| CharacterWithoutLength
|
|
|
|
|
{
|
|
|
|
|
/* Length was not specified so allow to be unrestricted.
|
|
|
|
|
* This handles problems with fixed-length (bpchar) strings
|
|
|
|
|
* which in column definitions must default to a length
|
|
|
|
|
* of one, but should not be constrained if the length
|
|
|
|
|
* was not specified.
|
|
|
|
|
*/
|
|
|
|
|
$$ = $1;
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->typmods = NIL;
|
2002-08-04 08:51:23 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2017-03-07 16:42:11 +01:00
|
|
|
CharacterWithLength: character '(' Iconst ')'
|
1997-10-25 07:56:41 +02:00
|
|
|
{
|
2002-05-03 02:32:19 +02:00
|
|
|
$$ = SystemTypeName($1);
|
2008-08-29 01:09:48 +02:00
|
|
|
$$->typmods = list_make1(makeIntConst($3, @3));
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->location = @1;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2002-08-04 08:51:23 +02:00
|
|
|
;
|
|
|
|
|
|
2017-03-07 16:42:11 +01:00
|
|
|
CharacterWithoutLength: character
|
1997-09-24 19:53:53 +02:00
|
|
|
{
|
2002-05-03 02:32:19 +02:00
|
|
|
$$ = SystemTypeName($1);
|
2001-11-12 22:04:46 +01:00
|
|
|
/* char defaults to char(1), varchar to no limit */
|
|
|
|
|
if (strcmp($1, "bpchar") == 0)
|
2008-08-29 01:09:48 +02:00
|
|
|
$$->typmods = list_make1(makeIntConst(1, -1));
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->location = @1;
|
1997-10-25 07:56:41 +02:00
|
|
|
}
|
2001-10-03 07:29:27 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
character: CHARACTER opt_varying
|
|
|
|
|
{ $$ = $2 ? "varchar": "bpchar"; }
|
|
|
|
|
| CHAR_P opt_varying
|
|
|
|
|
{ $$ = $2 ? "varchar": "bpchar"; }
|
|
|
|
|
| VARCHAR
|
|
|
|
|
{ $$ = "varchar"; }
|
|
|
|
|
| NATIONAL CHARACTER opt_varying
|
|
|
|
|
{ $$ = $3 ? "varchar": "bpchar"; }
|
|
|
|
|
| NATIONAL CHAR_P opt_varying
|
|
|
|
|
{ $$ = $3 ? "varchar": "bpchar"; }
|
|
|
|
|
| NCHAR opt_varying
|
|
|
|
|
{ $$ = $2 ? "varchar": "bpchar"; }
|
1997-10-25 07:56:41 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
opt_varying:
|
2017-08-16 06:22:32 +02:00
|
|
|
VARYING { $$ = true; }
|
|
|
|
|
| /*EMPTY*/ { $$ = false; }
|
1997-10-25 07:56:41 +02:00
|
|
|
;
|
|
|
|
|
|
2006-12-30 22:21:56 +01:00
|
|
|
/*
|
2013-04-20 17:04:41 +02:00
|
|
|
* SQL date/time types
|
2006-12-30 22:21:56 +01:00
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
ConstDatetime:
|
|
|
|
|
TIMESTAMP '(' Iconst ')' opt_timezone
|
2001-10-03 07:29:27 +02:00
|
|
|
{
|
|
|
|
|
if ($5)
|
2002-05-03 02:32:19 +02:00
|
|
|
$$ = SystemTypeName("timestamptz");
|
2001-10-03 07:29:27 +02:00
|
|
|
else
|
2002-05-03 02:32:19 +02:00
|
|
|
$$ = SystemTypeName("timestamp");
|
2008-08-29 01:09:48 +02:00
|
|
|
$$->typmods = list_make1(makeIntConst($3, @3));
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->location = @1;
|
2001-10-03 07:29:27 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| TIMESTAMP opt_timezone
|
1997-10-25 07:56:41 +02:00
|
|
|
{
|
2001-09-28 10:09:14 +02:00
|
|
|
if ($2)
|
2002-05-03 02:32:19 +02:00
|
|
|
$$ = SystemTypeName("timestamptz");
|
2001-09-28 10:09:14 +02:00
|
|
|
else
|
2002-05-03 02:32:19 +02:00
|
|
|
$$ = SystemTypeName("timestamp");
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->location = @1;
|
2001-10-03 07:29:27 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| TIME '(' Iconst ')' opt_timezone
|
2001-10-03 07:29:27 +02:00
|
|
|
{
|
|
|
|
|
if ($5)
|
2002-05-03 02:32:19 +02:00
|
|
|
$$ = SystemTypeName("timetz");
|
2001-10-03 07:29:27 +02:00
|
|
|
else
|
2002-05-03 02:32:19 +02:00
|
|
|
$$ = SystemTypeName("time");
|
2008-08-29 01:09:48 +02:00
|
|
|
$$->typmods = list_make1(makeIntConst($3, @3));
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->location = @1;
|
1997-10-25 07:56:41 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| TIME opt_timezone
|
1997-10-25 07:56:41 +02:00
|
|
|
{
|
2000-03-15 00:06:59 +01:00
|
|
|
if ($2)
|
2002-05-03 02:32:19 +02:00
|
|
|
$$ = SystemTypeName("timetz");
|
2000-03-15 00:06:59 +01:00
|
|
|
else
|
2002-05-03 02:32:19 +02:00
|
|
|
$$ = SystemTypeName("time");
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->location = @1;
|
1997-10-25 07:56:41 +02:00
|
|
|
}
|
2000-07-14 17:43:57 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
ConstInterval:
|
2006-12-30 22:21:56 +01:00
|
|
|
INTERVAL
|
|
|
|
|
{
|
|
|
|
|
$$ = SystemTypeName("interval");
|
|
|
|
|
$$->location = @1;
|
|
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
opt_timezone:
|
2017-08-16 06:22:32 +02:00
|
|
|
WITH_LA TIME ZONE { $$ = true; }
|
2023-04-04 14:04:30 +02:00
|
|
|
| WITHOUT_LA TIME ZONE { $$ = false; }
|
2017-08-16 06:22:32 +02:00
|
|
|
| /*EMPTY*/ { $$ = false; }
|
1997-10-25 07:56:41 +02:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
opt_interval:
|
2008-09-11 17:27:30 +02:00
|
|
|
YEAR_P
|
|
|
|
|
{ $$ = list_make1(makeIntConst(INTERVAL_MASK(YEAR), @1)); }
|
|
|
|
|
| MONTH_P
|
|
|
|
|
{ $$ = list_make1(makeIntConst(INTERVAL_MASK(MONTH), @1)); }
|
|
|
|
|
| DAY_P
|
|
|
|
|
{ $$ = list_make1(makeIntConst(INTERVAL_MASK(DAY), @1)); }
|
|
|
|
|
| HOUR_P
|
|
|
|
|
{ $$ = list_make1(makeIntConst(INTERVAL_MASK(HOUR), @1)); }
|
|
|
|
|
| MINUTE_P
|
|
|
|
|
{ $$ = list_make1(makeIntConst(INTERVAL_MASK(MINUTE), @1)); }
|
|
|
|
|
| interval_second
|
|
|
|
|
{ $$ = $1; }
|
2002-06-18 19:56:41 +02:00
|
|
|
| YEAR_P TO MONTH_P
|
2008-09-11 17:27:30 +02:00
|
|
|
{
|
|
|
|
|
$$ = list_make1(makeIntConst(INTERVAL_MASK(YEAR) |
|
|
|
|
|
INTERVAL_MASK(MONTH), @1));
|
|
|
|
|
}
|
2002-06-18 19:56:41 +02:00
|
|
|
| DAY_P TO HOUR_P
|
2008-09-11 17:27:30 +02:00
|
|
|
{
|
|
|
|
|
$$ = list_make1(makeIntConst(INTERVAL_MASK(DAY) |
|
|
|
|
|
INTERVAL_MASK(HOUR), @1));
|
|
|
|
|
}
|
2002-06-18 19:56:41 +02:00
|
|
|
| DAY_P TO MINUTE_P
|
2008-09-11 17:27:30 +02:00
|
|
|
{
|
|
|
|
|
$$ = list_make1(makeIntConst(INTERVAL_MASK(DAY) |
|
|
|
|
|
INTERVAL_MASK(HOUR) |
|
|
|
|
|
INTERVAL_MASK(MINUTE), @1));
|
|
|
|
|
}
|
|
|
|
|
| DAY_P TO interval_second
|
|
|
|
|
{
|
|
|
|
|
$$ = $3;
|
|
|
|
|
linitial($$) = makeIntConst(INTERVAL_MASK(DAY) |
|
|
|
|
|
INTERVAL_MASK(HOUR) |
|
|
|
|
|
INTERVAL_MASK(MINUTE) |
|
|
|
|
|
INTERVAL_MASK(SECOND), @1);
|
|
|
|
|
}
|
2002-06-18 19:56:41 +02:00
|
|
|
| HOUR_P TO MINUTE_P
|
2008-09-11 17:27:30 +02:00
|
|
|
{
|
|
|
|
|
$$ = list_make1(makeIntConst(INTERVAL_MASK(HOUR) |
|
|
|
|
|
INTERVAL_MASK(MINUTE), @1));
|
|
|
|
|
}
|
|
|
|
|
| HOUR_P TO interval_second
|
|
|
|
|
{
|
|
|
|
|
$$ = $3;
|
|
|
|
|
linitial($$) = makeIntConst(INTERVAL_MASK(HOUR) |
|
|
|
|
|
INTERVAL_MASK(MINUTE) |
|
|
|
|
|
INTERVAL_MASK(SECOND), @1);
|
|
|
|
|
}
|
|
|
|
|
| MINUTE_P TO interval_second
|
|
|
|
|
{
|
|
|
|
|
$$ = $3;
|
|
|
|
|
linitial($$) = makeIntConst(INTERVAL_MASK(MINUTE) |
|
|
|
|
|
INTERVAL_MASK(SECOND), @1);
|
|
|
|
|
}
|
|
|
|
|
| /*EMPTY*/
|
|
|
|
|
{ $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
interval_second:
|
|
|
|
|
SECOND_P
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make1(makeIntConst(INTERVAL_MASK(SECOND), @1));
|
|
|
|
|
}
|
|
|
|
|
| SECOND_P '(' Iconst ')'
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make2(makeIntConst(INTERVAL_MASK(SECOND), @1),
|
|
|
|
|
makeIntConst($3, @3));
|
|
|
|
|
}
|
1997-10-25 07:56:41 +02:00
|
|
|
;
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
1999-11-20 22:39:36 +01:00
|
|
|
* expression grammar
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
1999-11-20 22:39:36 +01:00
|
|
|
/*
|
|
|
|
|
* General expressions
|
1998-02-04 07:11:48 +01:00
|
|
|
* This is the heart of the expression syntax.
|
1999-11-20 22:39:36 +01:00
|
|
|
*
|
|
|
|
|
* We have two expression types: a_expr is the unrestricted kind, and
|
|
|
|
|
* b_expr is a subset that must be used in some places to avoid shift/reduce
|
|
|
|
|
* conflicts. For example, we can't do BETWEEN as "BETWEEN a_expr AND a_expr"
|
|
|
|
|
* because that use of AND conflicts with AND as a boolean operator. So,
|
|
|
|
|
* b_expr is used in BETWEEN and we remove boolean keywords from b_expr.
|
|
|
|
|
*
|
|
|
|
|
* Note that '(' a_expr ')' is a b_expr, so an unrestricted expression can
|
|
|
|
|
* always be used by surrounding it with parens.
|
|
|
|
|
*
|
2000-02-15 04:26:38 +01:00
|
|
|
* c_expr is all the productions that are common to a_expr and b_expr;
|
1999-11-20 22:39:36 +01:00
|
|
|
* it's factored out just to eliminate redundant coding.
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
*
|
|
|
|
|
* Be careful of productions involving more than one terminal token.
|
|
|
|
|
* By default, bison will assign such productions the precedence of their
|
|
|
|
|
* last terminal, but in nearly all cases you want it to be the precedence
|
|
|
|
|
* of the first terminal instead; otherwise you will not get the behavior
|
|
|
|
|
* you expect! So we use %prec annotations freely to set precedences.
|
1998-02-04 07:11:48 +01:00
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
a_expr: c_expr { $$ = $1; }
|
2002-06-18 19:56:41 +02:00
|
|
|
| a_expr TYPECAST Typename
|
2008-08-29 01:09:48 +02:00
|
|
|
{ $$ = makeTypeCast($1, $3, @2); }
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
| a_expr COLLATE any_name
|
|
|
|
|
{
|
|
|
|
|
CollateClause *n = makeNode(CollateClause);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2011-03-11 22:27:51 +01:00
|
|
|
n->arg = $1;
|
|
|
|
|
n->collname = $3;
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
n->location = @2;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2011-05-06 02:38:52 +02:00
|
|
|
| a_expr AT TIME ZONE a_expr %prec AT
|
2000-11-06 16:47:17 +01:00
|
|
|
{
|
2013-07-01 20:41:33 +02:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("timezone"),
|
|
|
|
|
list_make2($5, $1),
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
COERCE_SQL_SYNTAX,
|
2013-07-01 20:41:33 +02:00
|
|
|
@2);
|
2000-11-06 16:47:17 +01:00
|
|
|
}
|
1999-11-20 22:39:36 +01:00
|
|
|
/*
|
|
|
|
|
* These operators must be called out explicitly in order to make use
|
2009-07-12 19:12:34 +02:00
|
|
|
* of bison's automatic operator-precedence handling. All other
|
1999-11-20 22:39:36 +01:00
|
|
|
* operator names are handled by the generic productions using "Op",
|
|
|
|
|
* below; and all those operators will have the same precedence.
|
|
|
|
|
*
|
|
|
|
|
* If you add more explicitly-known operators, be sure to add them
|
2015-02-22 19:57:56 +01:00
|
|
|
* also to b_expr and to the MathOp list below.
|
1999-11-20 22:39:36 +01:00
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
| '+' a_expr %prec UMINUS
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "+", NULL, $2, @1); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| '-' a_expr %prec UMINUS
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = doNegate($2, @1); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| a_expr '+' a_expr
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "+", $1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| a_expr '-' a_expr
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "-", $1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| a_expr '*' a_expr
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "*", $1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| a_expr '/' a_expr
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "/", $1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| a_expr '%' a_expr
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "%", $1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| a_expr '^' a_expr
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "^", $1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| a_expr '<' a_expr
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "<", $1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| a_expr '>' a_expr
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, ">", $1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| a_expr '=' a_expr
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "=", $1, $3, @2); }
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
| a_expr LESS_EQUALS a_expr
|
|
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "<=", $1, $3, @2); }
|
|
|
|
|
| a_expr GREATER_EQUALS a_expr
|
|
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, ">=", $1, $3, @2); }
|
|
|
|
|
| a_expr NOT_EQUALS a_expr
|
|
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "<>", $1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
|
|
|
|
|
| a_expr qual_Op a_expr %prec Op
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeA_Expr(AEXPR_OP, $2, $1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| qual_Op a_expr %prec Op
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeA_Expr(AEXPR_OP, $1, NULL, $2, @1); }
|
2002-06-17 22:27:43 +02:00
|
|
|
|
|
|
|
|
| a_expr AND a_expr
|
2014-06-16 21:55:05 +02:00
|
|
|
{ $$ = makeAndExpr($1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| a_expr OR a_expr
|
2014-06-16 21:55:05 +02:00
|
|
|
{ $$ = makeOrExpr($1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| NOT a_expr
|
2014-06-16 21:55:05 +02:00
|
|
|
{ $$ = makeNotExpr($2, @1); }
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
| NOT_LA a_expr %prec NOT
|
|
|
|
|
{ $$ = makeNotExpr($2, @1); }
|
2002-06-17 22:27:43 +02:00
|
|
|
|
|
|
|
|
| a_expr LIKE a_expr
|
2015-02-23 18:46:46 +01:00
|
|
|
{
|
|
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_LIKE, "~~",
|
|
|
|
|
$1, $3, @2);
|
|
|
|
|
}
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
| a_expr LIKE a_expr ESCAPE a_expr %prec LIKE
|
2000-08-06 20:06:44 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
FuncCall *n = makeFuncCall(SystemFuncName("like_escape"),
|
|
|
|
|
list_make2($3, $5),
|
|
|
|
|
COERCE_EXPLICIT_CALL,
|
|
|
|
|
@2);
|
2015-02-23 18:46:46 +01:00
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_LIKE, "~~",
|
|
|
|
|
$1, (Node *) n, @2);
|
2000-08-06 20:06:44 +02:00
|
|
|
}
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
| a_expr NOT_LA LIKE a_expr %prec NOT_LA
|
2015-02-23 18:46:46 +01:00
|
|
|
{
|
|
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_LIKE, "!~~",
|
|
|
|
|
$1, $4, @2);
|
|
|
|
|
}
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
| a_expr NOT_LA LIKE a_expr ESCAPE a_expr %prec NOT_LA
|
2000-08-06 20:06:44 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
FuncCall *n = makeFuncCall(SystemFuncName("like_escape"),
|
|
|
|
|
list_make2($4, $6),
|
|
|
|
|
COERCE_EXPLICIT_CALL,
|
|
|
|
|
@2);
|
2015-02-23 18:46:46 +01:00
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_LIKE, "!~~",
|
|
|
|
|
$1, (Node *) n, @2);
|
2000-08-06 20:06:44 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| a_expr ILIKE a_expr
|
2015-02-23 18:46:46 +01:00
|
|
|
{
|
|
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_ILIKE, "~~*",
|
|
|
|
|
$1, $3, @2);
|
|
|
|
|
}
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
| a_expr ILIKE a_expr ESCAPE a_expr %prec ILIKE
|
2000-08-06 20:06:44 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
FuncCall *n = makeFuncCall(SystemFuncName("like_escape"),
|
|
|
|
|
list_make2($3, $5),
|
|
|
|
|
COERCE_EXPLICIT_CALL,
|
|
|
|
|
@2);
|
2015-02-23 18:46:46 +01:00
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_ILIKE, "~~*",
|
|
|
|
|
$1, (Node *) n, @2);
|
2000-08-06 20:06:44 +02:00
|
|
|
}
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
| a_expr NOT_LA ILIKE a_expr %prec NOT_LA
|
2015-02-23 18:46:46 +01:00
|
|
|
{
|
|
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_ILIKE, "!~~*",
|
|
|
|
|
$1, $4, @2);
|
|
|
|
|
}
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
| a_expr NOT_LA ILIKE a_expr ESCAPE a_expr %prec NOT_LA
|
2000-08-06 20:06:44 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
FuncCall *n = makeFuncCall(SystemFuncName("like_escape"),
|
|
|
|
|
list_make2($4, $6),
|
|
|
|
|
COERCE_EXPLICIT_CALL,
|
|
|
|
|
@2);
|
2015-02-23 18:46:46 +01:00
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_ILIKE, "!~~*",
|
|
|
|
|
$1, (Node *) n, @2);
|
2000-08-06 20:06:44 +02:00
|
|
|
}
|
2002-06-11 17:44:38 +02:00
|
|
|
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
| a_expr SIMILAR TO a_expr %prec SIMILAR
|
2002-09-22 19:27:25 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
FuncCall *n = makeFuncCall(SystemFuncName("similar_to_escape"),
|
|
|
|
|
list_make1($4),
|
|
|
|
|
COERCE_EXPLICIT_CALL,
|
|
|
|
|
@2);
|
2015-02-23 18:46:46 +01:00
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_SIMILAR, "~",
|
|
|
|
|
$1, (Node *) n, @2);
|
2002-09-22 19:27:25 +02:00
|
|
|
}
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
| a_expr SIMILAR TO a_expr ESCAPE a_expr %prec SIMILAR
|
2002-06-11 17:44:38 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
FuncCall *n = makeFuncCall(SystemFuncName("similar_to_escape"),
|
|
|
|
|
list_make2($4, $6),
|
|
|
|
|
COERCE_EXPLICIT_CALL,
|
|
|
|
|
@2);
|
2015-02-23 18:46:46 +01:00
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_SIMILAR, "~",
|
|
|
|
|
$1, (Node *) n, @2);
|
2002-06-11 17:44:38 +02:00
|
|
|
}
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
| a_expr NOT_LA SIMILAR TO a_expr %prec NOT_LA
|
2002-09-22 19:27:25 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
FuncCall *n = makeFuncCall(SystemFuncName("similar_to_escape"),
|
|
|
|
|
list_make1($5),
|
|
|
|
|
COERCE_EXPLICIT_CALL,
|
|
|
|
|
@2);
|
2015-02-23 18:46:46 +01:00
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_SIMILAR, "!~",
|
|
|
|
|
$1, (Node *) n, @2);
|
2002-09-22 19:27:25 +02:00
|
|
|
}
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
| a_expr NOT_LA SIMILAR TO a_expr ESCAPE a_expr %prec NOT_LA
|
2002-06-11 17:44:38 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
FuncCall *n = makeFuncCall(SystemFuncName("similar_to_escape"),
|
|
|
|
|
list_make2($5, $7),
|
|
|
|
|
COERCE_EXPLICIT_CALL,
|
|
|
|
|
@2);
|
2015-02-23 18:46:46 +01:00
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_SIMILAR, "!~",
|
|
|
|
|
$1, (Node *) n, @2);
|
2002-06-11 17:44:38 +02:00
|
|
|
}
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
/* NullTest clause
|
2013-04-20 17:04:41 +02:00
|
|
|
* Define SQL-style Null test clause.
|
2002-06-17 22:27:43 +02:00
|
|
|
* Allow two forms described in the standard:
|
|
|
|
|
* a IS NULL
|
|
|
|
|
* a IS NOT NULL
|
|
|
|
|
* Allow two SQL extensions
|
|
|
|
|
* a ISNULL
|
|
|
|
|
* a NOTNULL
|
|
|
|
|
*/
|
2011-05-06 02:38:52 +02:00
|
|
|
| a_expr IS NULL_P %prec IS
|
2001-06-20 00:39:12 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
NullTest *n = makeNode(NullTest);
|
|
|
|
|
|
2006-09-28 22:51:43 +02:00
|
|
|
n->arg = (Expr *) $1;
|
|
|
|
|
n->nulltesttype = IS_NULL;
|
2015-02-22 20:40:27 +01:00
|
|
|
n->location = @2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2001-06-20 00:39:12 +02:00
|
|
|
}
|
2006-09-28 22:51:43 +02:00
|
|
|
| a_expr ISNULL
|
2001-06-20 00:39:12 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
NullTest *n = makeNode(NullTest);
|
|
|
|
|
|
2006-09-28 22:51:43 +02:00
|
|
|
n->arg = (Expr *) $1;
|
|
|
|
|
n->nulltesttype = IS_NULL;
|
2015-02-22 20:40:27 +01:00
|
|
|
n->location = @2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2001-06-20 00:39:12 +02:00
|
|
|
}
|
2011-05-06 02:38:52 +02:00
|
|
|
| a_expr IS NOT NULL_P %prec IS
|
2001-06-20 00:39:12 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
NullTest *n = makeNode(NullTest);
|
|
|
|
|
|
2006-09-28 22:51:43 +02:00
|
|
|
n->arg = (Expr *) $1;
|
|
|
|
|
n->nulltesttype = IS_NOT_NULL;
|
2015-02-22 20:40:27 +01:00
|
|
|
n->location = @2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2006-09-28 22:51:43 +02:00
|
|
|
}
|
|
|
|
|
| a_expr NOTNULL
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
NullTest *n = makeNode(NullTest);
|
|
|
|
|
|
2006-09-28 22:51:43 +02:00
|
|
|
n->arg = (Expr *) $1;
|
|
|
|
|
n->nulltesttype = IS_NOT_NULL;
|
2015-02-22 20:40:27 +01:00
|
|
|
n->location = @2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-05-11 00:44:49 +02:00
|
|
|
}
|
|
|
|
|
| row OVERLAPS row
|
|
|
|
|
{
|
Remove broken code that tried to handle OVERLAPS with a single argument.
The SQL standard says that OVERLAPS should have a two-element row
constructor on each side. The original coding of OVERLAPS support in
our grammar attempted to extend that by allowing a single-element row
constructor, which it internally duplicated ... or tried to, anyway.
But that code has certainly not worked since our List infrastructure was
rewritten in 2004, and I'm none too sure it worked before that. As it
stands, it ends up building a List that includes itself, leading to
assorted undesirable behaviors later in the parser.
Even if it worked as intended, it'd be a bit evil because of the
possibility of duplicate evaluation of a volatile function that the user
had written only once. Given the lack of documentation, test cases, or
complaints, let's just get rid of the idea and only support the standard
syntax.
While we're at it, improve the error cursor positioning for the
wrong-number-of-arguments errors, and inline the makeOverlaps() function
since it's only called in one place anyway.
Per bug #9227 from Joshua Yanovski. Initial patch by Joshua Yanovski,
extended a bit by me.
2014-02-18 18:44:20 +01:00
|
|
|
if (list_length($1) != 2)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("wrong number of parameters on left side of OVERLAPS expression"),
|
|
|
|
|
parser_errposition(@1)));
|
|
|
|
|
if (list_length($3) != 2)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("wrong number of parameters on right side of OVERLAPS expression"),
|
|
|
|
|
parser_errposition(@3)));
|
|
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("overlaps"),
|
|
|
|
|
list_concat($1, $3),
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
COERCE_SQL_SYNTAX,
|
Remove broken code that tried to handle OVERLAPS with a single argument.
The SQL standard says that OVERLAPS should have a two-element row
constructor on each side. The original coding of OVERLAPS support in
our grammar attempted to extend that by allowing a single-element row
constructor, which it internally duplicated ... or tried to, anyway.
But that code has certainly not worked since our List infrastructure was
rewritten in 2004, and I'm none too sure it worked before that. As it
stands, it ends up building a List that includes itself, leading to
assorted undesirable behaviors later in the parser.
Even if it worked as intended, it'd be a bit evil because of the
possibility of duplicate evaluation of a volatile function that the user
had written only once. Given the lack of documentation, test cases, or
complaints, let's just get rid of the idea and only support the standard
syntax.
While we're at it, improve the error cursor positioning for the
wrong-number-of-arguments errors, and inline the makeOverlaps() function
since it's only called in one place anyway.
Per bug #9227 from Joshua Yanovski. Initial patch by Joshua Yanovski,
extended a bit by me.
2014-02-18 18:44:20 +01:00
|
|
|
@2);
|
2001-06-20 00:39:12 +02:00
|
|
|
}
|
2011-05-06 02:38:52 +02:00
|
|
|
| a_expr IS TRUE_P %prec IS
|
1997-10-25 07:56:41 +02:00
|
|
|
{
|
2001-06-20 00:39:12 +02:00
|
|
|
BooleanTest *b = makeNode(BooleanTest);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-12-12 16:49:42 +01:00
|
|
|
b->arg = (Expr *) $1;
|
2001-06-20 00:39:12 +02:00
|
|
|
b->booltesttype = IS_TRUE;
|
2015-02-22 20:40:27 +01:00
|
|
|
b->location = @2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) b;
|
1997-10-25 07:56:41 +02:00
|
|
|
}
|
2011-05-06 02:38:52 +02:00
|
|
|
| a_expr IS NOT TRUE_P %prec IS
|
1997-10-25 07:56:41 +02:00
|
|
|
{
|
2001-06-20 00:39:12 +02:00
|
|
|
BooleanTest *b = makeNode(BooleanTest);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-12-12 16:49:42 +01:00
|
|
|
b->arg = (Expr *) $1;
|
2001-06-20 00:39:12 +02:00
|
|
|
b->booltesttype = IS_NOT_TRUE;
|
2015-02-22 20:40:27 +01:00
|
|
|
b->location = @2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) b;
|
1997-10-25 07:56:41 +02:00
|
|
|
}
|
2011-05-06 02:38:52 +02:00
|
|
|
| a_expr IS FALSE_P %prec IS
|
1997-10-25 07:56:41 +02:00
|
|
|
{
|
2001-06-20 00:39:12 +02:00
|
|
|
BooleanTest *b = makeNode(BooleanTest);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-12-12 16:49:42 +01:00
|
|
|
b->arg = (Expr *) $1;
|
2001-06-20 00:39:12 +02:00
|
|
|
b->booltesttype = IS_FALSE;
|
2015-02-22 20:40:27 +01:00
|
|
|
b->location = @2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) b;
|
1997-10-25 07:56:41 +02:00
|
|
|
}
|
2011-05-06 02:38:52 +02:00
|
|
|
| a_expr IS NOT FALSE_P %prec IS
|
1997-10-25 07:56:41 +02:00
|
|
|
{
|
2001-06-20 00:39:12 +02:00
|
|
|
BooleanTest *b = makeNode(BooleanTest);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-12-12 16:49:42 +01:00
|
|
|
b->arg = (Expr *) $1;
|
2001-06-20 00:39:12 +02:00
|
|
|
b->booltesttype = IS_NOT_FALSE;
|
2015-02-22 20:40:27 +01:00
|
|
|
b->location = @2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) b;
|
2001-06-20 00:39:12 +02:00
|
|
|
}
|
2011-05-06 02:38:52 +02:00
|
|
|
| a_expr IS UNKNOWN %prec IS
|
2001-06-20 00:39:12 +02:00
|
|
|
{
|
|
|
|
|
BooleanTest *b = makeNode(BooleanTest);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-12-12 16:49:42 +01:00
|
|
|
b->arg = (Expr *) $1;
|
2001-06-20 00:39:12 +02:00
|
|
|
b->booltesttype = IS_UNKNOWN;
|
2015-02-22 20:40:27 +01:00
|
|
|
b->location = @2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) b;
|
2001-06-20 00:39:12 +02:00
|
|
|
}
|
2011-05-06 02:38:52 +02:00
|
|
|
| a_expr IS NOT UNKNOWN %prec IS
|
2001-06-20 00:39:12 +02:00
|
|
|
{
|
|
|
|
|
BooleanTest *b = makeNode(BooleanTest);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2002-12-12 16:49:42 +01:00
|
|
|
b->arg = (Expr *) $1;
|
2001-06-20 00:39:12 +02:00
|
|
|
b->booltesttype = IS_NOT_UNKNOWN;
|
2015-02-22 20:40:27 +01:00
|
|
|
b->location = @2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) b;
|
1997-10-25 07:56:41 +02:00
|
|
|
}
|
2002-09-06 00:52:48 +02:00
|
|
|
| a_expr IS DISTINCT FROM a_expr %prec IS
|
2004-05-11 00:44:49 +02:00
|
|
|
{
|
2006-03-14 23:48:25 +01:00
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_DISTINCT, "=", $1, $5, @2);
|
2004-05-11 00:44:49 +02:00
|
|
|
}
|
2005-12-11 11:54:28 +01:00
|
|
|
| a_expr IS NOT DISTINCT FROM a_expr %prec IS
|
|
|
|
|
{
|
2016-07-28 23:23:03 +02:00
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_NOT_DISTINCT, "=", $1, $6, @2);
|
2005-12-11 11:54:28 +01:00
|
|
|
}
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
| a_expr BETWEEN opt_asymmetric b_expr AND a_expr %prec BETWEEN
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2015-02-22 19:57:56 +01:00
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_BETWEEN,
|
|
|
|
|
"BETWEEN",
|
|
|
|
|
$1,
|
|
|
|
|
(Node *) list_make2($4, $6),
|
|
|
|
|
@2);
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
| a_expr NOT_LA BETWEEN opt_asymmetric b_expr AND a_expr %prec NOT_LA
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2015-02-22 19:57:56 +01:00
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_NOT_BETWEEN,
|
|
|
|
|
"NOT BETWEEN",
|
|
|
|
|
$1,
|
|
|
|
|
(Node *) list_make2($5, $7),
|
|
|
|
|
@2);
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
| a_expr BETWEEN SYMMETRIC b_expr AND a_expr %prec BETWEEN
|
2005-06-15 01:47:39 +02:00
|
|
|
{
|
2015-02-22 19:57:56 +01:00
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_BETWEEN_SYM,
|
|
|
|
|
"BETWEEN SYMMETRIC",
|
|
|
|
|
$1,
|
|
|
|
|
(Node *) list_make2($4, $6),
|
|
|
|
|
@2);
|
2005-06-15 01:47:39 +02:00
|
|
|
}
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
| a_expr NOT_LA BETWEEN SYMMETRIC b_expr AND a_expr %prec NOT_LA
|
2005-06-15 01:47:39 +02:00
|
|
|
{
|
2015-02-22 19:57:56 +01:00
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_NOT_BETWEEN_SYM,
|
|
|
|
|
"NOT BETWEEN SYMMETRIC",
|
|
|
|
|
$1,
|
|
|
|
|
(Node *) list_make2($5, $7),
|
|
|
|
|
@2);
|
2005-06-15 01:47:39 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| a_expr IN_P in_expr
|
1998-01-17 05:53:46 +01:00
|
|
|
{
|
1999-07-28 19:39:38 +02:00
|
|
|
/* in_expr returns a SubLink or a list of a_exprs */
|
2001-01-15 21:36:36 +01:00
|
|
|
if (IsA($3, SubLink))
|
1998-01-17 05:53:46 +01:00
|
|
|
{
|
2005-11-28 05:35:32 +01:00
|
|
|
/* generate foo = ANY (subquery) */
|
2022-05-13 07:17:29 +02:00
|
|
|
SubLink *n = (SubLink *) $3;
|
|
|
|
|
|
2005-11-28 05:35:32 +01:00
|
|
|
n->subLinkType = ANY_SUBLINK;
|
Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...
This SQL-standard feature allows a sub-SELECT yielding multiple columns
(but only one row) to be used to compute the new values of several columns
to be updated. While the same results can be had with an independent
sub-SELECT per column, such a workaround can require a great deal of
duplicated computation.
The standard actually says that the source for a multi-column assignment
could be any row-valued expression. The implementation used here is
tightly tied to our existing sub-SELECT support and can't handle other
cases; the Bison grammar would have some issues with them too. However,
I don't feel too bad about this since other cases can be converted into
sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could
be written "SET (a,b,c) = (SELECT * FROM row_valued_function(x))".
2014-06-18 19:22:25 +02:00
|
|
|
n->subLinkId = 0;
|
2005-12-28 02:30:02 +01:00
|
|
|
n->testexpr = $1;
|
2015-02-23 18:46:46 +01:00
|
|
|
n->operName = NIL; /* show it's IN not = ANY */
|
2008-08-29 01:09:48 +02:00
|
|
|
n->location = @2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1998-01-17 05:53:46 +01:00
|
|
|
}
|
1999-07-28 19:39:38 +02:00
|
|
|
else
|
|
|
|
|
{
|
2005-11-28 05:35:32 +01:00
|
|
|
/* generate scalar IN expression */
|
2006-03-14 23:48:25 +01:00
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_IN, "=", $1, $3, @2);
|
1999-07-28 19:39:38 +02:00
|
|
|
}
|
1998-01-17 05:53:46 +01:00
|
|
|
}
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
| a_expr NOT_LA IN_P in_expr %prec NOT_LA
|
1998-01-17 05:53:46 +01:00
|
|
|
{
|
1999-07-28 19:39:38 +02:00
|
|
|
/* in_expr returns a SubLink or a list of a_exprs */
|
2001-01-15 21:36:36 +01:00
|
|
|
if (IsA($4, SubLink))
|
1998-01-17 05:53:46 +01:00
|
|
|
{
|
2005-11-28 05:35:32 +01:00
|
|
|
/* generate NOT (foo = ANY (subquery)) */
|
|
|
|
|
/* Make an = ANY node */
|
2022-05-13 07:17:29 +02:00
|
|
|
SubLink *n = (SubLink *) $4;
|
|
|
|
|
|
2003-01-09 21:50:53 +01:00
|
|
|
n->subLinkType = ANY_SUBLINK;
|
Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...
This SQL-standard feature allows a sub-SELECT yielding multiple columns
(but only one row) to be used to compute the new values of several columns
to be updated. While the same results can be had with an independent
sub-SELECT per column, such a workaround can require a great deal of
duplicated computation.
The standard actually says that the source for a multi-column assignment
could be any row-valued expression. The implementation used here is
tightly tied to our existing sub-SELECT support and can't handle other
cases; the Bison grammar would have some issues with them too. However,
I don't feel too bad about this since other cases can be converted into
sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could
be written "SET (a,b,c) = (SELECT * FROM row_valued_function(x))".
2014-06-18 19:22:25 +02:00
|
|
|
n->subLinkId = 0;
|
2005-12-28 02:30:02 +01:00
|
|
|
n->testexpr = $1;
|
2015-02-23 18:46:46 +01:00
|
|
|
n->operName = NIL; /* show it's IN not = ANY */
|
|
|
|
|
n->location = @2;
|
|
|
|
|
/* Stick a NOT on top; must have same parse location */
|
2014-06-16 21:55:05 +02:00
|
|
|
$$ = makeNotExpr((Node *) n, @2);
|
1999-07-28 19:39:38 +02:00
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
2005-11-28 05:35:32 +01:00
|
|
|
/* generate scalar NOT IN expression */
|
2006-03-14 23:48:25 +01:00
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_IN, "<>", $1, $4, @2);
|
1998-01-17 05:53:46 +01:00
|
|
|
}
|
|
|
|
|
}
|
2006-01-22 21:03:16 +01:00
|
|
|
| a_expr subquery_Op sub_type select_with_parens %prec Op
|
1998-02-03 20:27:30 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
SubLink *n = makeNode(SubLink);
|
|
|
|
|
|
1999-11-15 03:00:15 +01:00
|
|
|
n->subLinkType = $3;
|
Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...
This SQL-standard feature allows a sub-SELECT yielding multiple columns
(but only one row) to be used to compute the new values of several columns
to be updated. While the same results can be had with an independent
sub-SELECT per column, such a workaround can require a great deal of
duplicated computation.
The standard actually says that the source for a multi-column assignment
could be any row-valued expression. The implementation used here is
tightly tied to our existing sub-SELECT support and can't handle other
cases; the Bison grammar would have some issues with them too. However,
I don't feel too bad about this since other cases can be converted into
sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could
be written "SET (a,b,c) = (SELECT * FROM row_valued_function(x))".
2014-06-18 19:22:25 +02:00
|
|
|
n->subLinkId = 0;
|
2005-12-28 02:30:02 +01:00
|
|
|
n->testexpr = $1;
|
2003-01-10 22:08:15 +01:00
|
|
|
n->operName = $2;
|
2001-01-15 21:36:36 +01:00
|
|
|
n->subselect = $4;
|
2008-08-29 01:09:48 +02:00
|
|
|
n->location = @2;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1998-02-03 20:27:30 +01:00
|
|
|
}
|
2006-01-22 21:03:16 +01:00
|
|
|
| a_expr subquery_Op sub_type '(' a_expr ')' %prec Op
|
2003-06-29 02:33:44 +02:00
|
|
|
{
|
|
|
|
|
if ($3 == ANY_SUBLINK)
|
2006-03-14 23:48:25 +01:00
|
|
|
$$ = (Node *) makeA_Expr(AEXPR_OP_ANY, $2, $1, $5, @2);
|
2003-06-29 02:33:44 +02:00
|
|
|
else
|
2006-03-14 23:48:25 +01:00
|
|
|
$$ = (Node *) makeA_Expr(AEXPR_OP_ALL, $2, $1, $5, @2);
|
2003-06-29 02:33:44 +02:00
|
|
|
}
|
2022-02-03 11:29:54 +01:00
|
|
|
| UNIQUE opt_unique_null_treatment select_with_parens
|
2002-08-04 08:51:23 +02:00
|
|
|
{
|
|
|
|
|
/* Not sure how to get rid of the parentheses
|
|
|
|
|
* but there are lots of shift/reduce errors without them.
|
|
|
|
|
*
|
|
|
|
|
* Should be able to implement this by plopping the entire
|
|
|
|
|
* select into a node, then transforming the target expressions
|
|
|
|
|
* from whatever they are into count(*), and testing the
|
|
|
|
|
* entire result equal to one.
|
|
|
|
|
* But, will probably implement a separate node in the executor.
|
|
|
|
|
*/
|
2003-07-19 22:20:53 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
2008-09-01 22:42:46 +02:00
|
|
|
errmsg("UNIQUE predicate is not yet implemented"),
|
2009-07-13 04:02:20 +02:00
|
|
|
parser_errposition(@1)));
|
2002-08-04 08:51:23 +02:00
|
|
|
}
|
2007-01-14 14:11:54 +01:00
|
|
|
| a_expr IS DOCUMENT_P %prec IS
|
|
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeXmlExpr(IS_DOCUMENT, NULL, NIL,
|
|
|
|
|
list_make1($1), @2);
|
2007-01-14 14:11:54 +01:00
|
|
|
}
|
|
|
|
|
| a_expr IS NOT DOCUMENT_P %prec IS
|
|
|
|
|
{
|
2014-06-16 21:55:05 +02:00
|
|
|
$$ = makeNotExpr(makeXmlExpr(IS_DOCUMENT, NULL, NIL,
|
|
|
|
|
list_make1($1), @2),
|
|
|
|
|
@2);
|
2007-01-14 14:11:54 +01:00
|
|
|
}
|
2020-03-26 08:14:00 +01:00
|
|
|
| a_expr IS NORMALIZED %prec IS
|
|
|
|
|
{
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("is_normalized"),
|
|
|
|
|
list_make1($1),
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@2);
|
2020-03-26 08:14:00 +01:00
|
|
|
}
|
|
|
|
|
| a_expr IS unicode_normal_form NORMALIZED %prec IS
|
|
|
|
|
{
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("is_normalized"),
|
|
|
|
|
list_make2($1, makeStringConst($3, @3)),
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@2);
|
2020-03-26 08:14:00 +01:00
|
|
|
}
|
|
|
|
|
| a_expr IS NOT NORMALIZED %prec IS
|
|
|
|
|
{
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
$$ = makeNotExpr((Node *) makeFuncCall(SystemFuncName("is_normalized"),
|
|
|
|
|
list_make1($1),
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@2),
|
|
|
|
|
@2);
|
2020-03-26 08:14:00 +01:00
|
|
|
}
|
|
|
|
|
| a_expr IS NOT unicode_normal_form NORMALIZED %prec IS
|
|
|
|
|
{
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
$$ = makeNotExpr((Node *) makeFuncCall(SystemFuncName("is_normalized"),
|
|
|
|
|
list_make2($1, makeStringConst($4, @4)),
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@2),
|
|
|
|
|
@2);
|
2020-03-26 08:14:00 +01:00
|
|
|
}
|
SQL/JSON: support the IS JSON predicate
This patch introduces the SQL standard IS JSON predicate. It operates
on text and bytea values representing JSON, as well as on the json and
jsonb types. Each test has IS and IS NOT variants and supports a WITH
UNIQUE KEYS flag. The tests are:
IS JSON [VALUE]
IS JSON ARRAY
IS JSON OBJECT
IS JSON SCALAR
These should be self-explanatory.
The WITH UNIQUE KEYS flag makes these return false when duplicate keys
exist in any object within the value, not necessarily directly contained
in the outermost object.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Author: Andrew Dunstan <andrew@dunslane.net>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-31 22:34:04 +02:00
|
|
|
| a_expr IS json_predicate_type_constraint
|
|
|
|
|
json_key_uniqueness_constraint_opt %prec IS
|
|
|
|
|
{
|
|
|
|
|
JsonFormat *format = makeJsonFormat(JS_FORMAT_DEFAULT, JS_ENC_DEFAULT, -1);
|
|
|
|
|
|
|
|
|
|
$$ = makeJsonIsPredicate($1, format, $3, $4, @1);
|
|
|
|
|
}
|
|
|
|
|
/*
|
|
|
|
|
* Required by SQL/JSON, but there are conflicts
|
|
|
|
|
| a_expr
|
|
|
|
|
FORMAT_LA JSON json_encoding_clause_opt
|
|
|
|
|
IS json_predicate_type_constraint
|
|
|
|
|
json_key_uniqueness_constraint_opt %prec IS
|
|
|
|
|
{
|
|
|
|
|
$3.location = @2;
|
|
|
|
|
$$ = makeJsonIsPredicate($1, $3, $5, $6, @1);
|
|
|
|
|
}
|
|
|
|
|
*/
|
|
|
|
|
| a_expr IS NOT
|
|
|
|
|
json_predicate_type_constraint
|
|
|
|
|
json_key_uniqueness_constraint_opt %prec IS
|
|
|
|
|
{
|
|
|
|
|
JsonFormat *format = makeJsonFormat(JS_FORMAT_DEFAULT, JS_ENC_DEFAULT, -1);
|
|
|
|
|
|
|
|
|
|
$$ = makeNotExpr(makeJsonIsPredicate($1, format, $4, $5, @1), @1);
|
|
|
|
|
}
|
|
|
|
|
/*
|
|
|
|
|
* Required by SQL/JSON, but there are conflicts
|
|
|
|
|
| a_expr
|
|
|
|
|
FORMAT_LA JSON json_encoding_clause_opt
|
|
|
|
|
IS NOT
|
|
|
|
|
json_predicate_type_constraint
|
|
|
|
|
json_key_uniqueness_constraint_opt %prec IS
|
|
|
|
|
{
|
|
|
|
|
$3.location = @2;
|
|
|
|
|
$$ = makeNotExpr(makeJsonIsPredicate($1, $3, $6, $7, @1), @1);
|
|
|
|
|
}
|
|
|
|
|
*/
|
Improve handling of "UPDATE ... SET (column_list) = row_constructor".
Previously, the right-hand side of a multiple-column assignment, if it
wasn't a sub-SELECT, had to be a simple parenthesized expression list,
because gram.y was responsible for "bursting" the construct into
independent column assignments. This had the minor defect that you
couldn't write ROW (though you should be able to, since the standard says
this is a row constructor), and the rather larger defect that unlike other
uses of row constructors, we would not expand a "foo.*" item into multiple
columns.
Fix that by changing the RHS to be just "a_expr" in the grammar, leaving
it to transformMultiAssignRef to separate the elements of a RowExpr;
which it will do only after performing standard transformation of the
RowExpr, so that "foo.*" behaves as expected.
The key reason we didn't do that before was the hard-wired handling of
DEFAULT tokens (SetToDefault nodes). This patch deals with that issue by
allowing DEFAULT in any a_expr and having parse analysis throw an error
if SetToDefault is found in an unexpected place. That's an improvement
anyway since the error can be more specific than just "syntax error".
The SQL standard suggests that the RHS could be any a_expr yielding a
suitable row value. This patch doesn't really move the goal posts in that
respect --- you're still limited to RowExpr or a sub-SELECT --- but it does
fix the grammar restriction, so it provides some tangible progress towards
a full implementation. And the limitation is now documented by an explicit
error message rather than an unhelpful "syntax error".
Discussion: <8542.1479742008@sss.pgh.pa.us>
2016-11-22 21:19:57 +01:00
|
|
|
| DEFAULT
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* The SQL spec only allows DEFAULT in "contextually typed
|
|
|
|
|
* expressions", but for us, it's easier to allow it in
|
|
|
|
|
* any a_expr and then throw error during parse analysis
|
|
|
|
|
* if it's in an inappropriate context. This way also
|
|
|
|
|
* lets us say something smarter than "syntax error".
|
|
|
|
|
*/
|
|
|
|
|
SetToDefault *n = makeNode(SetToDefault);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Improve handling of "UPDATE ... SET (column_list) = row_constructor".
Previously, the right-hand side of a multiple-column assignment, if it
wasn't a sub-SELECT, had to be a simple parenthesized expression list,
because gram.y was responsible for "bursting" the construct into
independent column assignments. This had the minor defect that you
couldn't write ROW (though you should be able to, since the standard says
this is a row constructor), and the rather larger defect that unlike other
uses of row constructors, we would not expand a "foo.*" item into multiple
columns.
Fix that by changing the RHS to be just "a_expr" in the grammar, leaving
it to transformMultiAssignRef to separate the elements of a RowExpr;
which it will do only after performing standard transformation of the
RowExpr, so that "foo.*" behaves as expected.
The key reason we didn't do that before was the hard-wired handling of
DEFAULT tokens (SetToDefault nodes). This patch deals with that issue by
allowing DEFAULT in any a_expr and having parse analysis throw an error
if SetToDefault is found in an unexpected place. That's an improvement
anyway since the error can be more specific than just "syntax error".
The SQL standard suggests that the RHS could be any a_expr yielding a
suitable row value. This patch doesn't really move the goal posts in that
respect --- you're still limited to RowExpr or a sub-SELECT --- but it does
fix the grammar restriction, so it provides some tangible progress towards
a full implementation. And the limitation is now documented by an explicit
error message rather than an unhelpful "syntax error".
Discussion: <8542.1479742008@sss.pgh.pa.us>
2016-11-22 21:19:57 +01:00
|
|
|
/* parse analysis will fill in the rest */
|
|
|
|
|
n->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
Improve handling of "UPDATE ... SET (column_list) = row_constructor".
Previously, the right-hand side of a multiple-column assignment, if it
wasn't a sub-SELECT, had to be a simple parenthesized expression list,
because gram.y was responsible for "bursting" the construct into
independent column assignments. This had the minor defect that you
couldn't write ROW (though you should be able to, since the standard says
this is a row constructor), and the rather larger defect that unlike other
uses of row constructors, we would not expand a "foo.*" item into multiple
columns.
Fix that by changing the RHS to be just "a_expr" in the grammar, leaving
it to transformMultiAssignRef to separate the elements of a RowExpr;
which it will do only after performing standard transformation of the
RowExpr, so that "foo.*" behaves as expected.
The key reason we didn't do that before was the hard-wired handling of
DEFAULT tokens (SetToDefault nodes). This patch deals with that issue by
allowing DEFAULT in any a_expr and having parse analysis throw an error
if SetToDefault is found in an unexpected place. That's an improvement
anyway since the error can be more specific than just "syntax error".
The SQL standard suggests that the RHS could be any a_expr yielding a
suitable row value. This patch doesn't really move the goal posts in that
respect --- you're still limited to RowExpr or a sub-SELECT --- but it does
fix the grammar restriction, so it provides some tangible progress towards
a full implementation. And the limitation is now documented by an explicit
error message rather than an unhelpful "syntax error".
Discussion: <8542.1479742008@sss.pgh.pa.us>
2016-11-22 21:19:57 +01:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1999-11-20 22:39:36 +01:00
|
|
|
/*
|
|
|
|
|
* Restricted expressions
|
|
|
|
|
*
|
|
|
|
|
* b_expr is a subset of the complete expression syntax defined by a_expr.
|
|
|
|
|
*
|
2000-03-12 01:39:52 +01:00
|
|
|
* Presently, AND, NOT, IS, and IN are the a_expr keywords that would
|
1999-11-20 22:39:36 +01:00
|
|
|
* cause trouble in the places where b_expr is used. For simplicity, we
|
|
|
|
|
* just eliminate all the boolean-keyword-operator productions from b_expr.
|
1998-02-04 07:11:48 +01:00
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
b_expr: c_expr
|
|
|
|
|
{ $$ = $1; }
|
|
|
|
|
| b_expr TYPECAST Typename
|
2008-08-29 01:09:48 +02:00
|
|
|
{ $$ = makeTypeCast($1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| '+' b_expr %prec UMINUS
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "+", NULL, $2, @1); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| '-' b_expr %prec UMINUS
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = doNegate($2, @1); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| b_expr '+' b_expr
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "+", $1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| b_expr '-' b_expr
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "-", $1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| b_expr '*' b_expr
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "*", $1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| b_expr '/' b_expr
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "/", $1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| b_expr '%' b_expr
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "%", $1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| b_expr '^' b_expr
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "^", $1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| b_expr '<' b_expr
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "<", $1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| b_expr '>' b_expr
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, ">", $1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| b_expr '=' b_expr
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "=", $1, $3, @2); }
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
| b_expr LESS_EQUALS b_expr
|
|
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "<=", $1, $3, @2); }
|
|
|
|
|
| b_expr GREATER_EQUALS b_expr
|
|
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, ">=", $1, $3, @2); }
|
|
|
|
|
| b_expr NOT_EQUALS b_expr
|
|
|
|
|
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "<>", $1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| b_expr qual_Op b_expr %prec Op
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeA_Expr(AEXPR_OP, $2, $1, $3, @2); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| qual_Op b_expr %prec Op
|
2006-03-14 23:48:25 +01:00
|
|
|
{ $$ = (Node *) makeA_Expr(AEXPR_OP, $1, NULL, $2, @1); }
|
2006-01-22 21:03:16 +01:00
|
|
|
| b_expr IS DISTINCT FROM b_expr %prec IS
|
2004-05-11 00:44:49 +02:00
|
|
|
{
|
2006-03-14 23:48:25 +01:00
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_DISTINCT, "=", $1, $5, @2);
|
2004-05-11 00:44:49 +02:00
|
|
|
}
|
2005-12-11 11:54:28 +01:00
|
|
|
| b_expr IS NOT DISTINCT FROM b_expr %prec IS
|
|
|
|
|
{
|
2016-07-28 23:23:03 +02:00
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_NOT_DISTINCT, "=", $1, $6, @2);
|
2005-12-11 11:54:28 +01:00
|
|
|
}
|
2007-01-14 14:11:54 +01:00
|
|
|
| b_expr IS DOCUMENT_P %prec IS
|
|
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeXmlExpr(IS_DOCUMENT, NULL, NIL,
|
|
|
|
|
list_make1($1), @2);
|
2007-01-14 14:11:54 +01:00
|
|
|
}
|
|
|
|
|
| b_expr IS NOT DOCUMENT_P %prec IS
|
|
|
|
|
{
|
2014-06-16 21:55:05 +02:00
|
|
|
$$ = makeNotExpr(makeXmlExpr(IS_DOCUMENT, NULL, NIL,
|
|
|
|
|
list_make1($1), @2),
|
|
|
|
|
@2);
|
2007-01-14 14:11:54 +01:00
|
|
|
}
|
1999-11-20 22:39:36 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Productions that can be used in both a_expr and b_expr.
|
|
|
|
|
*
|
|
|
|
|
* Note: productions that refer recursively to a_expr or b_expr mostly
|
2002-06-17 22:27:43 +02:00
|
|
|
* cannot appear here. However, it's OK to refer to a_exprs that occur
|
1999-11-20 22:39:36 +01:00
|
|
|
* inside parentheses, such as function arguments; that cannot introduce
|
|
|
|
|
* ambiguity to the b_expr syntax.
|
|
|
|
|
*/
|
2004-06-09 21:08:20 +02:00
|
|
|
c_expr: columnref { $$ = $1; }
|
2002-06-17 22:27:43 +02:00
|
|
|
| AexprConst { $$ = $1; }
|
2004-06-09 21:08:20 +02:00
|
|
|
| PARAM opt_indirection
|
2002-03-21 17:02:16 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
ParamRef *p = makeNode(ParamRef);
|
|
|
|
|
|
2004-06-09 21:08:20 +02:00
|
|
|
p->number = $1;
|
2008-08-29 01:09:48 +02:00
|
|
|
p->location = @1;
|
2004-06-09 21:08:20 +02:00
|
|
|
if ($2)
|
|
|
|
|
{
|
|
|
|
|
A_Indirection *n = makeNode(A_Indirection);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-06-09 21:08:20 +02:00
|
|
|
n->arg = (Node *) p;
|
2009-07-13 04:02:20 +02:00
|
|
|
n->indirection = check_indirection($2, yyscanner);
|
2004-06-09 21:08:20 +02:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
$$ = (Node *) p;
|
2002-03-21 17:02:16 +01:00
|
|
|
}
|
2003-04-09 01:20:04 +02:00
|
|
|
| '(' a_expr ')' opt_indirection
|
|
|
|
|
{
|
|
|
|
|
if ($4)
|
|
|
|
|
{
|
2004-06-09 21:08:20 +02:00
|
|
|
A_Indirection *n = makeNode(A_Indirection);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2003-04-09 01:20:04 +02:00
|
|
|
n->arg = $2;
|
2009-07-13 04:02:20 +02:00
|
|
|
n->indirection = check_indirection($4, yyscanner);
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2003-04-09 01:20:04 +02:00
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
$$ = $2;
|
|
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| case_expr
|
|
|
|
|
{ $$ = $1; }
|
2004-09-30 01:39:20 +02:00
|
|
|
| func_expr
|
|
|
|
|
{ $$ = $1; }
|
|
|
|
|
| select_with_parens %prec UMINUS
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
SubLink *n = makeNode(SubLink);
|
|
|
|
|
|
2004-09-30 01:39:20 +02:00
|
|
|
n->subLinkType = EXPR_SUBLINK;
|
Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...
This SQL-standard feature allows a sub-SELECT yielding multiple columns
(but only one row) to be used to compute the new values of several columns
to be updated. While the same results can be had with an independent
sub-SELECT per column, such a workaround can require a great deal of
duplicated computation.
The standard actually says that the source for a multi-column assignment
could be any row-valued expression. The implementation used here is
tightly tied to our existing sub-SELECT support and can't handle other
cases; the Bison grammar would have some issues with them too. However,
I don't feel too bad about this since other cases can be converted into
sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could
be written "SET (a,b,c) = (SELECT * FROM row_valued_function(x))".
2014-06-18 19:22:25 +02:00
|
|
|
n->subLinkId = 0;
|
2005-12-28 02:30:02 +01:00
|
|
|
n->testexpr = NULL;
|
2004-09-30 01:39:20 +02:00
|
|
|
n->operName = NIL;
|
|
|
|
|
n->subselect = $1;
|
2008-08-29 01:09:48 +02:00
|
|
|
n->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-09-30 01:39:20 +02:00
|
|
|
}
|
2013-01-30 20:16:16 +01:00
|
|
|
| select_with_parens indirection
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* Because the select_with_parens nonterminal is designed
|
|
|
|
|
* to "eat" as many levels of parens as possible, the
|
|
|
|
|
* '(' a_expr ')' opt_indirection production above will
|
|
|
|
|
* fail to match a sub-SELECT with indirection decoration;
|
|
|
|
|
* the sub-SELECT won't be regarded as an a_expr as long
|
|
|
|
|
* as there are parens around it. To support applying
|
|
|
|
|
* subscripting or field selection to a sub-SELECT result,
|
|
|
|
|
* we need this redundant-looking production.
|
|
|
|
|
*/
|
2022-05-13 07:17:29 +02:00
|
|
|
SubLink *n = makeNode(SubLink);
|
2013-01-30 20:16:16 +01:00
|
|
|
A_Indirection *a = makeNode(A_Indirection);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2013-01-30 20:16:16 +01:00
|
|
|
n->subLinkType = EXPR_SUBLINK;
|
Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...
This SQL-standard feature allows a sub-SELECT yielding multiple columns
(but only one row) to be used to compute the new values of several columns
to be updated. While the same results can be had with an independent
sub-SELECT per column, such a workaround can require a great deal of
duplicated computation.
The standard actually says that the source for a multi-column assignment
could be any row-valued expression. The implementation used here is
tightly tied to our existing sub-SELECT support and can't handle other
cases; the Bison grammar would have some issues with them too. However,
I don't feel too bad about this since other cases can be converted into
sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could
be written "SET (a,b,c) = (SELECT * FROM row_valued_function(x))".
2014-06-18 19:22:25 +02:00
|
|
|
n->subLinkId = 0;
|
2013-01-30 20:16:16 +01:00
|
|
|
n->testexpr = NULL;
|
|
|
|
|
n->operName = NIL;
|
|
|
|
|
n->subselect = $1;
|
|
|
|
|
n->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
a->arg = (Node *) n;
|
2013-01-30 20:16:16 +01:00
|
|
|
a->indirection = check_indirection($2, yyscanner);
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) a;
|
2013-01-30 20:16:16 +01:00
|
|
|
}
|
2004-09-30 01:39:20 +02:00
|
|
|
| EXISTS select_with_parens
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
SubLink *n = makeNode(SubLink);
|
|
|
|
|
|
2004-09-30 01:39:20 +02:00
|
|
|
n->subLinkType = EXISTS_SUBLINK;
|
Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...
This SQL-standard feature allows a sub-SELECT yielding multiple columns
(but only one row) to be used to compute the new values of several columns
to be updated. While the same results can be had with an independent
sub-SELECT per column, such a workaround can require a great deal of
duplicated computation.
The standard actually says that the source for a multi-column assignment
could be any row-valued expression. The implementation used here is
tightly tied to our existing sub-SELECT support and can't handle other
cases; the Bison grammar would have some issues with them too. However,
I don't feel too bad about this since other cases can be converted into
sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could
be written "SET (a,b,c) = (SELECT * FROM row_valued_function(x))".
2014-06-18 19:22:25 +02:00
|
|
|
n->subLinkId = 0;
|
2005-12-28 02:30:02 +01:00
|
|
|
n->testexpr = NULL;
|
2004-09-30 01:39:20 +02:00
|
|
|
n->operName = NIL;
|
|
|
|
|
n->subselect = $2;
|
2008-08-29 01:09:48 +02:00
|
|
|
n->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-09-30 01:39:20 +02:00
|
|
|
}
|
|
|
|
|
| ARRAY select_with_parens
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
SubLink *n = makeNode(SubLink);
|
|
|
|
|
|
2004-09-30 01:39:20 +02:00
|
|
|
n->subLinkType = ARRAY_SUBLINK;
|
Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...
This SQL-standard feature allows a sub-SELECT yielding multiple columns
(but only one row) to be used to compute the new values of several columns
to be updated. While the same results can be had with an independent
sub-SELECT per column, such a workaround can require a great deal of
duplicated computation.
The standard actually says that the source for a multi-column assignment
could be any row-valued expression. The implementation used here is
tightly tied to our existing sub-SELECT support and can't handle other
cases; the Bison grammar would have some issues with them too. However,
I don't feel too bad about this since other cases can be converted into
sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could
be written "SET (a,b,c) = (SELECT * FROM row_valued_function(x))".
2014-06-18 19:22:25 +02:00
|
|
|
n->subLinkId = 0;
|
2005-12-28 02:30:02 +01:00
|
|
|
n->testexpr = NULL;
|
2004-09-30 01:39:20 +02:00
|
|
|
n->operName = NIL;
|
|
|
|
|
n->subselect = $2;
|
2008-08-29 01:09:48 +02:00
|
|
|
n->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2004-09-30 01:39:20 +02:00
|
|
|
}
|
|
|
|
|
| ARRAY array_expr
|
2008-08-29 01:09:48 +02:00
|
|
|
{
|
2017-02-21 17:33:07 +01:00
|
|
|
A_ArrayExpr *n = castNode(A_ArrayExpr, $2);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2008-08-29 01:09:48 +02:00
|
|
|
/* point outermost A_ArrayExpr to the ARRAY keyword */
|
|
|
|
|
n->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2008-08-29 01:09:48 +02:00
|
|
|
}
|
Support GROUPING SETS, CUBE and ROLLUP.
This SQL standard functionality allows to aggregate data by different
GROUP BY clauses at once. Each grouping set returns rows with columns
grouped by in other sets set to NULL.
This could previously be achieved by doing each grouping as a separate
query, conjoined by UNION ALLs. Besides being considerably more concise,
grouping sets will in many cases be faster, requiring only one scan over
the underlying data.
The current implementation of grouping sets only supports using sorting
for input. Individual sets that share a sort order are computed in one
pass. If there are sets that don't share a sort order, additional sort &
aggregation steps are performed. These additional passes are sourced by
the previous sort step; thus avoiding repeated scans of the source data.
The code is structured in a way that adding support for purely using
hash aggregation or a mix of hashing and sorting is possible. Sorting
was chosen to be supported first, as it is the most generic method of
implementation.
Instead of, as in an earlier versions of the patch, representing the
chain of sort and aggregation steps as full blown planner and executor
nodes, all but the first sort are performed inside the aggregation node
itself. This avoids the need to do some unusual gymnastics to handle
having to return aggregated and non-aggregated tuples from underlying
nodes, as well as having to shut down underlying nodes early to limit
memory usage. The optimizer still builds Sort/Agg node to describe each
phase, but they're not part of the plan tree, but instead additional
data for the aggregation node. They're a convenient and preexisting way
to describe aggregation and sorting. The first (and possibly only) sort
step is still performed as a separate execution step. That retains
similarity with existing group by plans, makes rescans fairly simple,
avoids very deep plans (leading to slow explains) and easily allows to
avoid the sorting step if the underlying data is sorted by other means.
A somewhat ugly side of this patch is having to deal with a grammar
ambiguity between the new CUBE keyword and the cube extension/functions
named cube (and rollup). To avoid breaking existing deployments of the
cube extension it has not been renamed, neither has cube been made a
reserved keyword. Instead precedence hacking is used to make GROUP BY
cube(..) refer to the CUBE grouping sets feature, and not the function
cube(). To actually group by a function cube(), unlikely as that might
be, the function name has to be quoted.
Needs a catversion bump because stored rules may change.
Author: Andrew Gierth and Atri Sharma, with contributions from Andres Freund
Reviewed-By: Andres Freund, Noah Misch, Tom Lane, Svenne Krap, Tomas
Vondra, Erik Rijkers, Marti Raudsepp, Pavel Stehule
Discussion: CAOeZVidmVRe2jU6aMk_5qkxnB7dfmPROzM7Ur8JPW5j8Y5X-Lw@mail.gmail.com
2015-05-16 03:40:59 +02:00
|
|
|
| explicit_row
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
RowExpr *r = makeNode(RowExpr);
|
|
|
|
|
|
Support GROUPING SETS, CUBE and ROLLUP.
This SQL standard functionality allows to aggregate data by different
GROUP BY clauses at once. Each grouping set returns rows with columns
grouped by in other sets set to NULL.
This could previously be achieved by doing each grouping as a separate
query, conjoined by UNION ALLs. Besides being considerably more concise,
grouping sets will in many cases be faster, requiring only one scan over
the underlying data.
The current implementation of grouping sets only supports using sorting
for input. Individual sets that share a sort order are computed in one
pass. If there are sets that don't share a sort order, additional sort &
aggregation steps are performed. These additional passes are sourced by
the previous sort step; thus avoiding repeated scans of the source data.
The code is structured in a way that adding support for purely using
hash aggregation or a mix of hashing and sorting is possible. Sorting
was chosen to be supported first, as it is the most generic method of
implementation.
Instead of, as in an earlier versions of the patch, representing the
chain of sort and aggregation steps as full blown planner and executor
nodes, all but the first sort are performed inside the aggregation node
itself. This avoids the need to do some unusual gymnastics to handle
having to return aggregated and non-aggregated tuples from underlying
nodes, as well as having to shut down underlying nodes early to limit
memory usage. The optimizer still builds Sort/Agg node to describe each
phase, but they're not part of the plan tree, but instead additional
data for the aggregation node. They're a convenient and preexisting way
to describe aggregation and sorting. The first (and possibly only) sort
step is still performed as a separate execution step. That retains
similarity with existing group by plans, makes rescans fairly simple,
avoids very deep plans (leading to slow explains) and easily allows to
avoid the sorting step if the underlying data is sorted by other means.
A somewhat ugly side of this patch is having to deal with a grammar
ambiguity between the new CUBE keyword and the cube extension/functions
named cube (and rollup). To avoid breaking existing deployments of the
cube extension it has not been renamed, neither has cube been made a
reserved keyword. Instead precedence hacking is used to make GROUP BY
cube(..) refer to the CUBE grouping sets feature, and not the function
cube(). To actually group by a function cube(), unlikely as that might
be, the function name has to be quoted.
Needs a catversion bump because stored rules may change.
Author: Andrew Gierth and Atri Sharma, with contributions from Andres Freund
Reviewed-By: Andres Freund, Noah Misch, Tom Lane, Svenne Krap, Tomas
Vondra, Erik Rijkers, Marti Raudsepp, Pavel Stehule
Discussion: CAOeZVidmVRe2jU6aMk_5qkxnB7dfmPROzM7Ur8JPW5j8Y5X-Lw@mail.gmail.com
2015-05-16 03:40:59 +02:00
|
|
|
r->args = $1;
|
|
|
|
|
r->row_typeid = InvalidOid; /* not analyzed yet */
|
|
|
|
|
r->colnames = NIL; /* to be filled in during analysis */
|
|
|
|
|
r->row_format = COERCE_EXPLICIT_CALL; /* abuse */
|
|
|
|
|
r->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) r;
|
Support GROUPING SETS, CUBE and ROLLUP.
This SQL standard functionality allows to aggregate data by different
GROUP BY clauses at once. Each grouping set returns rows with columns
grouped by in other sets set to NULL.
This could previously be achieved by doing each grouping as a separate
query, conjoined by UNION ALLs. Besides being considerably more concise,
grouping sets will in many cases be faster, requiring only one scan over
the underlying data.
The current implementation of grouping sets only supports using sorting
for input. Individual sets that share a sort order are computed in one
pass. If there are sets that don't share a sort order, additional sort &
aggregation steps are performed. These additional passes are sourced by
the previous sort step; thus avoiding repeated scans of the source data.
The code is structured in a way that adding support for purely using
hash aggregation or a mix of hashing and sorting is possible. Sorting
was chosen to be supported first, as it is the most generic method of
implementation.
Instead of, as in an earlier versions of the patch, representing the
chain of sort and aggregation steps as full blown planner and executor
nodes, all but the first sort are performed inside the aggregation node
itself. This avoids the need to do some unusual gymnastics to handle
having to return aggregated and non-aggregated tuples from underlying
nodes, as well as having to shut down underlying nodes early to limit
memory usage. The optimizer still builds Sort/Agg node to describe each
phase, but they're not part of the plan tree, but instead additional
data for the aggregation node. They're a convenient and preexisting way
to describe aggregation and sorting. The first (and possibly only) sort
step is still performed as a separate execution step. That retains
similarity with existing group by plans, makes rescans fairly simple,
avoids very deep plans (leading to slow explains) and easily allows to
avoid the sorting step if the underlying data is sorted by other means.
A somewhat ugly side of this patch is having to deal with a grammar
ambiguity between the new CUBE keyword and the cube extension/functions
named cube (and rollup). To avoid breaking existing deployments of the
cube extension it has not been renamed, neither has cube been made a
reserved keyword. Instead precedence hacking is used to make GROUP BY
cube(..) refer to the CUBE grouping sets feature, and not the function
cube(). To actually group by a function cube(), unlikely as that might
be, the function name has to be quoted.
Needs a catversion bump because stored rules may change.
Author: Andrew Gierth and Atri Sharma, with contributions from Andres Freund
Reviewed-By: Andres Freund, Noah Misch, Tom Lane, Svenne Krap, Tomas
Vondra, Erik Rijkers, Marti Raudsepp, Pavel Stehule
Discussion: CAOeZVidmVRe2jU6aMk_5qkxnB7dfmPROzM7Ur8JPW5j8Y5X-Lw@mail.gmail.com
2015-05-16 03:40:59 +02:00
|
|
|
}
|
|
|
|
|
| implicit_row
|
2004-09-30 01:39:20 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
RowExpr *r = makeNode(RowExpr);
|
|
|
|
|
|
2004-09-30 01:39:20 +02:00
|
|
|
r->args = $1;
|
|
|
|
|
r->row_typeid = InvalidOid; /* not analyzed yet */
|
2012-02-14 23:34:19 +01:00
|
|
|
r->colnames = NIL; /* to be filled in during analysis */
|
Support GROUPING SETS, CUBE and ROLLUP.
This SQL standard functionality allows to aggregate data by different
GROUP BY clauses at once. Each grouping set returns rows with columns
grouped by in other sets set to NULL.
This could previously be achieved by doing each grouping as a separate
query, conjoined by UNION ALLs. Besides being considerably more concise,
grouping sets will in many cases be faster, requiring only one scan over
the underlying data.
The current implementation of grouping sets only supports using sorting
for input. Individual sets that share a sort order are computed in one
pass. If there are sets that don't share a sort order, additional sort &
aggregation steps are performed. These additional passes are sourced by
the previous sort step; thus avoiding repeated scans of the source data.
The code is structured in a way that adding support for purely using
hash aggregation or a mix of hashing and sorting is possible. Sorting
was chosen to be supported first, as it is the most generic method of
implementation.
Instead of, as in an earlier versions of the patch, representing the
chain of sort and aggregation steps as full blown planner and executor
nodes, all but the first sort are performed inside the aggregation node
itself. This avoids the need to do some unusual gymnastics to handle
having to return aggregated and non-aggregated tuples from underlying
nodes, as well as having to shut down underlying nodes early to limit
memory usage. The optimizer still builds Sort/Agg node to describe each
phase, but they're not part of the plan tree, but instead additional
data for the aggregation node. They're a convenient and preexisting way
to describe aggregation and sorting. The first (and possibly only) sort
step is still performed as a separate execution step. That retains
similarity with existing group by plans, makes rescans fairly simple,
avoids very deep plans (leading to slow explains) and easily allows to
avoid the sorting step if the underlying data is sorted by other means.
A somewhat ugly side of this patch is having to deal with a grammar
ambiguity between the new CUBE keyword and the cube extension/functions
named cube (and rollup). To avoid breaking existing deployments of the
cube extension it has not been renamed, neither has cube been made a
reserved keyword. Instead precedence hacking is used to make GROUP BY
cube(..) refer to the CUBE grouping sets feature, and not the function
cube(). To actually group by a function cube(), unlikely as that might
be, the function name has to be quoted.
Needs a catversion bump because stored rules may change.
Author: Andrew Gierth and Atri Sharma, with contributions from Andres Freund
Reviewed-By: Andres Freund, Noah Misch, Tom Lane, Svenne Krap, Tomas
Vondra, Erik Rijkers, Marti Raudsepp, Pavel Stehule
Discussion: CAOeZVidmVRe2jU6aMk_5qkxnB7dfmPROzM7Ur8JPW5j8Y5X-Lw@mail.gmail.com
2015-05-16 03:40:59 +02:00
|
|
|
r->row_format = COERCE_IMPLICIT_CAST; /* abuse */
|
2008-08-29 01:09:48 +02:00
|
|
|
r->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) r;
|
2004-09-30 01:39:20 +02:00
|
|
|
}
|
Support GROUPING SETS, CUBE and ROLLUP.
This SQL standard functionality allows to aggregate data by different
GROUP BY clauses at once. Each grouping set returns rows with columns
grouped by in other sets set to NULL.
This could previously be achieved by doing each grouping as a separate
query, conjoined by UNION ALLs. Besides being considerably more concise,
grouping sets will in many cases be faster, requiring only one scan over
the underlying data.
The current implementation of grouping sets only supports using sorting
for input. Individual sets that share a sort order are computed in one
pass. If there are sets that don't share a sort order, additional sort &
aggregation steps are performed. These additional passes are sourced by
the previous sort step; thus avoiding repeated scans of the source data.
The code is structured in a way that adding support for purely using
hash aggregation or a mix of hashing and sorting is possible. Sorting
was chosen to be supported first, as it is the most generic method of
implementation.
Instead of, as in an earlier versions of the patch, representing the
chain of sort and aggregation steps as full blown planner and executor
nodes, all but the first sort are performed inside the aggregation node
itself. This avoids the need to do some unusual gymnastics to handle
having to return aggregated and non-aggregated tuples from underlying
nodes, as well as having to shut down underlying nodes early to limit
memory usage. The optimizer still builds Sort/Agg node to describe each
phase, but they're not part of the plan tree, but instead additional
data for the aggregation node. They're a convenient and preexisting way
to describe aggregation and sorting. The first (and possibly only) sort
step is still performed as a separate execution step. That retains
similarity with existing group by plans, makes rescans fairly simple,
avoids very deep plans (leading to slow explains) and easily allows to
avoid the sorting step if the underlying data is sorted by other means.
A somewhat ugly side of this patch is having to deal with a grammar
ambiguity between the new CUBE keyword and the cube extension/functions
named cube (and rollup). To avoid breaking existing deployments of the
cube extension it has not been renamed, neither has cube been made a
reserved keyword. Instead precedence hacking is used to make GROUP BY
cube(..) refer to the CUBE grouping sets feature, and not the function
cube(). To actually group by a function cube(), unlikely as that might
be, the function name has to be quoted.
Needs a catversion bump because stored rules may change.
Author: Andrew Gierth and Atri Sharma, with contributions from Andres Freund
Reviewed-By: Andres Freund, Noah Misch, Tom Lane, Svenne Krap, Tomas
Vondra, Erik Rijkers, Marti Raudsepp, Pavel Stehule
Discussion: CAOeZVidmVRe2jU6aMk_5qkxnB7dfmPROzM7Ur8JPW5j8Y5X-Lw@mail.gmail.com
2015-05-16 03:40:59 +02:00
|
|
|
| GROUPING '(' expr_list ')'
|
|
|
|
|
{
|
|
|
|
|
GroupingFunc *g = makeNode(GroupingFunc);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Support GROUPING SETS, CUBE and ROLLUP.
This SQL standard functionality allows to aggregate data by different
GROUP BY clauses at once. Each grouping set returns rows with columns
grouped by in other sets set to NULL.
This could previously be achieved by doing each grouping as a separate
query, conjoined by UNION ALLs. Besides being considerably more concise,
grouping sets will in many cases be faster, requiring only one scan over
the underlying data.
The current implementation of grouping sets only supports using sorting
for input. Individual sets that share a sort order are computed in one
pass. If there are sets that don't share a sort order, additional sort &
aggregation steps are performed. These additional passes are sourced by
the previous sort step; thus avoiding repeated scans of the source data.
The code is structured in a way that adding support for purely using
hash aggregation or a mix of hashing and sorting is possible. Sorting
was chosen to be supported first, as it is the most generic method of
implementation.
Instead of, as in an earlier versions of the patch, representing the
chain of sort and aggregation steps as full blown planner and executor
nodes, all but the first sort are performed inside the aggregation node
itself. This avoids the need to do some unusual gymnastics to handle
having to return aggregated and non-aggregated tuples from underlying
nodes, as well as having to shut down underlying nodes early to limit
memory usage. The optimizer still builds Sort/Agg node to describe each
phase, but they're not part of the plan tree, but instead additional
data for the aggregation node. They're a convenient and preexisting way
to describe aggregation and sorting. The first (and possibly only) sort
step is still performed as a separate execution step. That retains
similarity with existing group by plans, makes rescans fairly simple,
avoids very deep plans (leading to slow explains) and easily allows to
avoid the sorting step if the underlying data is sorted by other means.
A somewhat ugly side of this patch is having to deal with a grammar
ambiguity between the new CUBE keyword and the cube extension/functions
named cube (and rollup). To avoid breaking existing deployments of the
cube extension it has not been renamed, neither has cube been made a
reserved keyword. Instead precedence hacking is used to make GROUP BY
cube(..) refer to the CUBE grouping sets feature, and not the function
cube(). To actually group by a function cube(), unlikely as that might
be, the function name has to be quoted.
Needs a catversion bump because stored rules may change.
Author: Andrew Gierth and Atri Sharma, with contributions from Andres Freund
Reviewed-By: Andres Freund, Noah Misch, Tom Lane, Svenne Krap, Tomas
Vondra, Erik Rijkers, Marti Raudsepp, Pavel Stehule
Discussion: CAOeZVidmVRe2jU6aMk_5qkxnB7dfmPROzM7Ur8JPW5j8Y5X-Lw@mail.gmail.com
2015-05-16 03:40:59 +02:00
|
|
|
g->args = $3;
|
|
|
|
|
g->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) g;
|
Support GROUPING SETS, CUBE and ROLLUP.
This SQL standard functionality allows to aggregate data by different
GROUP BY clauses at once. Each grouping set returns rows with columns
grouped by in other sets set to NULL.
This could previously be achieved by doing each grouping as a separate
query, conjoined by UNION ALLs. Besides being considerably more concise,
grouping sets will in many cases be faster, requiring only one scan over
the underlying data.
The current implementation of grouping sets only supports using sorting
for input. Individual sets that share a sort order are computed in one
pass. If there are sets that don't share a sort order, additional sort &
aggregation steps are performed. These additional passes are sourced by
the previous sort step; thus avoiding repeated scans of the source data.
The code is structured in a way that adding support for purely using
hash aggregation or a mix of hashing and sorting is possible. Sorting
was chosen to be supported first, as it is the most generic method of
implementation.
Instead of, as in an earlier versions of the patch, representing the
chain of sort and aggregation steps as full blown planner and executor
nodes, all but the first sort are performed inside the aggregation node
itself. This avoids the need to do some unusual gymnastics to handle
having to return aggregated and non-aggregated tuples from underlying
nodes, as well as having to shut down underlying nodes early to limit
memory usage. The optimizer still builds Sort/Agg node to describe each
phase, but they're not part of the plan tree, but instead additional
data for the aggregation node. They're a convenient and preexisting way
to describe aggregation and sorting. The first (and possibly only) sort
step is still performed as a separate execution step. That retains
similarity with existing group by plans, makes rescans fairly simple,
avoids very deep plans (leading to slow explains) and easily allows to
avoid the sorting step if the underlying data is sorted by other means.
A somewhat ugly side of this patch is having to deal with a grammar
ambiguity between the new CUBE keyword and the cube extension/functions
named cube (and rollup). To avoid breaking existing deployments of the
cube extension it has not been renamed, neither has cube been made a
reserved keyword. Instead precedence hacking is used to make GROUP BY
cube(..) refer to the CUBE grouping sets feature, and not the function
cube(). To actually group by a function cube(), unlikely as that might
be, the function name has to be quoted.
Needs a catversion bump because stored rules may change.
Author: Andrew Gierth and Atri Sharma, with contributions from Andres Freund
Reviewed-By: Andres Freund, Noah Misch, Tom Lane, Svenne Krap, Tomas
Vondra, Erik Rijkers, Marti Raudsepp, Pavel Stehule
Discussion: CAOeZVidmVRe2jU6aMk_5qkxnB7dfmPROzM7Ur8JPW5j8Y5X-Lw@mail.gmail.com
2015-05-16 03:40:59 +02:00
|
|
|
}
|
2004-09-30 01:39:20 +02:00
|
|
|
;
|
|
|
|
|
|
2013-06-28 16:18:00 +02:00
|
|
|
func_application: func_name '(' ')'
|
1998-02-04 07:11:48 +01:00
|
|
|
{
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
$$ = (Node *) makeFuncCall($1, NIL,
|
|
|
|
|
COERCE_EXPLICIT_CALL,
|
|
|
|
|
@1);
|
1998-02-04 07:11:48 +01:00
|
|
|
}
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
| func_name '(' func_arg_list opt_sort_clause ')'
|
1998-02-04 07:11:48 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
FuncCall *n = makeFuncCall($1, $3,
|
|
|
|
|
COERCE_EXPLICIT_CALL,
|
|
|
|
|
@1);
|
|
|
|
|
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
n->agg_order = $4;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2008-07-16 03:30:23 +02:00
|
|
|
}
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
| func_name '(' VARIADIC func_arg_expr opt_sort_clause ')'
|
2008-07-16 03:30:23 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
FuncCall *n = makeFuncCall($1, list_make1($4),
|
|
|
|
|
COERCE_EXPLICIT_CALL,
|
|
|
|
|
@1);
|
|
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
n->func_variadic = true;
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
n->agg_order = $5;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2008-07-16 03:30:23 +02:00
|
|
|
}
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
| func_name '(' func_arg_list ',' VARIADIC func_arg_expr opt_sort_clause ')'
|
2008-07-16 03:30:23 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
FuncCall *n = makeFuncCall($1, lappend($3, $6),
|
|
|
|
|
COERCE_EXPLICIT_CALL,
|
|
|
|
|
@1);
|
|
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
n->func_variadic = true;
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
n->agg_order = $7;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2009-12-15 18:57:48 +01:00
|
|
|
}
|
2013-06-28 16:18:00 +02:00
|
|
|
| func_name '(' ALL func_arg_list opt_sort_clause ')'
|
2000-02-19 20:37:21 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
FuncCall *n = makeFuncCall($1, $4,
|
|
|
|
|
COERCE_EXPLICIT_CALL,
|
|
|
|
|
@1);
|
|
|
|
|
|
2009-12-15 18:57:48 +01:00
|
|
|
n->agg_order = $5;
|
2000-02-19 20:37:21 +01:00
|
|
|
/* Ideally we'd mark the FuncCall node to indicate
|
|
|
|
|
* "must be an aggregate", but there's no provision
|
|
|
|
|
* for that in FuncCall at the moment.
|
|
|
|
|
*/
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2000-02-19 20:37:21 +01:00
|
|
|
}
|
2013-06-28 16:18:00 +02:00
|
|
|
| func_name '(' DISTINCT func_arg_list opt_sort_clause ')'
|
1999-12-10 08:37:35 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
FuncCall *n = makeFuncCall($1, $4,
|
|
|
|
|
COERCE_EXPLICIT_CALL,
|
|
|
|
|
@1);
|
|
|
|
|
|
2009-12-15 18:57:48 +01:00
|
|
|
n->agg_order = $5;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->agg_distinct = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1998-02-04 07:11:48 +01:00
|
|
|
}
|
2013-06-28 16:18:00 +02:00
|
|
|
| func_name '(' '*' ')'
|
1999-11-20 22:39:36 +01:00
|
|
|
{
|
|
|
|
|
/*
|
2006-07-27 21:52:07 +02:00
|
|
|
* We consider AGGREGATE(*) to invoke a parameterless
|
|
|
|
|
* aggregate. This does the right thing for COUNT(*),
|
2013-04-20 17:04:41 +02:00
|
|
|
* and there are no other aggregates in SQL that accept
|
1999-11-20 22:39:36 +01:00
|
|
|
* '*' as parameter.
|
|
|
|
|
*
|
1999-12-10 08:37:35 +01:00
|
|
|
* The FuncCall node is also marked agg_star = true,
|
|
|
|
|
* so that later processing can detect what the argument
|
|
|
|
|
* really was.
|
1999-11-20 22:39:36 +01:00
|
|
|
*/
|
2022-05-13 07:17:29 +02:00
|
|
|
FuncCall *n = makeFuncCall($1, NIL,
|
|
|
|
|
COERCE_EXPLICIT_CALL,
|
|
|
|
|
@1);
|
|
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
n->agg_star = true;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1999-11-20 22:39:36 +01:00
|
|
|
}
|
2013-11-10 15:20:52 +01:00
|
|
|
;
|
2013-06-28 16:18:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
* func_expr and its cousin func_expr_windowless are split out from c_expr just
|
2013-11-10 15:20:52 +01:00
|
|
|
* so that we have classifications for "everything that is a function call or
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
* looks like one". This isn't very important, but it saves us having to
|
|
|
|
|
* document which variants are legal in places like "FROM function()" or the
|
|
|
|
|
* backwards-compatible functional-index syntax for CREATE INDEX.
|
2013-06-28 16:18:00 +02:00
|
|
|
* (Note that many of the special SQL functions wouldn't actually make any
|
|
|
|
|
* sense as functional index entries, but we ignore that consideration here.)
|
|
|
|
|
*/
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
func_expr: func_application within_group_clause filter_clause over_clause
|
2013-06-28 16:18:00 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
FuncCall *n = (FuncCall *) $1;
|
|
|
|
|
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
/*
|
|
|
|
|
* The order clause for WITHIN GROUP and the one for
|
|
|
|
|
* plain-aggregate ORDER BY share a field, so we have to
|
|
|
|
|
* check here that at most one is present. We also check
|
|
|
|
|
* for DISTINCT and VARIADIC here to give a better error
|
|
|
|
|
* location. Other consistency checks are deferred to
|
|
|
|
|
* parse analysis.
|
|
|
|
|
*/
|
|
|
|
|
if ($2 != NIL)
|
|
|
|
|
{
|
|
|
|
|
if (n->agg_order != NIL)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("cannot use multiple ORDER BY clauses with WITHIN GROUP"),
|
|
|
|
|
parser_errposition(@2)));
|
|
|
|
|
if (n->agg_distinct)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("cannot use DISTINCT with WITHIN GROUP"),
|
|
|
|
|
parser_errposition(@2)));
|
|
|
|
|
if (n->func_variadic)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("cannot use VARIADIC with WITHIN GROUP"),
|
|
|
|
|
parser_errposition(@2)));
|
|
|
|
|
n->agg_order = $2;
|
2017-08-16 06:22:32 +02:00
|
|
|
n->agg_within_group = true;
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
}
|
|
|
|
|
n->agg_filter = $3;
|
|
|
|
|
n->over = $4;
|
|
|
|
|
$$ = (Node *) n;
|
2013-11-10 15:20:52 +01:00
|
|
|
}
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
| json_aggregate_func filter_clause over_clause
|
|
|
|
|
{
|
|
|
|
|
JsonAggConstructor *n = IsA($1, JsonObjectAgg) ?
|
|
|
|
|
((JsonObjectAgg *) $1)->constructor :
|
|
|
|
|
((JsonArrayAgg *) $1)->constructor;
|
|
|
|
|
|
|
|
|
|
n->agg_filter = $2;
|
|
|
|
|
n->over = $3;
|
|
|
|
|
$$ = (Node *) $1;
|
|
|
|
|
}
|
2013-06-28 16:18:00 +02:00
|
|
|
| func_expr_common_subexpr
|
|
|
|
|
{ $$ = $1; }
|
|
|
|
|
;
|
|
|
|
|
|
2013-11-10 15:20:52 +01:00
|
|
|
/*
|
2014-01-21 22:34:28 +01:00
|
|
|
* As func_expr but does not accept WINDOW functions directly
|
|
|
|
|
* (but they can still be contained in arguments for functions etc).
|
|
|
|
|
* Use this when window expressions are not allowed, where needed to
|
|
|
|
|
* disambiguate the grammar (e.g. in CREATE INDEX).
|
2013-06-28 16:18:00 +02:00
|
|
|
*/
|
2013-11-10 15:20:52 +01:00
|
|
|
func_expr_windowless:
|
2013-06-28 16:18:00 +02:00
|
|
|
func_application { $$ = $1; }
|
2013-11-10 15:20:52 +01:00
|
|
|
| func_expr_common_subexpr { $$ = $1; }
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
| json_aggregate_func { $$ = $1; }
|
2013-06-28 16:18:00 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/*
|
2014-01-21 22:34:28 +01:00
|
|
|
* Special expressions that are considered to be functions.
|
2013-06-28 16:18:00 +02:00
|
|
|
*/
|
2013-11-10 15:20:52 +01:00
|
|
|
func_expr_common_subexpr:
|
2013-06-28 16:18:00 +02:00
|
|
|
COLLATION FOR '(' a_expr ')'
|
2012-03-02 20:12:16 +01:00
|
|
|
{
|
2013-07-01 20:41:33 +02:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("pg_collation_for"),
|
|
|
|
|
list_make1($4),
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
COERCE_SQL_SYNTAX,
|
2013-07-01 20:41:33 +02:00
|
|
|
@1);
|
2012-03-02 20:12:16 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| CURRENT_DATE
|
1998-02-04 07:11:48 +01:00
|
|
|
{
|
2022-11-21 10:31:59 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("current_date"),
|
|
|
|
|
NIL,
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
1998-02-04 07:11:48 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| CURRENT_TIME
|
1998-02-04 07:11:48 +01:00
|
|
|
{
|
2022-11-21 10:31:59 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("current_time"),
|
|
|
|
|
NIL,
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
1998-02-04 07:11:48 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| CURRENT_TIME '(' Iconst ')'
|
1998-02-04 07:11:48 +01:00
|
|
|
{
|
2022-11-21 10:31:59 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("current_time"),
|
|
|
|
|
list_make1(makeIntConst($3, @3)),
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
1998-02-04 07:11:48 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| CURRENT_TIMESTAMP
|
1998-02-04 07:11:48 +01:00
|
|
|
{
|
2022-11-21 10:31:59 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("current_timestamp"),
|
|
|
|
|
NIL,
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
1998-02-04 07:11:48 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| CURRENT_TIMESTAMP '(' Iconst ')'
|
1998-02-04 07:11:48 +01:00
|
|
|
{
|
2022-11-21 10:31:59 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("current_timestamp"),
|
|
|
|
|
list_make1(makeIntConst($3, @3)),
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
1998-02-04 07:11:48 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| LOCALTIME
|
2002-06-15 05:00:09 +02:00
|
|
|
{
|
2022-11-21 10:31:59 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("localtime"),
|
|
|
|
|
NIL,
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
2002-06-15 05:00:09 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| LOCALTIME '(' Iconst ')'
|
2002-06-15 05:00:09 +02:00
|
|
|
{
|
2022-11-21 10:31:59 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("localtime"),
|
|
|
|
|
list_make1(makeIntConst($3, @3)),
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
2002-06-15 05:00:09 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| LOCALTIMESTAMP
|
2002-06-15 05:00:09 +02:00
|
|
|
{
|
2022-11-21 10:31:59 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("localtimestamp"),
|
|
|
|
|
NIL,
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
2002-06-15 05:00:09 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| LOCALTIMESTAMP '(' Iconst ')'
|
2002-06-15 05:00:09 +02:00
|
|
|
{
|
2022-11-21 10:31:59 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("localtimestamp"),
|
|
|
|
|
list_make1(makeIntConst($3, @3)),
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
2002-06-15 05:00:09 +02:00
|
|
|
}
|
2005-06-28 07:09:14 +02:00
|
|
|
| CURRENT_ROLE
|
|
|
|
|
{
|
2022-11-20 02:58:28 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("current_role"),
|
|
|
|
|
NIL,
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
2005-06-28 07:09:14 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| CURRENT_USER
|
1998-02-04 07:11:48 +01:00
|
|
|
{
|
2022-11-20 02:58:28 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("current_user"),
|
|
|
|
|
NIL,
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
1998-02-04 07:11:48 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| SESSION_USER
|
2000-02-15 04:26:38 +01:00
|
|
|
{
|
2022-11-20 02:58:28 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("session_user"),
|
|
|
|
|
NIL,
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
2000-02-15 04:26:38 +01:00
|
|
|
}
|
Introduce SYSTEM_USER
SYSTEM_USER is a reserved keyword of the SQL specification that,
roughly described, is aimed at reporting some information about the
system user who has connected to the database server. It may include
implementation-specific information about the means by the user
connected, like an authentication method.
This commit implements SYSTEM_USER as of auth_method:identity, where
"auth_method" is a keyword about the authentication method used to log
into the server (like peer, md5, scram-sha-256, gss, etc.) and
"identity" is the authentication identity as introduced by 9afffcb (peer
sets authn to the OS user name, gss to the user principal, etc.). This
format has been suggested by Tom Lane.
Note that thanks to d951052, SYSTEM_USER is available to parallel
workers.
Bump catalog version.
Author: Bertrand Drouvot
Reviewed-by: Jacob Champion, Joe Conway, Álvaro Herrera, Michael Paquier
Discussion: https://postgr.es/m/7e692b8c-0b11-45db-1cad-3afc5b57409f@amazon.com
2022-09-29 08:05:40 +02:00
|
|
|
| SYSTEM_USER
|
|
|
|
|
{
|
|
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("system_user"),
|
|
|
|
|
NIL,
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
|
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| USER
|
1998-05-10 01:22:15 +02:00
|
|
|
{
|
2022-11-20 02:58:28 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("user"),
|
|
|
|
|
NIL,
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
1998-05-10 01:22:15 +02:00
|
|
|
}
|
2008-10-27 10:37:47 +01:00
|
|
|
| CURRENT_CATALOG
|
|
|
|
|
{
|
2022-11-20 02:58:28 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("current_catalog"),
|
|
|
|
|
NIL,
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
2008-10-27 10:37:47 +01:00
|
|
|
}
|
|
|
|
|
| CURRENT_SCHEMA
|
|
|
|
|
{
|
2022-11-20 02:58:28 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("current_schema"),
|
|
|
|
|
NIL,
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
2008-10-27 10:37:47 +01:00
|
|
|
}
|
2002-07-04 17:24:11 +02:00
|
|
|
| CAST '(' a_expr AS Typename ')'
|
2008-08-29 01:09:48 +02:00
|
|
|
{ $$ = makeTypeCast($3, $5, @1); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| EXTRACT '(' extract_list ')'
|
1999-11-20 22:39:36 +01:00
|
|
|
{
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("extract"),
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
$3,
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
1999-11-20 22:39:36 +01:00
|
|
|
}
|
2020-03-26 08:14:00 +01:00
|
|
|
| NORMALIZE '(' a_expr ')'
|
|
|
|
|
{
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("normalize"),
|
|
|
|
|
list_make1($3),
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
2020-03-26 08:14:00 +01:00
|
|
|
}
|
|
|
|
|
| NORMALIZE '(' a_expr ',' unicode_normal_form ')'
|
|
|
|
|
{
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("normalize"),
|
|
|
|
|
list_make2($3, makeStringConst($5, @5)),
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
2020-03-26 08:14:00 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| OVERLAY '(' overlay_list ')'
|
2002-06-11 17:44:38 +02:00
|
|
|
{
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("overlay"),
|
|
|
|
|
$3,
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
|
|
|
|
}
|
|
|
|
|
| OVERLAY '(' func_arg_list_opt ')'
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* allow functions named overlay() to be called without
|
|
|
|
|
* special syntax
|
|
|
|
|
*/
|
|
|
|
|
$$ = (Node *) makeFuncCall(list_make1(makeString("overlay")),
|
|
|
|
|
$3,
|
|
|
|
|
COERCE_EXPLICIT_CALL,
|
|
|
|
|
@1);
|
2002-06-11 17:44:38 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| POSITION '(' position_list ')'
|
1998-02-04 07:11:48 +01:00
|
|
|
{
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
/*
|
|
|
|
|
* position(A in B) is converted to position(B, A)
|
|
|
|
|
*
|
|
|
|
|
* We deliberately don't offer a "plain syntax" option
|
|
|
|
|
* for position(), because the reversal of the arguments
|
|
|
|
|
* creates too much risk of confusion.
|
|
|
|
|
*/
|
|
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("position"),
|
|
|
|
|
$3,
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
1998-02-04 07:11:48 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| SUBSTRING '(' substr_list ')'
|
1998-02-04 07:11:48 +01:00
|
|
|
{
|
2000-10-31 11:22:13 +01:00
|
|
|
/* substring(A from B for C) is converted to
|
2000-12-03 15:51:12 +01:00
|
|
|
* substring(A, B, C) - thomas 2000-11-28
|
|
|
|
|
*/
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("substring"),
|
|
|
|
|
$3,
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
|
|
|
|
}
|
|
|
|
|
| SUBSTRING '(' func_arg_list_opt ')'
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* allow functions named substring() to be called without
|
|
|
|
|
* special syntax
|
|
|
|
|
*/
|
|
|
|
|
$$ = (Node *) makeFuncCall(list_make1(makeString("substring")),
|
|
|
|
|
$3,
|
|
|
|
|
COERCE_EXPLICIT_CALL,
|
|
|
|
|
@1);
|
1998-02-04 07:11:48 +01:00
|
|
|
}
|
2002-07-04 17:24:11 +02:00
|
|
|
| TREAT '(' a_expr AS Typename ')'
|
|
|
|
|
{
|
|
|
|
|
/* TREAT(expr AS target) converts expr of a particular type to target,
|
|
|
|
|
* which is defined to be a subtype of the original expression.
|
|
|
|
|
* In SQL99, this is intended for use with structured UDTs,
|
|
|
|
|
* but let's make this a generally useful form allowing stronger
|
2006-03-14 23:48:25 +01:00
|
|
|
* coercions than are handled by implicit casting.
|
2013-07-01 20:41:33 +02:00
|
|
|
*
|
|
|
|
|
* Convert SystemTypeName() to SystemFuncName() even though
|
2002-07-04 17:24:11 +02:00
|
|
|
* at the moment they result in the same thing.
|
|
|
|
|
*/
|
2020-12-03 11:35:20 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName(strVal(llast($5->names))),
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
list_make1($3),
|
|
|
|
|
COERCE_EXPLICIT_CALL,
|
|
|
|
|
@1);
|
2002-07-04 17:24:11 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| TRIM '(' BOTH trim_list ')'
|
1998-02-04 07:11:48 +01:00
|
|
|
{
|
2013-04-20 17:04:41 +02:00
|
|
|
/* various trim expressions are defined in SQL
|
2000-12-03 15:51:12 +01:00
|
|
|
* - thomas 1997-07-19
|
|
|
|
|
*/
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("btrim"),
|
|
|
|
|
$4,
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
1998-02-04 07:11:48 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| TRIM '(' LEADING trim_list ')'
|
1998-02-04 07:11:48 +01:00
|
|
|
{
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("ltrim"),
|
|
|
|
|
$4,
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
1998-02-04 07:11:48 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| TRIM '(' TRAILING trim_list ')'
|
1998-02-04 07:11:48 +01:00
|
|
|
{
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("rtrim"),
|
|
|
|
|
$4,
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
1998-02-04 07:11:48 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| TRIM '(' trim_list ')'
|
1998-02-04 07:11:48 +01:00
|
|
|
{
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("btrim"),
|
|
|
|
|
$3,
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
1998-02-04 07:11:48 +01:00
|
|
|
}
|
2004-09-30 02:24:27 +02:00
|
|
|
| NULLIF '(' a_expr ',' a_expr ')'
|
|
|
|
|
{
|
2006-03-14 23:48:25 +01:00
|
|
|
$$ = (Node *) makeSimpleA_Expr(AEXPR_NULLIF, "=", $3, $5, @1);
|
2004-09-30 02:24:27 +02:00
|
|
|
}
|
|
|
|
|
| COALESCE '(' expr_list ')'
|
|
|
|
|
{
|
|
|
|
|
CoalesceExpr *c = makeNode(CoalesceExpr);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2004-09-30 02:24:27 +02:00
|
|
|
c->args = $3;
|
2008-08-29 01:09:48 +02:00
|
|
|
c->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) c;
|
2004-09-30 02:24:27 +02:00
|
|
|
}
|
2005-06-27 00:05:42 +02:00
|
|
|
| GREATEST '(' expr_list ')'
|
|
|
|
|
{
|
|
|
|
|
MinMaxExpr *v = makeNode(MinMaxExpr);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-06-27 00:05:42 +02:00
|
|
|
v->args = $3;
|
|
|
|
|
v->op = IS_GREATEST;
|
2008-08-29 01:09:48 +02:00
|
|
|
v->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) v;
|
2005-06-27 00:05:42 +02:00
|
|
|
}
|
|
|
|
|
| LEAST '(' expr_list ')'
|
|
|
|
|
{
|
|
|
|
|
MinMaxExpr *v = makeNode(MinMaxExpr);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2005-06-27 00:05:42 +02:00
|
|
|
v->args = $3;
|
|
|
|
|
v->op = IS_LEAST;
|
2008-08-29 01:09:48 +02:00
|
|
|
v->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) v;
|
2005-06-27 00:05:42 +02:00
|
|
|
}
|
2006-12-21 17:05:16 +01:00
|
|
|
| XMLCONCAT '(' expr_list ')'
|
2006-12-30 22:21:56 +01:00
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeXmlExpr(IS_XMLCONCAT, NULL, NIL, $3, @1);
|
2006-12-21 17:05:16 +01:00
|
|
|
}
|
2006-12-24 01:29:20 +01:00
|
|
|
| XMLELEMENT '(' NAME_P ColLabel ')'
|
2006-12-21 17:05:16 +01:00
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeXmlExpr(IS_XMLELEMENT, $4, NIL, NIL, @1);
|
2006-12-21 17:05:16 +01:00
|
|
|
}
|
2006-12-24 01:29:20 +01:00
|
|
|
| XMLELEMENT '(' NAME_P ColLabel ',' xml_attributes ')'
|
2006-12-21 17:05:16 +01:00
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeXmlExpr(IS_XMLELEMENT, $4, $6, NIL, @1);
|
2006-12-21 17:05:16 +01:00
|
|
|
}
|
2006-12-24 01:29:20 +01:00
|
|
|
| XMLELEMENT '(' NAME_P ColLabel ',' expr_list ')'
|
2006-12-21 17:05:16 +01:00
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeXmlExpr(IS_XMLELEMENT, $4, NIL, $6, @1);
|
2006-12-21 17:05:16 +01:00
|
|
|
}
|
2006-12-24 01:29:20 +01:00
|
|
|
| XMLELEMENT '(' NAME_P ColLabel ',' xml_attributes ',' expr_list ')'
|
2006-12-21 17:05:16 +01:00
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeXmlExpr(IS_XMLELEMENT, $4, $6, $8, @1);
|
2006-12-21 17:05:16 +01:00
|
|
|
}
|
2010-08-05 06:21:54 +02:00
|
|
|
| XMLEXISTS '(' c_expr xmlexists_argument ')'
|
|
|
|
|
{
|
|
|
|
|
/* xmlexists(A PASSING [BY REF] B [BY REF]) is
|
|
|
|
|
* converted to xmlexists(A, B)*/
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("xmlexists"),
|
|
|
|
|
list_make2($3, $4),
|
|
|
|
|
COERCE_SQL_SYNTAX,
|
|
|
|
|
@1);
|
2010-08-05 06:21:54 +02:00
|
|
|
}
|
2006-12-21 17:05:16 +01:00
|
|
|
| XMLFOREST '(' xml_attribute_list ')'
|
|
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeXmlExpr(IS_XMLFOREST, NULL, $3, NIL, @1);
|
2006-12-21 17:05:16 +01:00
|
|
|
}
|
|
|
|
|
| XMLPARSE '(' document_or_content a_expr xml_whitespace_option ')'
|
|
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
XmlExpr *x = (XmlExpr *)
|
|
|
|
|
makeXmlExpr(IS_XMLPARSE, NULL, NIL,
|
|
|
|
|
list_make2($4, makeBoolAConst($5, -1)),
|
|
|
|
|
@1);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-02-03 15:06:56 +01:00
|
|
|
x->xmloption = $3;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) x;
|
2006-12-21 17:05:16 +01:00
|
|
|
}
|
2006-12-24 01:29:20 +01:00
|
|
|
| XMLPI '(' NAME_P ColLabel ')'
|
2006-12-21 17:05:16 +01:00
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeXmlExpr(IS_XMLPI, $4, NULL, NIL, @1);
|
2006-12-21 17:05:16 +01:00
|
|
|
}
|
2006-12-24 01:29:20 +01:00
|
|
|
| XMLPI '(' NAME_P ColLabel ',' a_expr ')'
|
2006-12-21 17:05:16 +01:00
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeXmlExpr(IS_XMLPI, $4, NULL, list_make1($6), @1);
|
2006-12-21 17:05:16 +01:00
|
|
|
}
|
|
|
|
|
| XMLROOT '(' a_expr ',' xml_root_version opt_xml_root_standalone ')'
|
|
|
|
|
{
|
2006-12-24 01:29:20 +01:00
|
|
|
$$ = makeXmlExpr(IS_XMLROOT, NULL, NIL,
|
2008-08-29 01:09:48 +02:00
|
|
|
list_make3($3, $5, $6), @1);
|
2006-12-21 17:05:16 +01:00
|
|
|
}
|
2023-03-15 21:58:59 +01:00
|
|
|
| XMLSERIALIZE '(' document_or_content a_expr AS SimpleTypename xml_indent_option ')'
|
2006-12-21 17:05:16 +01:00
|
|
|
{
|
2007-02-03 15:06:56 +01:00
|
|
|
XmlSerialize *n = makeNode(XmlSerialize);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2007-02-03 15:06:56 +01:00
|
|
|
n->xmloption = $3;
|
|
|
|
|
n->expr = $4;
|
2009-07-16 08:33:46 +02:00
|
|
|
n->typeName = $6;
|
2023-03-15 21:58:59 +01:00
|
|
|
n->indent = $7;
|
2008-08-29 01:09:48 +02:00
|
|
|
n->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
2006-12-21 17:05:16 +01:00
|
|
|
}
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
| JSON_OBJECT '(' func_arg_list ')'
|
|
|
|
|
{
|
|
|
|
|
/* Support for legacy (non-standard) json_object() */
|
|
|
|
|
$$ = (Node *) makeFuncCall(SystemFuncName("json_object"),
|
|
|
|
|
$3, COERCE_EXPLICIT_CALL, @1);
|
|
|
|
|
}
|
|
|
|
|
| JSON_OBJECT '(' json_name_and_value_list
|
|
|
|
|
json_object_constructor_null_clause_opt
|
|
|
|
|
json_key_uniqueness_constraint_opt
|
|
|
|
|
json_output_clause_opt ')'
|
|
|
|
|
{
|
|
|
|
|
JsonObjectConstructor *n = makeNode(JsonObjectConstructor);
|
|
|
|
|
|
|
|
|
|
n->exprs = $3;
|
|
|
|
|
n->absent_on_null = $4;
|
|
|
|
|
n->unique = $5;
|
|
|
|
|
n->output = (JsonOutput *) $6;
|
|
|
|
|
n->location = @1;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| JSON_OBJECT '(' json_output_clause_opt ')'
|
|
|
|
|
{
|
|
|
|
|
JsonObjectConstructor *n = makeNode(JsonObjectConstructor);
|
|
|
|
|
|
|
|
|
|
n->exprs = NULL;
|
|
|
|
|
n->absent_on_null = false;
|
|
|
|
|
n->unique = false;
|
|
|
|
|
n->output = (JsonOutput *) $3;
|
|
|
|
|
n->location = @1;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| JSON_ARRAY '('
|
|
|
|
|
json_value_expr_list
|
|
|
|
|
json_array_constructor_null_clause_opt
|
|
|
|
|
json_output_clause_opt
|
|
|
|
|
')'
|
|
|
|
|
{
|
|
|
|
|
JsonArrayConstructor *n = makeNode(JsonArrayConstructor);
|
|
|
|
|
|
|
|
|
|
n->exprs = $3;
|
|
|
|
|
n->absent_on_null = $4;
|
|
|
|
|
n->output = (JsonOutput *) $5;
|
|
|
|
|
n->location = @1;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| JSON_ARRAY '('
|
|
|
|
|
select_no_parens
|
|
|
|
|
json_format_clause_opt
|
|
|
|
|
/* json_array_constructor_null_clause_opt */
|
|
|
|
|
json_output_clause_opt
|
|
|
|
|
')'
|
|
|
|
|
{
|
|
|
|
|
JsonArrayQueryConstructor *n = makeNode(JsonArrayQueryConstructor);
|
|
|
|
|
|
|
|
|
|
n->query = $3;
|
|
|
|
|
n->format = (JsonFormat *) $4;
|
|
|
|
|
n->absent_on_null = true; /* XXX */
|
|
|
|
|
n->output = (JsonOutput *) $5;
|
|
|
|
|
n->location = @1;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| JSON_ARRAY '('
|
|
|
|
|
json_output_clause_opt
|
|
|
|
|
')'
|
|
|
|
|
{
|
|
|
|
|
JsonArrayConstructor *n = makeNode(JsonArrayConstructor);
|
|
|
|
|
|
|
|
|
|
n->exprs = NIL;
|
|
|
|
|
n->absent_on_null = true;
|
|
|
|
|
n->output = (JsonOutput *) $3;
|
|
|
|
|
n->location = @1;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
2006-12-21 17:05:16 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* SQL/XML support
|
|
|
|
|
*/
|
2006-12-24 01:29:20 +01:00
|
|
|
xml_root_version: VERSION_P a_expr
|
|
|
|
|
{ $$ = $2; }
|
|
|
|
|
| VERSION_P NO VALUE_P
|
2008-08-29 01:09:48 +02:00
|
|
|
{ $$ = makeNullAConst(-1); }
|
2006-12-21 17:05:16 +01:00
|
|
|
;
|
|
|
|
|
|
2006-12-24 01:29:20 +01:00
|
|
|
opt_xml_root_standalone: ',' STANDALONE_P YES_P
|
2008-08-29 01:09:48 +02:00
|
|
|
{ $$ = makeIntConst(XML_STANDALONE_YES, -1); }
|
2006-12-24 01:29:20 +01:00
|
|
|
| ',' STANDALONE_P NO
|
2008-08-29 01:09:48 +02:00
|
|
|
{ $$ = makeIntConst(XML_STANDALONE_NO, -1); }
|
2006-12-24 01:29:20 +01:00
|
|
|
| ',' STANDALONE_P NO VALUE_P
|
2008-08-29 01:09:48 +02:00
|
|
|
{ $$ = makeIntConst(XML_STANDALONE_NO_VALUE, -1); }
|
2006-12-24 01:29:20 +01:00
|
|
|
| /*EMPTY*/
|
2008-08-29 01:09:48 +02:00
|
|
|
{ $$ = makeIntConst(XML_STANDALONE_OMITTED, -1); }
|
2006-12-21 17:05:16 +01:00
|
|
|
;
|
|
|
|
|
|
2006-12-24 01:29:20 +01:00
|
|
|
xml_attributes: XMLATTRIBUTES '(' xml_attribute_list ')' { $$ = $3; }
|
2006-12-21 17:05:16 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
xml_attribute_list: xml_attribute_el { $$ = list_make1($1); }
|
|
|
|
|
| xml_attribute_list ',' xml_attribute_el { $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
xml_attribute_el: a_expr AS ColLabel
|
|
|
|
|
{
|
|
|
|
|
$$ = makeNode(ResTarget);
|
|
|
|
|
$$->name = $3;
|
2008-08-30 03:39:14 +02:00
|
|
|
$$->indirection = NIL;
|
2006-12-21 17:05:16 +01:00
|
|
|
$$->val = (Node *) $1;
|
2006-12-24 01:29:20 +01:00
|
|
|
$$->location = @1;
|
2006-12-21 17:05:16 +01:00
|
|
|
}
|
|
|
|
|
| a_expr
|
|
|
|
|
{
|
|
|
|
|
$$ = makeNode(ResTarget);
|
|
|
|
|
$$->name = NULL;
|
2008-08-30 03:39:14 +02:00
|
|
|
$$->indirection = NIL;
|
2006-12-30 22:21:56 +01:00
|
|
|
$$->val = (Node *) $1;
|
2006-12-24 01:29:20 +01:00
|
|
|
$$->location = @1;
|
2006-12-21 17:05:16 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2007-02-03 15:06:56 +01:00
|
|
|
document_or_content: DOCUMENT_P { $$ = XMLOPTION_DOCUMENT; }
|
|
|
|
|
| CONTENT_P { $$ = XMLOPTION_CONTENT; }
|
2006-12-21 17:05:16 +01:00
|
|
|
;
|
|
|
|
|
|
2023-03-15 21:58:59 +01:00
|
|
|
xml_indent_option: INDENT { $$ = true; }
|
|
|
|
|
| NO INDENT { $$ = false; }
|
|
|
|
|
| /*EMPTY*/ { $$ = false; }
|
|
|
|
|
;
|
|
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
xml_whitespace_option: PRESERVE WHITESPACE_P { $$ = true; }
|
|
|
|
|
| STRIP_P WHITESPACE_P { $$ = false; }
|
|
|
|
|
| /*EMPTY*/ { $$ = false; }
|
1998-02-04 07:11:48 +01:00
|
|
|
;
|
|
|
|
|
|
2010-08-05 06:21:54 +02:00
|
|
|
/* We allow several variants for SQL and other compatibility. */
|
|
|
|
|
xmlexists_argument:
|
|
|
|
|
PASSING c_expr
|
|
|
|
|
{
|
|
|
|
|
$$ = $2;
|
|
|
|
|
}
|
2019-03-07 15:17:09 +01:00
|
|
|
| PASSING c_expr xml_passing_mech
|
2010-08-05 06:21:54 +02:00
|
|
|
{
|
|
|
|
|
$$ = $2;
|
|
|
|
|
}
|
2019-03-07 15:17:09 +01:00
|
|
|
| PASSING xml_passing_mech c_expr
|
2010-08-05 06:21:54 +02:00
|
|
|
{
|
2019-03-07 15:17:09 +01:00
|
|
|
$$ = $3;
|
2010-08-05 06:21:54 +02:00
|
|
|
}
|
2019-03-07 15:17:09 +01:00
|
|
|
| PASSING xml_passing_mech c_expr xml_passing_mech
|
2010-08-05 06:21:54 +02:00
|
|
|
{
|
2019-03-07 15:17:09 +01:00
|
|
|
$$ = $3;
|
2010-08-05 06:21:54 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2019-03-07 15:17:09 +01:00
|
|
|
xml_passing_mech:
|
Rename parser token REF to REF_P to avoid a symbol conflict.
In the latest version of Apple's macOS SDK, <sys/socket.h>
fails to compile if "REF" is #define'd as something.
Apple may or may not agree that this is a bug, and even if
they do accept the bug report I filed, they probably won't
fix it very quickly. In the meantime, our back branches will all
fail to compile gram.y. v15 and HEAD currently escape the problem
thanks to the refactoring done in 98e93a1fc, but that's purely
accidental. Moreover, since that patch removed a widely-visible
inclusion of <netdb.h>, back-patching it seems too likely to break
third-party code.
Instead, change the token's code name to REF_P, following our usual
convention for naming parser tokens that are likely to have symbol
conflicts. The effects of that should be localized to the grammar
and immediately surrounding files, so it seems like a safer answer.
Per project policy that we want to keep recently-out-of-support
branches buildable on modern systems, back-patch all the way to 9.2.
Discussion: https://postgr.es/m/1803927.1665938411@sss.pgh.pa.us
2022-10-16 21:27:04 +02:00
|
|
|
BY REF_P
|
2019-03-07 15:17:09 +01:00
|
|
|
| BY VALUE_P
|
|
|
|
|
;
|
|
|
|
|
|
2010-08-05 06:21:54 +02:00
|
|
|
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
/*
|
|
|
|
|
* Aggregate decoration clauses
|
|
|
|
|
*/
|
|
|
|
|
within_group_clause:
|
|
|
|
|
WITHIN GROUP_P '(' sort_clause ')' { $$ = $4; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
filter_clause:
|
|
|
|
|
FILTER '(' WHERE a_expr ')' { $$ = $4; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
2008-12-28 19:54:01 +01:00
|
|
|
/*
|
|
|
|
|
* Window Definitions
|
|
|
|
|
*/
|
|
|
|
|
window_clause:
|
|
|
|
|
WINDOW window_definition_list { $$ = $2; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
window_definition_list:
|
|
|
|
|
window_definition { $$ = list_make1($1); }
|
|
|
|
|
| window_definition_list ',' window_definition
|
|
|
|
|
{ $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
window_definition:
|
|
|
|
|
ColId AS window_specification
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
WindowDef *n = $3;
|
|
|
|
|
|
2008-12-28 19:54:01 +01:00
|
|
|
n->name = $1;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
over_clause: OVER window_specification
|
|
|
|
|
{ $$ = $2; }
|
|
|
|
|
| OVER ColId
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
WindowDef *n = makeNode(WindowDef);
|
|
|
|
|
|
2008-12-31 01:08:39 +01:00
|
|
|
n->name = $2;
|
|
|
|
|
n->refname = NULL;
|
2008-12-28 19:54:01 +01:00
|
|
|
n->partitionClause = NIL;
|
|
|
|
|
n->orderClause = NIL;
|
2008-12-31 01:08:39 +01:00
|
|
|
n->frameOptions = FRAMEOPTION_DEFAULTS;
|
2010-02-12 18:33:21 +01:00
|
|
|
n->startOffset = NULL;
|
|
|
|
|
n->endOffset = NULL;
|
2008-12-28 19:54:01 +01:00
|
|
|
n->location = @2;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| /*EMPTY*/
|
|
|
|
|
{ $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
window_specification: '(' opt_existing_window_name opt_partition_clause
|
2008-12-31 01:08:39 +01:00
|
|
|
opt_sort_clause opt_frame_clause ')'
|
2008-12-28 19:54:01 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
WindowDef *n = makeNode(WindowDef);
|
|
|
|
|
|
2008-12-28 19:54:01 +01:00
|
|
|
n->name = NULL;
|
|
|
|
|
n->refname = $2;
|
|
|
|
|
n->partitionClause = $3;
|
|
|
|
|
n->orderClause = $4;
|
2010-02-12 18:33:21 +01:00
|
|
|
/* copy relevant fields of opt_frame_clause */
|
|
|
|
|
n->frameOptions = $5->frameOptions;
|
|
|
|
|
n->startOffset = $5->startOffset;
|
|
|
|
|
n->endOffset = $5->endOffset;
|
2008-12-28 19:54:01 +01:00
|
|
|
n->location = @1;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/*
|
Support all SQL:2011 options for window frame clauses.
This patch adds the ability to use "RANGE offset PRECEDING/FOLLOWING"
frame boundaries in window functions. We'd punted on that back in the
original patch to add window functions, because it was not clear how to
do it in a reasonably data-type-extensible fashion. That problem is
resolved here by adding the ability for btree operator classes to provide
an "in_range" support function that defines how to add or subtract the
RANGE offset value. Factoring it this way also allows the operator class
to avoid overflow problems near the ends of the datatype's range, if it
wishes to expend effort on that. (In the committed patch, the integer
opclasses handle that issue, but it did not seem worth the trouble to
avoid overflow failures for datetime types.)
The patch includes in_range support for the integer_ops opfamily
(int2/int4/int8) as well as the standard datetime types. Support for
other numeric types has been requested, but that seems like suitable
material for a follow-on patch.
In addition, the patch adds GROUPS mode which counts the offset in
ORDER-BY peer groups rather than rows, and it adds the frame_exclusion
options specified by SQL:2011. As far as I can see, we are now fully
up to spec on window framing options.
Existing behaviors remain unchanged, except that I changed the errcode
for a couple of existing error reports to meet the SQL spec's expectation
that negative "offset" values should be reported as SQLSTATE 22013.
Internally and in relevant parts of the documentation, we now consistently
use the terminology "offset PRECEDING/FOLLOWING" rather than "value
PRECEDING/FOLLOWING", since the term "value" is confusingly vague.
Oliver Ford, reviewed and whacked around some by me
Discussion: https://postgr.es/m/CAGMVOdu9sivPAxbNN0X+q19Sfv9edEPv=HibOJhB14TJv_RCQg@mail.gmail.com
2018-02-07 06:06:50 +01:00
|
|
|
* If we see PARTITION, RANGE, ROWS or GROUPS as the first token after the '('
|
2008-12-28 19:54:01 +01:00
|
|
|
* of a window_specification, we want the assumption to be that there is
|
|
|
|
|
* no existing_window_name; but those keywords are unreserved and so could
|
|
|
|
|
* be ColIds. We fix this by making them have the same precedence as IDENT
|
|
|
|
|
* and giving the empty production here a slightly higher precedence, so
|
|
|
|
|
* that the shift/reduce conflict is resolved in favor of reducing the rule.
|
|
|
|
|
* These keywords are thus precluded from being an existing_window_name but
|
|
|
|
|
* are not reserved for any other purpose.
|
|
|
|
|
*/
|
|
|
|
|
opt_existing_window_name: ColId { $$ = $1; }
|
|
|
|
|
| /*EMPTY*/ %prec Op { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_partition_clause: PARTITION BY expr_list { $$ = $3; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
2008-12-31 01:08:39 +01:00
|
|
|
/*
|
2010-02-12 18:33:21 +01:00
|
|
|
* For frame clauses, we return a WindowDef, but only some fields are used:
|
|
|
|
|
* frameOptions, startOffset, and endOffset.
|
2008-12-31 01:08:39 +01:00
|
|
|
*/
|
|
|
|
|
opt_frame_clause:
|
Support all SQL:2011 options for window frame clauses.
This patch adds the ability to use "RANGE offset PRECEDING/FOLLOWING"
frame boundaries in window functions. We'd punted on that back in the
original patch to add window functions, because it was not clear how to
do it in a reasonably data-type-extensible fashion. That problem is
resolved here by adding the ability for btree operator classes to provide
an "in_range" support function that defines how to add or subtract the
RANGE offset value. Factoring it this way also allows the operator class
to avoid overflow problems near the ends of the datatype's range, if it
wishes to expend effort on that. (In the committed patch, the integer
opclasses handle that issue, but it did not seem worth the trouble to
avoid overflow failures for datetime types.)
The patch includes in_range support for the integer_ops opfamily
(int2/int4/int8) as well as the standard datetime types. Support for
other numeric types has been requested, but that seems like suitable
material for a follow-on patch.
In addition, the patch adds GROUPS mode which counts the offset in
ORDER-BY peer groups rather than rows, and it adds the frame_exclusion
options specified by SQL:2011. As far as I can see, we are now fully
up to spec on window framing options.
Existing behaviors remain unchanged, except that I changed the errcode
for a couple of existing error reports to meet the SQL spec's expectation
that negative "offset" values should be reported as SQLSTATE 22013.
Internally and in relevant parts of the documentation, we now consistently
use the terminology "offset PRECEDING/FOLLOWING" rather than "value
PRECEDING/FOLLOWING", since the term "value" is confusingly vague.
Oliver Ford, reviewed and whacked around some by me
Discussion: https://postgr.es/m/CAGMVOdu9sivPAxbNN0X+q19Sfv9edEPv=HibOJhB14TJv_RCQg@mail.gmail.com
2018-02-07 06:06:50 +01:00
|
|
|
RANGE frame_extent opt_window_exclusion_clause
|
2008-12-31 01:08:39 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
WindowDef *n = $2;
|
|
|
|
|
|
2010-02-12 18:33:21 +01:00
|
|
|
n->frameOptions |= FRAMEOPTION_NONDEFAULT | FRAMEOPTION_RANGE;
|
Support all SQL:2011 options for window frame clauses.
This patch adds the ability to use "RANGE offset PRECEDING/FOLLOWING"
frame boundaries in window functions. We'd punted on that back in the
original patch to add window functions, because it was not clear how to
do it in a reasonably data-type-extensible fashion. That problem is
resolved here by adding the ability for btree operator classes to provide
an "in_range" support function that defines how to add or subtract the
RANGE offset value. Factoring it this way also allows the operator class
to avoid overflow problems near the ends of the datatype's range, if it
wishes to expend effort on that. (In the committed patch, the integer
opclasses handle that issue, but it did not seem worth the trouble to
avoid overflow failures for datetime types.)
The patch includes in_range support for the integer_ops opfamily
(int2/int4/int8) as well as the standard datetime types. Support for
other numeric types has been requested, but that seems like suitable
material for a follow-on patch.
In addition, the patch adds GROUPS mode which counts the offset in
ORDER-BY peer groups rather than rows, and it adds the frame_exclusion
options specified by SQL:2011. As far as I can see, we are now fully
up to spec on window framing options.
Existing behaviors remain unchanged, except that I changed the errcode
for a couple of existing error reports to meet the SQL spec's expectation
that negative "offset" values should be reported as SQLSTATE 22013.
Internally and in relevant parts of the documentation, we now consistently
use the terminology "offset PRECEDING/FOLLOWING" rather than "value
PRECEDING/FOLLOWING", since the term "value" is confusingly vague.
Oliver Ford, reviewed and whacked around some by me
Discussion: https://postgr.es/m/CAGMVOdu9sivPAxbNN0X+q19Sfv9edEPv=HibOJhB14TJv_RCQg@mail.gmail.com
2018-02-07 06:06:50 +01:00
|
|
|
n->frameOptions |= $3;
|
2010-02-12 18:33:21 +01:00
|
|
|
$$ = n;
|
2008-12-31 01:08:39 +01:00
|
|
|
}
|
Support all SQL:2011 options for window frame clauses.
This patch adds the ability to use "RANGE offset PRECEDING/FOLLOWING"
frame boundaries in window functions. We'd punted on that back in the
original patch to add window functions, because it was not clear how to
do it in a reasonably data-type-extensible fashion. That problem is
resolved here by adding the ability for btree operator classes to provide
an "in_range" support function that defines how to add or subtract the
RANGE offset value. Factoring it this way also allows the operator class
to avoid overflow problems near the ends of the datatype's range, if it
wishes to expend effort on that. (In the committed patch, the integer
opclasses handle that issue, but it did not seem worth the trouble to
avoid overflow failures for datetime types.)
The patch includes in_range support for the integer_ops opfamily
(int2/int4/int8) as well as the standard datetime types. Support for
other numeric types has been requested, but that seems like suitable
material for a follow-on patch.
In addition, the patch adds GROUPS mode which counts the offset in
ORDER-BY peer groups rather than rows, and it adds the frame_exclusion
options specified by SQL:2011. As far as I can see, we are now fully
up to spec on window framing options.
Existing behaviors remain unchanged, except that I changed the errcode
for a couple of existing error reports to meet the SQL spec's expectation
that negative "offset" values should be reported as SQLSTATE 22013.
Internally and in relevant parts of the documentation, we now consistently
use the terminology "offset PRECEDING/FOLLOWING" rather than "value
PRECEDING/FOLLOWING", since the term "value" is confusingly vague.
Oliver Ford, reviewed and whacked around some by me
Discussion: https://postgr.es/m/CAGMVOdu9sivPAxbNN0X+q19Sfv9edEPv=HibOJhB14TJv_RCQg@mail.gmail.com
2018-02-07 06:06:50 +01:00
|
|
|
| ROWS frame_extent opt_window_exclusion_clause
|
2008-12-31 01:08:39 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
WindowDef *n = $2;
|
|
|
|
|
|
2010-02-12 18:33:21 +01:00
|
|
|
n->frameOptions |= FRAMEOPTION_NONDEFAULT | FRAMEOPTION_ROWS;
|
Support all SQL:2011 options for window frame clauses.
This patch adds the ability to use "RANGE offset PRECEDING/FOLLOWING"
frame boundaries in window functions. We'd punted on that back in the
original patch to add window functions, because it was not clear how to
do it in a reasonably data-type-extensible fashion. That problem is
resolved here by adding the ability for btree operator classes to provide
an "in_range" support function that defines how to add or subtract the
RANGE offset value. Factoring it this way also allows the operator class
to avoid overflow problems near the ends of the datatype's range, if it
wishes to expend effort on that. (In the committed patch, the integer
opclasses handle that issue, but it did not seem worth the trouble to
avoid overflow failures for datetime types.)
The patch includes in_range support for the integer_ops opfamily
(int2/int4/int8) as well as the standard datetime types. Support for
other numeric types has been requested, but that seems like suitable
material for a follow-on patch.
In addition, the patch adds GROUPS mode which counts the offset in
ORDER-BY peer groups rather than rows, and it adds the frame_exclusion
options specified by SQL:2011. As far as I can see, we are now fully
up to spec on window framing options.
Existing behaviors remain unchanged, except that I changed the errcode
for a couple of existing error reports to meet the SQL spec's expectation
that negative "offset" values should be reported as SQLSTATE 22013.
Internally and in relevant parts of the documentation, we now consistently
use the terminology "offset PRECEDING/FOLLOWING" rather than "value
PRECEDING/FOLLOWING", since the term "value" is confusingly vague.
Oliver Ford, reviewed and whacked around some by me
Discussion: https://postgr.es/m/CAGMVOdu9sivPAxbNN0X+q19Sfv9edEPv=HibOJhB14TJv_RCQg@mail.gmail.com
2018-02-07 06:06:50 +01:00
|
|
|
n->frameOptions |= $3;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| GROUPS frame_extent opt_window_exclusion_clause
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
WindowDef *n = $2;
|
|
|
|
|
|
Support all SQL:2011 options for window frame clauses.
This patch adds the ability to use "RANGE offset PRECEDING/FOLLOWING"
frame boundaries in window functions. We'd punted on that back in the
original patch to add window functions, because it was not clear how to
do it in a reasonably data-type-extensible fashion. That problem is
resolved here by adding the ability for btree operator classes to provide
an "in_range" support function that defines how to add or subtract the
RANGE offset value. Factoring it this way also allows the operator class
to avoid overflow problems near the ends of the datatype's range, if it
wishes to expend effort on that. (In the committed patch, the integer
opclasses handle that issue, but it did not seem worth the trouble to
avoid overflow failures for datetime types.)
The patch includes in_range support for the integer_ops opfamily
(int2/int4/int8) as well as the standard datetime types. Support for
other numeric types has been requested, but that seems like suitable
material for a follow-on patch.
In addition, the patch adds GROUPS mode which counts the offset in
ORDER-BY peer groups rather than rows, and it adds the frame_exclusion
options specified by SQL:2011. As far as I can see, we are now fully
up to spec on window framing options.
Existing behaviors remain unchanged, except that I changed the errcode
for a couple of existing error reports to meet the SQL spec's expectation
that negative "offset" values should be reported as SQLSTATE 22013.
Internally and in relevant parts of the documentation, we now consistently
use the terminology "offset PRECEDING/FOLLOWING" rather than "value
PRECEDING/FOLLOWING", since the term "value" is confusingly vague.
Oliver Ford, reviewed and whacked around some by me
Discussion: https://postgr.es/m/CAGMVOdu9sivPAxbNN0X+q19Sfv9edEPv=HibOJhB14TJv_RCQg@mail.gmail.com
2018-02-07 06:06:50 +01:00
|
|
|
n->frameOptions |= FRAMEOPTION_NONDEFAULT | FRAMEOPTION_GROUPS;
|
|
|
|
|
n->frameOptions |= $3;
|
2010-02-12 18:33:21 +01:00
|
|
|
$$ = n;
|
2008-12-31 01:08:39 +01:00
|
|
|
}
|
|
|
|
|
| /*EMPTY*/
|
2010-02-12 18:33:21 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
WindowDef *n = makeNode(WindowDef);
|
|
|
|
|
|
2010-02-12 18:33:21 +01:00
|
|
|
n->frameOptions = FRAMEOPTION_DEFAULTS;
|
|
|
|
|
n->startOffset = NULL;
|
|
|
|
|
n->endOffset = NULL;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
2008-12-31 01:08:39 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
frame_extent: frame_bound
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
WindowDef *n = $1;
|
|
|
|
|
|
2008-12-31 01:08:39 +01:00
|
|
|
/* reject invalid cases */
|
2010-02-12 18:33:21 +01:00
|
|
|
if (n->frameOptions & FRAMEOPTION_START_UNBOUNDED_FOLLOWING)
|
2008-12-31 01:08:39 +01:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_WINDOWING_ERROR),
|
|
|
|
|
errmsg("frame start cannot be UNBOUNDED FOLLOWING"),
|
2009-07-13 04:02:20 +02:00
|
|
|
parser_errposition(@1)));
|
Support all SQL:2011 options for window frame clauses.
This patch adds the ability to use "RANGE offset PRECEDING/FOLLOWING"
frame boundaries in window functions. We'd punted on that back in the
original patch to add window functions, because it was not clear how to
do it in a reasonably data-type-extensible fashion. That problem is
resolved here by adding the ability for btree operator classes to provide
an "in_range" support function that defines how to add or subtract the
RANGE offset value. Factoring it this way also allows the operator class
to avoid overflow problems near the ends of the datatype's range, if it
wishes to expend effort on that. (In the committed patch, the integer
opclasses handle that issue, but it did not seem worth the trouble to
avoid overflow failures for datetime types.)
The patch includes in_range support for the integer_ops opfamily
(int2/int4/int8) as well as the standard datetime types. Support for
other numeric types has been requested, but that seems like suitable
material for a follow-on patch.
In addition, the patch adds GROUPS mode which counts the offset in
ORDER-BY peer groups rather than rows, and it adds the frame_exclusion
options specified by SQL:2011. As far as I can see, we are now fully
up to spec on window framing options.
Existing behaviors remain unchanged, except that I changed the errcode
for a couple of existing error reports to meet the SQL spec's expectation
that negative "offset" values should be reported as SQLSTATE 22013.
Internally and in relevant parts of the documentation, we now consistently
use the terminology "offset PRECEDING/FOLLOWING" rather than "value
PRECEDING/FOLLOWING", since the term "value" is confusingly vague.
Oliver Ford, reviewed and whacked around some by me
Discussion: https://postgr.es/m/CAGMVOdu9sivPAxbNN0X+q19Sfv9edEPv=HibOJhB14TJv_RCQg@mail.gmail.com
2018-02-07 06:06:50 +01:00
|
|
|
if (n->frameOptions & FRAMEOPTION_START_OFFSET_FOLLOWING)
|
2008-12-31 01:08:39 +01:00
|
|
|
ereport(ERROR,
|
2010-02-12 18:33:21 +01:00
|
|
|
(errcode(ERRCODE_WINDOWING_ERROR),
|
|
|
|
|
errmsg("frame starting from following row cannot end with current row"),
|
2009-07-13 04:02:20 +02:00
|
|
|
parser_errposition(@1)));
|
2010-02-12 18:33:21 +01:00
|
|
|
n->frameOptions |= FRAMEOPTION_END_CURRENT_ROW;
|
|
|
|
|
$$ = n;
|
2008-12-31 01:08:39 +01:00
|
|
|
}
|
|
|
|
|
| BETWEEN frame_bound AND frame_bound
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
WindowDef *n1 = $2;
|
|
|
|
|
WindowDef *n2 = $4;
|
|
|
|
|
|
2010-02-12 18:33:21 +01:00
|
|
|
/* form merged options */
|
|
|
|
|
int frameOptions = n1->frameOptions;
|
|
|
|
|
/* shift converts START_ options to END_ options */
|
|
|
|
|
frameOptions |= n2->frameOptions << 1;
|
|
|
|
|
frameOptions |= FRAMEOPTION_BETWEEN;
|
2008-12-31 01:08:39 +01:00
|
|
|
/* reject invalid cases */
|
2010-02-12 18:33:21 +01:00
|
|
|
if (frameOptions & FRAMEOPTION_START_UNBOUNDED_FOLLOWING)
|
2008-12-31 01:08:39 +01:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_WINDOWING_ERROR),
|
|
|
|
|
errmsg("frame start cannot be UNBOUNDED FOLLOWING"),
|
2009-07-13 04:02:20 +02:00
|
|
|
parser_errposition(@2)));
|
2010-02-12 18:33:21 +01:00
|
|
|
if (frameOptions & FRAMEOPTION_END_UNBOUNDED_PRECEDING)
|
2008-12-31 01:08:39 +01:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_WINDOWING_ERROR),
|
|
|
|
|
errmsg("frame end cannot be UNBOUNDED PRECEDING"),
|
2009-07-13 04:02:20 +02:00
|
|
|
parser_errposition(@4)));
|
2010-02-12 18:33:21 +01:00
|
|
|
if ((frameOptions & FRAMEOPTION_START_CURRENT_ROW) &&
|
Support all SQL:2011 options for window frame clauses.
This patch adds the ability to use "RANGE offset PRECEDING/FOLLOWING"
frame boundaries in window functions. We'd punted on that back in the
original patch to add window functions, because it was not clear how to
do it in a reasonably data-type-extensible fashion. That problem is
resolved here by adding the ability for btree operator classes to provide
an "in_range" support function that defines how to add or subtract the
RANGE offset value. Factoring it this way also allows the operator class
to avoid overflow problems near the ends of the datatype's range, if it
wishes to expend effort on that. (In the committed patch, the integer
opclasses handle that issue, but it did not seem worth the trouble to
avoid overflow failures for datetime types.)
The patch includes in_range support for the integer_ops opfamily
(int2/int4/int8) as well as the standard datetime types. Support for
other numeric types has been requested, but that seems like suitable
material for a follow-on patch.
In addition, the patch adds GROUPS mode which counts the offset in
ORDER-BY peer groups rather than rows, and it adds the frame_exclusion
options specified by SQL:2011. As far as I can see, we are now fully
up to spec on window framing options.
Existing behaviors remain unchanged, except that I changed the errcode
for a couple of existing error reports to meet the SQL spec's expectation
that negative "offset" values should be reported as SQLSTATE 22013.
Internally and in relevant parts of the documentation, we now consistently
use the terminology "offset PRECEDING/FOLLOWING" rather than "value
PRECEDING/FOLLOWING", since the term "value" is confusingly vague.
Oliver Ford, reviewed and whacked around some by me
Discussion: https://postgr.es/m/CAGMVOdu9sivPAxbNN0X+q19Sfv9edEPv=HibOJhB14TJv_RCQg@mail.gmail.com
2018-02-07 06:06:50 +01:00
|
|
|
(frameOptions & FRAMEOPTION_END_OFFSET_PRECEDING))
|
2010-02-12 18:33:21 +01:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_WINDOWING_ERROR),
|
|
|
|
|
errmsg("frame starting from current row cannot have preceding rows"),
|
|
|
|
|
parser_errposition(@4)));
|
Support all SQL:2011 options for window frame clauses.
This patch adds the ability to use "RANGE offset PRECEDING/FOLLOWING"
frame boundaries in window functions. We'd punted on that back in the
original patch to add window functions, because it was not clear how to
do it in a reasonably data-type-extensible fashion. That problem is
resolved here by adding the ability for btree operator classes to provide
an "in_range" support function that defines how to add or subtract the
RANGE offset value. Factoring it this way also allows the operator class
to avoid overflow problems near the ends of the datatype's range, if it
wishes to expend effort on that. (In the committed patch, the integer
opclasses handle that issue, but it did not seem worth the trouble to
avoid overflow failures for datetime types.)
The patch includes in_range support for the integer_ops opfamily
(int2/int4/int8) as well as the standard datetime types. Support for
other numeric types has been requested, but that seems like suitable
material for a follow-on patch.
In addition, the patch adds GROUPS mode which counts the offset in
ORDER-BY peer groups rather than rows, and it adds the frame_exclusion
options specified by SQL:2011. As far as I can see, we are now fully
up to spec on window framing options.
Existing behaviors remain unchanged, except that I changed the errcode
for a couple of existing error reports to meet the SQL spec's expectation
that negative "offset" values should be reported as SQLSTATE 22013.
Internally and in relevant parts of the documentation, we now consistently
use the terminology "offset PRECEDING/FOLLOWING" rather than "value
PRECEDING/FOLLOWING", since the term "value" is confusingly vague.
Oliver Ford, reviewed and whacked around some by me
Discussion: https://postgr.es/m/CAGMVOdu9sivPAxbNN0X+q19Sfv9edEPv=HibOJhB14TJv_RCQg@mail.gmail.com
2018-02-07 06:06:50 +01:00
|
|
|
if ((frameOptions & FRAMEOPTION_START_OFFSET_FOLLOWING) &&
|
|
|
|
|
(frameOptions & (FRAMEOPTION_END_OFFSET_PRECEDING |
|
2010-02-12 18:33:21 +01:00
|
|
|
FRAMEOPTION_END_CURRENT_ROW)))
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_WINDOWING_ERROR),
|
|
|
|
|
errmsg("frame starting from following row cannot have preceding rows"),
|
|
|
|
|
parser_errposition(@4)));
|
|
|
|
|
n1->frameOptions = frameOptions;
|
|
|
|
|
n1->endOffset = n2->startOffset;
|
|
|
|
|
$$ = n1;
|
2008-12-31 01:08:39 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* This is used for both frame start and frame end, with output set up on
|
|
|
|
|
* the assumption it's frame start; the frame_extent productions must reject
|
|
|
|
|
* invalid cases.
|
|
|
|
|
*/
|
|
|
|
|
frame_bound:
|
|
|
|
|
UNBOUNDED PRECEDING
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
WindowDef *n = makeNode(WindowDef);
|
|
|
|
|
|
2010-02-12 18:33:21 +01:00
|
|
|
n->frameOptions = FRAMEOPTION_START_UNBOUNDED_PRECEDING;
|
|
|
|
|
n->startOffset = NULL;
|
|
|
|
|
n->endOffset = NULL;
|
|
|
|
|
$$ = n;
|
2008-12-31 01:08:39 +01:00
|
|
|
}
|
|
|
|
|
| UNBOUNDED FOLLOWING
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
WindowDef *n = makeNode(WindowDef);
|
|
|
|
|
|
2010-02-12 18:33:21 +01:00
|
|
|
n->frameOptions = FRAMEOPTION_START_UNBOUNDED_FOLLOWING;
|
|
|
|
|
n->startOffset = NULL;
|
|
|
|
|
n->endOffset = NULL;
|
|
|
|
|
$$ = n;
|
2008-12-31 01:08:39 +01:00
|
|
|
}
|
|
|
|
|
| CURRENT_P ROW
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
WindowDef *n = makeNode(WindowDef);
|
|
|
|
|
|
2010-02-12 18:33:21 +01:00
|
|
|
n->frameOptions = FRAMEOPTION_START_CURRENT_ROW;
|
|
|
|
|
n->startOffset = NULL;
|
|
|
|
|
n->endOffset = NULL;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| a_expr PRECEDING
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
WindowDef *n = makeNode(WindowDef);
|
|
|
|
|
|
Support all SQL:2011 options for window frame clauses.
This patch adds the ability to use "RANGE offset PRECEDING/FOLLOWING"
frame boundaries in window functions. We'd punted on that back in the
original patch to add window functions, because it was not clear how to
do it in a reasonably data-type-extensible fashion. That problem is
resolved here by adding the ability for btree operator classes to provide
an "in_range" support function that defines how to add or subtract the
RANGE offset value. Factoring it this way also allows the operator class
to avoid overflow problems near the ends of the datatype's range, if it
wishes to expend effort on that. (In the committed patch, the integer
opclasses handle that issue, but it did not seem worth the trouble to
avoid overflow failures for datetime types.)
The patch includes in_range support for the integer_ops opfamily
(int2/int4/int8) as well as the standard datetime types. Support for
other numeric types has been requested, but that seems like suitable
material for a follow-on patch.
In addition, the patch adds GROUPS mode which counts the offset in
ORDER-BY peer groups rather than rows, and it adds the frame_exclusion
options specified by SQL:2011. As far as I can see, we are now fully
up to spec on window framing options.
Existing behaviors remain unchanged, except that I changed the errcode
for a couple of existing error reports to meet the SQL spec's expectation
that negative "offset" values should be reported as SQLSTATE 22013.
Internally and in relevant parts of the documentation, we now consistently
use the terminology "offset PRECEDING/FOLLOWING" rather than "value
PRECEDING/FOLLOWING", since the term "value" is confusingly vague.
Oliver Ford, reviewed and whacked around some by me
Discussion: https://postgr.es/m/CAGMVOdu9sivPAxbNN0X+q19Sfv9edEPv=HibOJhB14TJv_RCQg@mail.gmail.com
2018-02-07 06:06:50 +01:00
|
|
|
n->frameOptions = FRAMEOPTION_START_OFFSET_PRECEDING;
|
2010-02-12 18:33:21 +01:00
|
|
|
n->startOffset = $1;
|
|
|
|
|
n->endOffset = NULL;
|
|
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| a_expr FOLLOWING
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
WindowDef *n = makeNode(WindowDef);
|
|
|
|
|
|
Support all SQL:2011 options for window frame clauses.
This patch adds the ability to use "RANGE offset PRECEDING/FOLLOWING"
frame boundaries in window functions. We'd punted on that back in the
original patch to add window functions, because it was not clear how to
do it in a reasonably data-type-extensible fashion. That problem is
resolved here by adding the ability for btree operator classes to provide
an "in_range" support function that defines how to add or subtract the
RANGE offset value. Factoring it this way also allows the operator class
to avoid overflow problems near the ends of the datatype's range, if it
wishes to expend effort on that. (In the committed patch, the integer
opclasses handle that issue, but it did not seem worth the trouble to
avoid overflow failures for datetime types.)
The patch includes in_range support for the integer_ops opfamily
(int2/int4/int8) as well as the standard datetime types. Support for
other numeric types has been requested, but that seems like suitable
material for a follow-on patch.
In addition, the patch adds GROUPS mode which counts the offset in
ORDER-BY peer groups rather than rows, and it adds the frame_exclusion
options specified by SQL:2011. As far as I can see, we are now fully
up to spec on window framing options.
Existing behaviors remain unchanged, except that I changed the errcode
for a couple of existing error reports to meet the SQL spec's expectation
that negative "offset" values should be reported as SQLSTATE 22013.
Internally and in relevant parts of the documentation, we now consistently
use the terminology "offset PRECEDING/FOLLOWING" rather than "value
PRECEDING/FOLLOWING", since the term "value" is confusingly vague.
Oliver Ford, reviewed and whacked around some by me
Discussion: https://postgr.es/m/CAGMVOdu9sivPAxbNN0X+q19Sfv9edEPv=HibOJhB14TJv_RCQg@mail.gmail.com
2018-02-07 06:06:50 +01:00
|
|
|
n->frameOptions = FRAMEOPTION_START_OFFSET_FOLLOWING;
|
2010-02-12 18:33:21 +01:00
|
|
|
n->startOffset = $1;
|
|
|
|
|
n->endOffset = NULL;
|
|
|
|
|
$$ = n;
|
2008-12-31 01:08:39 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
Support all SQL:2011 options for window frame clauses.
This patch adds the ability to use "RANGE offset PRECEDING/FOLLOWING"
frame boundaries in window functions. We'd punted on that back in the
original patch to add window functions, because it was not clear how to
do it in a reasonably data-type-extensible fashion. That problem is
resolved here by adding the ability for btree operator classes to provide
an "in_range" support function that defines how to add or subtract the
RANGE offset value. Factoring it this way also allows the operator class
to avoid overflow problems near the ends of the datatype's range, if it
wishes to expend effort on that. (In the committed patch, the integer
opclasses handle that issue, but it did not seem worth the trouble to
avoid overflow failures for datetime types.)
The patch includes in_range support for the integer_ops opfamily
(int2/int4/int8) as well as the standard datetime types. Support for
other numeric types has been requested, but that seems like suitable
material for a follow-on patch.
In addition, the patch adds GROUPS mode which counts the offset in
ORDER-BY peer groups rather than rows, and it adds the frame_exclusion
options specified by SQL:2011. As far as I can see, we are now fully
up to spec on window framing options.
Existing behaviors remain unchanged, except that I changed the errcode
for a couple of existing error reports to meet the SQL spec's expectation
that negative "offset" values should be reported as SQLSTATE 22013.
Internally and in relevant parts of the documentation, we now consistently
use the terminology "offset PRECEDING/FOLLOWING" rather than "value
PRECEDING/FOLLOWING", since the term "value" is confusingly vague.
Oliver Ford, reviewed and whacked around some by me
Discussion: https://postgr.es/m/CAGMVOdu9sivPAxbNN0X+q19Sfv9edEPv=HibOJhB14TJv_RCQg@mail.gmail.com
2018-02-07 06:06:50 +01:00
|
|
|
opt_window_exclusion_clause:
|
|
|
|
|
EXCLUDE CURRENT_P ROW { $$ = FRAMEOPTION_EXCLUDE_CURRENT_ROW; }
|
|
|
|
|
| EXCLUDE GROUP_P { $$ = FRAMEOPTION_EXCLUDE_GROUP; }
|
|
|
|
|
| EXCLUDE TIES { $$ = FRAMEOPTION_EXCLUDE_TIES; }
|
|
|
|
|
| EXCLUDE NO OTHERS { $$ = 0; }
|
|
|
|
|
| /*EMPTY*/ { $$ = 0; }
|
|
|
|
|
;
|
|
|
|
|
|
2008-12-31 01:08:39 +01:00
|
|
|
|
1999-11-20 22:39:36 +01:00
|
|
|
/*
|
|
|
|
|
* Supporting nonterminals for expressions.
|
|
|
|
|
*/
|
|
|
|
|
|
2004-05-11 00:44:49 +02:00
|
|
|
/* Explicit row production.
|
|
|
|
|
*
|
|
|
|
|
* SQL99 allows an optional ROW keyword, so we can now do single-element rows
|
|
|
|
|
* without conflicting with the parenthesized a_expr production. Without the
|
|
|
|
|
* ROW keyword, there must be more than one a_expr inside the parens.
|
|
|
|
|
*/
|
|
|
|
|
row: ROW '(' expr_list ')' { $$ = $3; }
|
|
|
|
|
| ROW '(' ')' { $$ = NIL; }
|
|
|
|
|
| '(' expr_list ',' a_expr ')' { $$ = lappend($2, $4); }
|
|
|
|
|
;
|
|
|
|
|
|
Support GROUPING SETS, CUBE and ROLLUP.
This SQL standard functionality allows to aggregate data by different
GROUP BY clauses at once. Each grouping set returns rows with columns
grouped by in other sets set to NULL.
This could previously be achieved by doing each grouping as a separate
query, conjoined by UNION ALLs. Besides being considerably more concise,
grouping sets will in many cases be faster, requiring only one scan over
the underlying data.
The current implementation of grouping sets only supports using sorting
for input. Individual sets that share a sort order are computed in one
pass. If there are sets that don't share a sort order, additional sort &
aggregation steps are performed. These additional passes are sourced by
the previous sort step; thus avoiding repeated scans of the source data.
The code is structured in a way that adding support for purely using
hash aggregation or a mix of hashing and sorting is possible. Sorting
was chosen to be supported first, as it is the most generic method of
implementation.
Instead of, as in an earlier versions of the patch, representing the
chain of sort and aggregation steps as full blown planner and executor
nodes, all but the first sort are performed inside the aggregation node
itself. This avoids the need to do some unusual gymnastics to handle
having to return aggregated and non-aggregated tuples from underlying
nodes, as well as having to shut down underlying nodes early to limit
memory usage. The optimizer still builds Sort/Agg node to describe each
phase, but they're not part of the plan tree, but instead additional
data for the aggregation node. They're a convenient and preexisting way
to describe aggregation and sorting. The first (and possibly only) sort
step is still performed as a separate execution step. That retains
similarity with existing group by plans, makes rescans fairly simple,
avoids very deep plans (leading to slow explains) and easily allows to
avoid the sorting step if the underlying data is sorted by other means.
A somewhat ugly side of this patch is having to deal with a grammar
ambiguity between the new CUBE keyword and the cube extension/functions
named cube (and rollup). To avoid breaking existing deployments of the
cube extension it has not been renamed, neither has cube been made a
reserved keyword. Instead precedence hacking is used to make GROUP BY
cube(..) refer to the CUBE grouping sets feature, and not the function
cube(). To actually group by a function cube(), unlikely as that might
be, the function name has to be quoted.
Needs a catversion bump because stored rules may change.
Author: Andrew Gierth and Atri Sharma, with contributions from Andres Freund
Reviewed-By: Andres Freund, Noah Misch, Tom Lane, Svenne Krap, Tomas
Vondra, Erik Rijkers, Marti Raudsepp, Pavel Stehule
Discussion: CAOeZVidmVRe2jU6aMk_5qkxnB7dfmPROzM7Ur8JPW5j8Y5X-Lw@mail.gmail.com
2015-05-16 03:40:59 +02:00
|
|
|
explicit_row: ROW '(' expr_list ')' { $$ = $3; }
|
|
|
|
|
| ROW '(' ')' { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
implicit_row: '(' expr_list ',' a_expr ')' { $$ = lappend($2, $4); }
|
|
|
|
|
;
|
|
|
|
|
|
2004-05-11 00:44:49 +02:00
|
|
|
sub_type: ANY { $$ = ANY_SUBLINK; }
|
|
|
|
|
| SOME { $$ = ANY_SUBLINK; }
|
|
|
|
|
| ALL { $$ = ALL_SUBLINK; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
all_Op: Op { $$ = $1; }
|
|
|
|
|
| MathOp { $$ = $1; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
MathOp: '+' { $$ = "+"; }
|
|
|
|
|
| '-' { $$ = "-"; }
|
|
|
|
|
| '*' { $$ = "*"; }
|
|
|
|
|
| '/' { $$ = "/"; }
|
|
|
|
|
| '%' { $$ = "%"; }
|
|
|
|
|
| '^' { $$ = "^"; }
|
|
|
|
|
| '<' { $$ = "<"; }
|
|
|
|
|
| '>' { $$ = ">"; }
|
|
|
|
|
| '=' { $$ = "="; }
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
| LESS_EQUALS { $$ = "<="; }
|
|
|
|
|
| GREATER_EQUALS { $$ = ">="; }
|
|
|
|
|
| NOT_EQUALS { $$ = "<>"; }
|
2004-05-11 00:44:49 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
qual_Op: Op
|
2004-05-31 01:40:41 +02:00
|
|
|
{ $$ = list_make1(makeString($1)); }
|
2004-05-11 00:44:49 +02:00
|
|
|
| OPERATOR '(' any_operator ')'
|
|
|
|
|
{ $$ = $3; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
qual_all_Op:
|
|
|
|
|
all_Op
|
2004-05-31 01:40:41 +02:00
|
|
|
{ $$ = list_make1(makeString($1)); }
|
2004-05-11 00:44:49 +02:00
|
|
|
| OPERATOR '(' any_operator ')'
|
|
|
|
|
{ $$ = $3; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
subquery_Op:
|
|
|
|
|
all_Op
|
2004-05-31 01:40:41 +02:00
|
|
|
{ $$ = list_make1(makeString($1)); }
|
2004-05-11 00:44:49 +02:00
|
|
|
| OPERATOR '(' any_operator ')'
|
|
|
|
|
{ $$ = $3; }
|
|
|
|
|
| LIKE
|
2004-05-31 01:40:41 +02:00
|
|
|
{ $$ = list_make1(makeString("~~")); }
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
| NOT_LA LIKE
|
2004-05-31 01:40:41 +02:00
|
|
|
{ $$ = list_make1(makeString("!~~")); }
|
2004-05-11 00:44:49 +02:00
|
|
|
| ILIKE
|
2004-05-31 01:40:41 +02:00
|
|
|
{ $$ = list_make1(makeString("~~*")); }
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
| NOT_LA ILIKE
|
2004-05-31 01:40:41 +02:00
|
|
|
{ $$ = list_make1(makeString("!~~*")); }
|
2004-05-11 00:44:49 +02:00
|
|
|
/* cannot put SIMILAR TO here, because SIMILAR TO is a hack.
|
2019-09-07 20:21:59 +02:00
|
|
|
* the regular expression is preprocessed by a function (similar_to_escape),
|
2004-06-18 08:14:31 +02:00
|
|
|
* and the ~ operator for posix regular expressions is used.
|
2019-09-07 20:21:59 +02:00
|
|
|
* x SIMILAR TO y -> x ~ similar_to_escape(y)
|
2004-05-11 00:44:49 +02:00
|
|
|
* this transformation is made on the fly by the parser upwards.
|
|
|
|
|
* however the SubLink structure which handles any/some/all stuff
|
|
|
|
|
* is not ready for such a thing.
|
|
|
|
|
*/
|
|
|
|
|
;
|
|
|
|
|
|
2003-08-22 22:34:33 +02:00
|
|
|
expr_list: a_expr
|
|
|
|
|
{
|
2004-06-01 05:28:48 +02:00
|
|
|
$$ = list_make1($1);
|
2003-08-22 22:34:33 +02:00
|
|
|
}
|
|
|
|
|
| expr_list ',' a_expr
|
|
|
|
|
{
|
2004-06-01 05:28:48 +02:00
|
|
|
$$ = lappend($1, $3);
|
2003-08-22 22:34:33 +02:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1997-09-01 08:00:35 +02:00
|
|
|
|
2009-10-08 04:39:25 +02:00
|
|
|
/* function arguments can have names */
|
|
|
|
|
func_arg_list: func_arg_expr
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make1($1);
|
|
|
|
|
}
|
|
|
|
|
| func_arg_list ',' func_arg_expr
|
|
|
|
|
{
|
|
|
|
|
$$ = lappend($1, $3);
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
func_arg_expr: a_expr
|
|
|
|
|
{
|
|
|
|
|
$$ = $1;
|
|
|
|
|
}
|
2010-05-30 20:10:41 +02:00
|
|
|
| param_name COLON_EQUALS a_expr
|
2009-10-08 04:39:25 +02:00
|
|
|
{
|
|
|
|
|
NamedArgExpr *na = makeNode(NamedArgExpr);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2010-05-30 20:10:41 +02:00
|
|
|
na->name = $1;
|
|
|
|
|
na->arg = (Expr *) $3;
|
2009-10-08 04:39:25 +02:00
|
|
|
na->argnumber = -1; /* until determined */
|
2010-05-30 20:10:41 +02:00
|
|
|
na->location = @1;
|
2009-10-08 04:39:25 +02:00
|
|
|
$$ = (Node *) na;
|
|
|
|
|
}
|
Allow named parameters to be specified using => in addition to :=
SQL has standardized on => as the use of to specify named parameters,
and we've wanted for many years to support the same syntax ourselves,
but this has been complicated by the possible use of => as an operator
name. In PostgreSQL 9.0, we began emitting a warning when an operator
named => was defined, and in PostgreSQL 9.2, we stopped shipping a
=>(text, text) operator as part of hstore. By the time the next major
version of PostgreSQL is released, => will have been deprecated for a
full five years, so hopefully there won't be too many people still
relying on it. We continue to support := for compatibility with
previous PostgreSQL releases.
Pavel Stehule, reviewed by Petr Jelinek, with a few documentation
tweaks by me.
2015-03-10 15:59:11 +01:00
|
|
|
| param_name EQUALS_GREATER a_expr
|
|
|
|
|
{
|
|
|
|
|
NamedArgExpr *na = makeNode(NamedArgExpr);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
Allow named parameters to be specified using => in addition to :=
SQL has standardized on => as the use of to specify named parameters,
and we've wanted for many years to support the same syntax ourselves,
but this has been complicated by the possible use of => as an operator
name. In PostgreSQL 9.0, we began emitting a warning when an operator
named => was defined, and in PostgreSQL 9.2, we stopped shipping a
=>(text, text) operator as part of hstore. By the time the next major
version of PostgreSQL is released, => will have been deprecated for a
full five years, so hopefully there won't be too many people still
relying on it. We continue to support := for compatibility with
previous PostgreSQL releases.
Pavel Stehule, reviewed by Petr Jelinek, with a few documentation
tweaks by me.
2015-03-10 15:59:11 +01:00
|
|
|
na->name = $1;
|
|
|
|
|
na->arg = (Expr *) $3;
|
|
|
|
|
na->argnumber = -1; /* until determined */
|
|
|
|
|
na->location = @1;
|
|
|
|
|
$$ = (Node *) na;
|
|
|
|
|
}
|
2009-10-08 04:39:25 +02:00
|
|
|
;
|
|
|
|
|
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
func_arg_list_opt: func_arg_list { $$ = $1; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
2007-01-23 06:07:18 +01:00
|
|
|
type_list: Typename { $$ = list_make1($1); }
|
|
|
|
|
| type_list ',' Typename { $$ = lappend($1, $3); }
|
2002-08-04 08:51:23 +02:00
|
|
|
;
|
|
|
|
|
|
2003-04-09 01:20:04 +02:00
|
|
|
array_expr: '[' expr_list ']'
|
|
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeAArrayExpr($2, @1);
|
2003-04-09 01:20:04 +02:00
|
|
|
}
|
|
|
|
|
| '[' array_expr_list ']'
|
|
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeAArrayExpr($2, @1);
|
2008-03-20 22:42:48 +01:00
|
|
|
}
|
|
|
|
|
| '[' ']'
|
|
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeAArrayExpr(NIL, @1);
|
2008-03-20 22:42:48 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
array_expr_list: array_expr { $$ = list_make1($1); }
|
|
|
|
|
| array_expr_list ',' array_expr { $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
extract_list:
|
|
|
|
|
extract_arg FROM a_expr
|
|
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = list_make2(makeStringConst($1, @1), $3);
|
2003-04-09 01:20:04 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2008-11-12 16:50:20 +01:00
|
|
|
/* Allow delimited string Sconst in extract_arg as an SQL extension.
|
2001-05-01 03:36:10 +02:00
|
|
|
* - thomas 2001-04-12
|
|
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
extract_arg:
|
|
|
|
|
IDENT { $$ = $1; }
|
|
|
|
|
| YEAR_P { $$ = "year"; }
|
|
|
|
|
| MONTH_P { $$ = "month"; }
|
|
|
|
|
| DAY_P { $$ = "day"; }
|
|
|
|
|
| HOUR_P { $$ = "hour"; }
|
|
|
|
|
| MINUTE_P { $$ = "minute"; }
|
|
|
|
|
| SECOND_P { $$ = "second"; }
|
2008-11-12 16:50:20 +01:00
|
|
|
| Sconst { $$ = $1; }
|
1998-04-08 08:39:01 +02:00
|
|
|
;
|
|
|
|
|
|
2020-03-26 08:14:00 +01:00
|
|
|
unicode_normal_form:
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
NFC { $$ = "NFC"; }
|
|
|
|
|
| NFD { $$ = "NFD"; }
|
|
|
|
|
| NFKC { $$ = "NFKC"; }
|
|
|
|
|
| NFKD { $$ = "NFKD"; }
|
2020-03-26 08:14:00 +01:00
|
|
|
;
|
|
|
|
|
|
2020-06-29 10:36:52 +02:00
|
|
|
/* OVERLAY() arguments */
|
2002-06-17 22:27:43 +02:00
|
|
|
overlay_list:
|
2020-06-29 10:36:52 +02:00
|
|
|
a_expr PLACING a_expr FROM a_expr FOR a_expr
|
2002-06-11 17:44:38 +02:00
|
|
|
{
|
2020-06-29 10:36:52 +02:00
|
|
|
/* overlay(A PLACING B FROM C FOR D) is converted to overlay(A, B, C, D) */
|
|
|
|
|
$$ = list_make4($1, $3, $5, $7);
|
2002-06-11 17:44:38 +02:00
|
|
|
}
|
2020-06-29 10:36:52 +02:00
|
|
|
| a_expr PLACING a_expr FROM a_expr
|
2002-06-11 17:44:38 +02:00
|
|
|
{
|
2020-06-29 10:36:52 +02:00
|
|
|
/* overlay(A PLACING B FROM C) is converted to overlay(A, B, C) */
|
|
|
|
|
$$ = list_make3($1, $3, $5);
|
2002-06-11 17:44:38 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
1999-07-17 00:29:42 +02:00
|
|
|
/* position_list uses b_expr not a_expr to avoid conflict with general IN */
|
2002-06-17 22:27:43 +02:00
|
|
|
position_list:
|
2004-05-31 01:40:41 +02:00
|
|
|
b_expr IN_P b_expr { $$ = list_make2($3, $1); }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1997-09-01 08:00:35 +02:00
|
|
|
|
2020-06-29 11:04:42 +02:00
|
|
|
/*
|
|
|
|
|
* SUBSTRING() arguments
|
|
|
|
|
*
|
|
|
|
|
* Note that SQL:1999 has both
|
|
|
|
|
* text FROM int FOR int
|
|
|
|
|
* and
|
|
|
|
|
* text FROM pattern FOR escape
|
|
|
|
|
*
|
|
|
|
|
* In the parser we map them both to a call to the substring() function and
|
|
|
|
|
* rely on type resolution to pick the right one.
|
|
|
|
|
*
|
|
|
|
|
* In SQL:2003, the second variant was changed to
|
|
|
|
|
* text SIMILAR pattern ESCAPE escape
|
|
|
|
|
* We could in theory map that to a different function internally, but
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
* since we still support the SQL:1999 version, we don't. However,
|
|
|
|
|
* ruleutils.c will reverse-list the call in the newer style.
|
2020-06-29 11:04:42 +02:00
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
substr_list:
|
2020-06-29 10:36:52 +02:00
|
|
|
a_expr FROM a_expr FOR a_expr
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2020-06-29 10:36:52 +02:00
|
|
|
$$ = list_make3($1, $3, $5);
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2020-06-29 10:36:52 +02:00
|
|
|
| a_expr FOR a_expr FROM a_expr
|
2000-12-03 15:51:12 +01:00
|
|
|
{
|
2020-06-29 10:36:52 +02:00
|
|
|
/* not legal per SQL, but might as well allow it */
|
|
|
|
|
$$ = list_make3($1, $5, $3);
|
2000-12-03 15:51:12 +01:00
|
|
|
}
|
2020-06-29 10:36:52 +02:00
|
|
|
| a_expr FROM a_expr
|
2000-12-03 15:51:12 +01:00
|
|
|
{
|
Improve our ability to regurgitate SQL-syntax function calls.
The SQL spec calls out nonstandard syntax for certain function calls,
for example substring() with numeric position info is supposed to be
spelled "SUBSTRING(string FROM start FOR count)". We accept many
of these things, but up to now would not print them in the same format,
instead simplifying down to "substring"(string, start, count).
That's long annoyed me because it creates an interoperability
problem: we're gratuitously injecting Postgres-specific syntax into
what might otherwise be a perfectly spec-compliant view definition.
However, the real reason for addressing it right now is to support
a planned change in the semantics of EXTRACT() a/k/a date_part().
When we switch that to returning numeric, we'll have the parser
translate EXTRACT() to some new function name (might as well be
"extract" if you ask me) and then teach ruleutils.c to reverse-list
that per SQL spec. In this way existing calls to date_part() will
continue to have the old semantics.
To implement this, invent a new CoercionForm value COERCE_SQL_SYNTAX,
and make the parser insert that rather than COERCE_EXPLICIT_CALL when
the input has SQL-spec decoration. (But if the input has the form of
a plain function call, continue to mark it COERCE_EXPLICIT_CALL, even
if it's calling one of these functions.) Then ruleutils.c recognizes
COERCE_SQL_SYNTAX as a cue to emit SQL call syntax. It can know
which decoration to emit using hard-wired knowledge about the
functions that could be called this way. (While this solution isn't
extensible without manual additions, neither is the grammar, so this
doesn't seem unmaintainable.) Notice that this solution will
reverse-list a function call with SQL decoration only if it was
entered that way; so dump-and-reload will not by itself produce any
changes in the appearance of views.
This requires adding a CoercionForm field to struct FuncCall.
(I couldn't resist the temptation to rearrange that struct's
field order a tad while I was at it.) FuncCall doesn't appear
in stored rules, so that change isn't a reason for a catversion
bump, but I did one anyway because the new enum value for
CoercionForm fields could confuse old backend code.
Possible future work:
* Perhaps CoercionForm should now be renamed to DisplayForm,
or something like that, to reflect its more general meaning.
This'd require touching a couple hundred places, so it's not
clear it's worth the code churn.
* The SQLValueFunction node type, which was invented partly for
the same goal of improving SQL-compatibility of view output,
could perhaps be replaced with regular function calls marked
with COERCE_SQL_SYNTAX. It's unclear if this would be a net
code savings, however.
Discussion: https://postgr.es/m/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-11-04 18:34:50 +01:00
|
|
|
/*
|
|
|
|
|
* Because we aren't restricting data types here, this
|
|
|
|
|
* syntax can end up resolving to textregexsubstr().
|
|
|
|
|
* We've historically allowed that to happen, so continue
|
|
|
|
|
* to accept it. However, ruleutils.c will reverse-list
|
|
|
|
|
* such a call in regular function call syntax.
|
|
|
|
|
*/
|
2020-06-29 10:36:52 +02:00
|
|
|
$$ = list_make2($1, $3);
|
2000-12-03 15:51:12 +01:00
|
|
|
}
|
2020-06-29 10:36:52 +02:00
|
|
|
| a_expr FOR a_expr
|
1997-09-26 17:09:11 +02:00
|
|
|
{
|
2020-06-29 10:36:52 +02:00
|
|
|
/* not legal per SQL */
|
|
|
|
|
|
2005-11-13 20:11:28 +01:00
|
|
|
/*
|
|
|
|
|
* Since there are no cases where this syntax allows
|
|
|
|
|
* a textual FOR value, we forcibly cast the argument
|
2007-08-21 17:13:42 +02:00
|
|
|
* to int4. The possible matches in pg_proc are
|
|
|
|
|
* substring(text,int4) and substring(text,text),
|
|
|
|
|
* and we don't want the parser to choose the latter,
|
|
|
|
|
* which it is likely to do if the second argument
|
|
|
|
|
* is unknown or doesn't have an implicit cast to int4.
|
2005-11-13 20:11:28 +01:00
|
|
|
*/
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = list_make3($1, makeIntConst(1, -1),
|
2020-06-29 10:36:52 +02:00
|
|
|
makeTypeCast($3,
|
2008-08-29 01:09:48 +02:00
|
|
|
SystemTypeName("int4"), -1));
|
2000-12-03 15:51:12 +01:00
|
|
|
}
|
2020-06-29 11:04:42 +02:00
|
|
|
| a_expr SIMILAR a_expr ESCAPE a_expr
|
|
|
|
|
{
|
|
|
|
|
$$ = list_make3($1, $3, $5);
|
|
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1997-09-01 08:00:35 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
trim_list: a_expr FROM expr_list { $$ = lappend($3, $1); }
|
|
|
|
|
| FROM expr_list { $$ = $2; }
|
|
|
|
|
| expr_list { $$ = $1; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
in_expr: select_with_parens
|
1997-10-25 07:56:41 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
SubLink *n = makeNode(SubLink);
|
|
|
|
|
|
1998-01-17 05:53:46 +01:00
|
|
|
n->subselect = $1;
|
2003-01-10 22:08:15 +01:00
|
|
|
/* other fields will be filled later */
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) n;
|
1997-10-25 07:56:41 +02:00
|
|
|
}
|
2022-05-13 07:17:29 +02:00
|
|
|
| '(' expr_list ')' { $$ = (Node *) $2; }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-11-30 04:38:09 +01:00
|
|
|
|
2004-09-30 02:24:27 +02:00
|
|
|
/*
|
2013-04-20 17:04:41 +02:00
|
|
|
* Define SQL-style CASE clause.
|
1998-12-04 16:34:49 +01:00
|
|
|
* - Full specification
|
2002-06-17 22:27:43 +02:00
|
|
|
* CASE WHEN a = b THEN c ... ELSE d END
|
1998-12-04 16:34:49 +01:00
|
|
|
* - Implicit argument
|
2002-06-17 22:27:43 +02:00
|
|
|
* CASE a WHEN b THEN c ... ELSE d END
|
1998-12-04 16:34:49 +01:00
|
|
|
*/
|
2003-02-10 05:44:47 +01:00
|
|
|
case_expr: CASE case_arg when_clause_list case_default END_P
|
1998-12-04 16:34:49 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
CaseExpr *c = makeNode(CaseExpr);
|
|
|
|
|
|
2004-03-17 21:48:43 +01:00
|
|
|
c->casetype = InvalidOid; /* not analyzed yet */
|
2002-12-12 16:49:42 +01:00
|
|
|
c->arg = (Expr *) $2;
|
1998-12-04 16:34:49 +01:00
|
|
|
c->args = $3;
|
2002-12-12 16:49:42 +01:00
|
|
|
c->defresult = (Expr *) $4;
|
2008-08-29 01:09:48 +02:00
|
|
|
c->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) c;
|
1998-12-04 16:34:49 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
when_clause_list:
|
2002-06-18 02:28:11 +02:00
|
|
|
/* There must be at least one */
|
2004-05-31 01:40:41 +02:00
|
|
|
when_clause { $$ = list_make1($1); }
|
2002-06-18 02:28:11 +02:00
|
|
|
| when_clause_list when_clause { $$ = lappend($1, $2); }
|
1998-12-04 16:34:49 +01:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
when_clause:
|
|
|
|
|
WHEN a_expr THEN a_expr
|
1998-12-04 16:34:49 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
CaseWhen *w = makeNode(CaseWhen);
|
|
|
|
|
|
2002-12-12 16:49:42 +01:00
|
|
|
w->expr = (Expr *) $2;
|
|
|
|
|
w->result = (Expr *) $4;
|
2008-08-29 01:09:48 +02:00
|
|
|
w->location = @1;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = (Node *) w;
|
1998-12-04 16:34:49 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
case_default:
|
|
|
|
|
ELSE a_expr { $$ = $2; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
1998-12-04 16:34:49 +01:00
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
case_arg: a_expr { $$ = $1; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
1998-12-04 16:34:49 +01:00
|
|
|
;
|
|
|
|
|
|
2009-11-06 00:24:27 +01:00
|
|
|
columnref: ColId
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2009-07-13 04:02:20 +02:00
|
|
|
$$ = makeColumnRef($1, NIL, @1, yyscanner);
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2009-11-06 00:24:27 +01:00
|
|
|
| ColId indirection
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2009-07-13 04:02:20 +02:00
|
|
|
$$ = makeColumnRef($1, $2, @1, yyscanner);
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2004-06-09 21:08:20 +02:00
|
|
|
indirection_el:
|
|
|
|
|
'.' attr_name
|
|
|
|
|
{
|
|
|
|
|
$$ = (Node *) makeString($2);
|
|
|
|
|
}
|
|
|
|
|
| '.' '*'
|
|
|
|
|
{
|
2008-08-30 03:39:14 +02:00
|
|
|
$$ = (Node *) makeNode(A_Star);
|
2004-06-09 21:08:20 +02:00
|
|
|
}
|
|
|
|
|
| '[' a_expr ']'
|
|
|
|
|
{
|
|
|
|
|
A_Indices *ai = makeNode(A_Indices);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2015-12-23 03:05:16 +01:00
|
|
|
ai->is_slice = false;
|
2004-06-09 21:08:20 +02:00
|
|
|
ai->lidx = NULL;
|
|
|
|
|
ai->uidx = $2;
|
|
|
|
|
$$ = (Node *) ai;
|
|
|
|
|
}
|
2015-12-23 03:05:16 +01:00
|
|
|
| '[' opt_slice_bound ':' opt_slice_bound ']'
|
2004-06-09 21:08:20 +02:00
|
|
|
{
|
|
|
|
|
A_Indices *ai = makeNode(A_Indices);
|
2022-05-13 07:17:29 +02:00
|
|
|
|
2015-12-23 03:05:16 +01:00
|
|
|
ai->is_slice = true;
|
2004-06-09 21:08:20 +02:00
|
|
|
ai->lidx = $2;
|
|
|
|
|
ai->uidx = $4;
|
|
|
|
|
$$ = (Node *) ai;
|
|
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
|
|
|
|
|
2015-12-23 03:05:16 +01:00
|
|
|
opt_slice_bound:
|
|
|
|
|
a_expr { $$ = $1; }
|
|
|
|
|
| /*EMPTY*/ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
2004-06-09 21:08:20 +02:00
|
|
|
indirection:
|
|
|
|
|
indirection_el { $$ = list_make1($1); }
|
|
|
|
|
| indirection indirection_el { $$ = lappend($1, $2); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
opt_indirection:
|
|
|
|
|
/*EMPTY*/ { $$ = NIL; }
|
|
|
|
|
| opt_indirection indirection_el { $$ = lappend($1, $2); }
|
2002-03-21 17:02:16 +01:00
|
|
|
;
|
|
|
|
|
|
2005-06-18 00:32:51 +02:00
|
|
|
opt_asymmetric: ASYMMETRIC
|
|
|
|
|
| /*EMPTY*/
|
|
|
|
|
;
|
|
|
|
|
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
/* SQL/JSON support */
|
|
|
|
|
json_value_expr:
|
|
|
|
|
a_expr json_format_clause_opt
|
|
|
|
|
{
|
|
|
|
|
$$ = (Node *) makeJsonValueExpr((Expr *) $1, castNode(JsonFormat, $2));
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
json_format_clause_opt:
|
|
|
|
|
FORMAT_LA JSON json_encoding_clause_opt
|
|
|
|
|
{
|
|
|
|
|
$$ = (Node *) makeJsonFormat(JS_FORMAT_JSON, $3, @1);
|
|
|
|
|
}
|
|
|
|
|
| /* EMPTY */
|
|
|
|
|
{
|
|
|
|
|
$$ = (Node *) makeJsonFormat(JS_FORMAT_DEFAULT, JS_ENC_DEFAULT, -1);
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
json_encoding_clause_opt:
|
|
|
|
|
ENCODING name { $$ = makeJsonEncoding($2); }
|
|
|
|
|
| /* EMPTY */ { $$ = JS_ENC_DEFAULT; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
json_output_clause_opt:
|
|
|
|
|
RETURNING Typename json_format_clause_opt
|
|
|
|
|
{
|
|
|
|
|
JsonOutput *n = makeNode(JsonOutput);
|
|
|
|
|
|
|
|
|
|
n->typeName = $2;
|
|
|
|
|
n->returning = makeNode(JsonReturning);
|
|
|
|
|
n->returning->format = (JsonFormat *) $3;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| /* EMPTY */ { $$ = NULL; }
|
|
|
|
|
;
|
|
|
|
|
|
SQL/JSON: support the IS JSON predicate
This patch introduces the SQL standard IS JSON predicate. It operates
on text and bytea values representing JSON, as well as on the json and
jsonb types. Each test has IS and IS NOT variants and supports a WITH
UNIQUE KEYS flag. The tests are:
IS JSON [VALUE]
IS JSON ARRAY
IS JSON OBJECT
IS JSON SCALAR
These should be self-explanatory.
The WITH UNIQUE KEYS flag makes these return false when duplicate keys
exist in any object within the value, not necessarily directly contained
in the outermost object.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Author: Andrew Dunstan <andrew@dunslane.net>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-31 22:34:04 +02:00
|
|
|
json_predicate_type_constraint:
|
|
|
|
|
JSON { $$ = JS_TYPE_ANY; }
|
|
|
|
|
| JSON VALUE_P { $$ = JS_TYPE_ANY; }
|
|
|
|
|
| JSON ARRAY { $$ = JS_TYPE_ARRAY; }
|
|
|
|
|
| JSON OBJECT_P { $$ = JS_TYPE_OBJECT; }
|
|
|
|
|
| JSON SCALAR { $$ = JS_TYPE_SCALAR; }
|
|
|
|
|
;
|
|
|
|
|
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
/* KEYS is a noise word here */
|
|
|
|
|
json_key_uniqueness_constraint_opt:
|
SQL/JSON: support the IS JSON predicate
This patch introduces the SQL standard IS JSON predicate. It operates
on text and bytea values representing JSON, as well as on the json and
jsonb types. Each test has IS and IS NOT variants and supports a WITH
UNIQUE KEYS flag. The tests are:
IS JSON [VALUE]
IS JSON ARRAY
IS JSON OBJECT
IS JSON SCALAR
These should be self-explanatory.
The WITH UNIQUE KEYS flag makes these return false when duplicate keys
exist in any object within the value, not necessarily directly contained
in the outermost object.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Author: Andrew Dunstan <andrew@dunslane.net>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-31 22:34:04 +02:00
|
|
|
WITH UNIQUE KEYS { $$ = true; }
|
|
|
|
|
| WITH UNIQUE { $$ = true; }
|
2023-04-04 14:04:30 +02:00
|
|
|
| WITHOUT UNIQUE KEYS { $$ = false; }
|
|
|
|
|
| WITHOUT UNIQUE { $$ = false; }
|
SQL/JSON: support the IS JSON predicate
This patch introduces the SQL standard IS JSON predicate. It operates
on text and bytea values representing JSON, as well as on the json and
jsonb types. Each test has IS and IS NOT variants and supports a WITH
UNIQUE KEYS flag. The tests are:
IS JSON [VALUE]
IS JSON ARRAY
IS JSON OBJECT
IS JSON SCALAR
These should be self-explanatory.
The WITH UNIQUE KEYS flag makes these return false when duplicate keys
exist in any object within the value, not necessarily directly contained
in the outermost object.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Author: Andrew Dunstan <andrew@dunslane.net>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-31 22:34:04 +02:00
|
|
|
| /* EMPTY */ %prec KEYS { $$ = false; }
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
json_name_and_value_list:
|
|
|
|
|
json_name_and_value
|
|
|
|
|
{ $$ = list_make1($1); }
|
|
|
|
|
| json_name_and_value_list ',' json_name_and_value
|
|
|
|
|
{ $$ = lappend($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
json_name_and_value:
|
|
|
|
|
/* Supporting this syntax seems to require major surgery
|
|
|
|
|
KEY c_expr VALUE_P json_value_expr
|
|
|
|
|
{ $$ = makeJsonKeyValue($2, $4); }
|
|
|
|
|
|
|
|
|
|
|
*/
|
|
|
|
|
c_expr VALUE_P json_value_expr
|
|
|
|
|
{ $$ = makeJsonKeyValue($1, $3); }
|
|
|
|
|
|
|
|
|
|
|
a_expr ':' json_value_expr
|
|
|
|
|
{ $$ = makeJsonKeyValue($1, $3); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/* empty means false for objects, true for arrays */
|
|
|
|
|
json_object_constructor_null_clause_opt:
|
|
|
|
|
NULL_P ON NULL_P { $$ = false; }
|
|
|
|
|
| ABSENT ON NULL_P { $$ = true; }
|
|
|
|
|
| /* EMPTY */ { $$ = false; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
json_array_constructor_null_clause_opt:
|
|
|
|
|
NULL_P ON NULL_P { $$ = false; }
|
|
|
|
|
| ABSENT ON NULL_P { $$ = true; }
|
|
|
|
|
| /* EMPTY */ { $$ = true; }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
json_value_expr_list:
|
|
|
|
|
json_value_expr { $$ = list_make1($1); }
|
|
|
|
|
| json_value_expr_list ',' json_value_expr { $$ = lappend($1, $3);}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
json_aggregate_func:
|
|
|
|
|
JSON_OBJECTAGG '('
|
|
|
|
|
json_name_and_value
|
|
|
|
|
json_object_constructor_null_clause_opt
|
|
|
|
|
json_key_uniqueness_constraint_opt
|
|
|
|
|
json_output_clause_opt
|
|
|
|
|
')'
|
|
|
|
|
{
|
|
|
|
|
JsonObjectAgg *n = makeNode(JsonObjectAgg);
|
|
|
|
|
|
|
|
|
|
n->arg = (JsonKeyValue *) $3;
|
|
|
|
|
n->absent_on_null = $4;
|
|
|
|
|
n->unique = $5;
|
|
|
|
|
n->constructor = makeNode(JsonAggConstructor);
|
|
|
|
|
n->constructor->output = (JsonOutput *) $6;
|
|
|
|
|
n->constructor->agg_order = NULL;
|
|
|
|
|
n->constructor->location = @1;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
| JSON_ARRAYAGG '('
|
|
|
|
|
json_value_expr
|
|
|
|
|
json_array_aggregate_order_by_clause_opt
|
|
|
|
|
json_array_constructor_null_clause_opt
|
|
|
|
|
json_output_clause_opt
|
|
|
|
|
')'
|
|
|
|
|
{
|
|
|
|
|
JsonArrayAgg *n = makeNode(JsonArrayAgg);
|
|
|
|
|
|
|
|
|
|
n->arg = (JsonValueExpr *) $3;
|
|
|
|
|
n->absent_on_null = $5;
|
|
|
|
|
n->constructor = makeNode(JsonAggConstructor);
|
|
|
|
|
n->constructor->agg_order = $4;
|
|
|
|
|
n->constructor->output = (JsonOutput *) $6;
|
|
|
|
|
n->constructor->location = @1;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
json_array_aggregate_order_by_clause_opt:
|
|
|
|
|
ORDER BY sortby_list { $$ = $3; }
|
|
|
|
|
| /* EMPTY */ { $$ = NIL; }
|
|
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
2006-09-04 00:37:06 +02:00
|
|
|
* target list for SELECT
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2013-12-15 02:23:26 +01:00
|
|
|
opt_target_list: target_list { $$ = $1; }
|
|
|
|
|
| /* EMPTY */ { $$ = NIL; }
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
target_list:
|
2004-05-31 01:40:41 +02:00
|
|
|
target_el { $$ = list_make1($1); }
|
2002-06-18 02:28:11 +02:00
|
|
|
| target_list ',' target_el { $$ = lappend($1, $3); }
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
target_el: a_expr AS ColLabel
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
|
|
|
|
$$ = makeNode(ResTarget);
|
|
|
|
|
$$->name = $3;
|
2002-03-21 17:02:16 +01:00
|
|
|
$$->indirection = NIL;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$->val = (Node *) $1;
|
2006-03-23 01:19:30 +01:00
|
|
|
$$->location = @1;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
| a_expr BareColLabel
|
2008-02-15 23:17:06 +01:00
|
|
|
{
|
|
|
|
|
$$ = makeNode(ResTarget);
|
|
|
|
|
$$->name = $2;
|
|
|
|
|
$$->indirection = NIL;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$->val = (Node *) $1;
|
2008-02-15 23:17:06 +01:00
|
|
|
$$->location = @1;
|
|
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| a_expr
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
|
|
|
|
$$ = makeNode(ResTarget);
|
|
|
|
|
$$->name = NULL;
|
2002-03-21 17:02:16 +01:00
|
|
|
$$->indirection = NIL;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$->val = (Node *) $1;
|
2006-03-23 01:19:30 +01:00
|
|
|
$$->location = @1;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| '*'
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
ColumnRef *n = makeNode(ColumnRef);
|
|
|
|
|
|
2008-08-30 03:39:14 +02:00
|
|
|
n->fields = list_make1(makeNode(A_Star));
|
2006-03-14 23:48:25 +01:00
|
|
|
n->location = @1;
|
2004-06-09 21:08:20 +02:00
|
|
|
|
1997-09-08 05:20:18 +02:00
|
|
|
$$ = makeNode(ResTarget);
|
|
|
|
|
$$->name = NULL;
|
2002-03-21 17:02:16 +01:00
|
|
|
$$->indirection = NIL;
|
2022-05-13 07:17:29 +02:00
|
|
|
$$->val = (Node *) n;
|
2006-03-23 01:19:30 +01:00
|
|
|
$$->location = @1;
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2002-04-05 13:56:55 +02:00
|
|
|
|
1999-07-17 00:29:42 +02:00
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* Names and constants
|
|
|
|
|
*
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
qualified_name_list:
|
2004-05-31 01:40:41 +02:00
|
|
|
qualified_name { $$ = list_make1($1); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| qualified_name_list ',' qualified_name { $$ = lappend($1, $3); }
|
2002-03-21 17:02:16 +01:00
|
|
|
;
|
|
|
|
|
|
2004-11-08 05:02:20 +01:00
|
|
|
/*
|
|
|
|
|
* The production for a qualified relation name has to exactly match the
|
|
|
|
|
* production for a qualified func_name, because in a FROM clause we cannot
|
|
|
|
|
* tell which we are parsing until we see what comes after it ('(' for a
|
|
|
|
|
* func_name, something else for a relation). Therefore we allow 'indirection'
|
|
|
|
|
* which may contain subscripts, and reject that case in the C code.
|
|
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
qualified_name:
|
2009-11-06 00:24:27 +01:00
|
|
|
ColId
|
2002-03-21 17:02:16 +01:00
|
|
|
{
|
2010-12-13 18:34:26 +01:00
|
|
|
$$ = makeRangeVar(NULL, $1, @1);
|
2002-03-21 17:02:16 +01:00
|
|
|
}
|
2009-11-06 00:24:27 +01:00
|
|
|
| ColId indirection
|
2002-03-21 17:02:16 +01:00
|
|
|
{
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
$$ = makeRangeVarFromQualifiedName($1, $2, @1, yyscanner);
|
2002-03-21 17:02:16 +01:00
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
2002-06-18 19:56:41 +02:00
|
|
|
name_list: name
|
2004-05-31 01:40:41 +02:00
|
|
|
{ $$ = list_make1(makeString($1)); }
|
2002-06-18 19:56:41 +02:00
|
|
|
| name_list ',' name
|
|
|
|
|
{ $$ = lappend($1, makeString($3)); }
|
2002-03-21 17:02:16 +01:00
|
|
|
;
|
|
|
|
|
|
1997-09-08 05:20:18 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
name: ColId { $$ = $1; };
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2004-08-24 22:41:40 +02:00
|
|
|
attr_name: ColLabel { $$ = $1; };
|
2002-06-17 22:27:43 +02:00
|
|
|
|
|
|
|
|
file_name: Sconst { $$ = $1; };
|
|
|
|
|
|
2004-06-09 21:08:20 +02:00
|
|
|
/*
|
|
|
|
|
* The production for a qualified func_name has to exactly match the
|
|
|
|
|
* production for a qualified columnref, because we cannot tell which we
|
2006-12-30 22:21:56 +01:00
|
|
|
* are parsing until we see what comes after it ('(' or Sconst for a func_name,
|
2004-06-09 21:08:20 +02:00
|
|
|
* anything else for a columnref). Therefore we allow 'indirection' which
|
|
|
|
|
* may contain subscripts, and reject that case in the C code. (If we
|
|
|
|
|
* ever implement SQL99-like methods, such syntax may actually become legal!)
|
|
|
|
|
*/
|
2006-12-30 22:21:56 +01:00
|
|
|
func_name: type_function_name
|
2004-05-31 01:40:41 +02:00
|
|
|
{ $$ = list_make1(makeString($1)); }
|
2009-11-06 00:24:27 +01:00
|
|
|
| ColId indirection
|
2009-07-13 04:02:20 +02:00
|
|
|
{
|
|
|
|
|
$$ = check_func_name(lcons(makeString($1), $2),
|
|
|
|
|
yyscanner);
|
|
|
|
|
}
|
2002-03-29 20:06:29 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
2002-08-04 08:51:23 +02:00
|
|
|
/*
|
|
|
|
|
* Constants
|
1997-10-25 07:56:41 +02:00
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
AexprConst: Iconst
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeIntConst($1, @1);
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| FCONST
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeFloatConst($1, @1);
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| Sconst
|
1997-09-08 05:20:18 +02:00
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeStringConst($1, @1);
|
1997-09-08 05:20:18 +02:00
|
|
|
}
|
2002-08-04 08:51:23 +02:00
|
|
|
| BCONST
|
2000-10-31 11:22:13 +01:00
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeBitStringConst($1, @1);
|
2000-10-31 11:22:13 +01:00
|
|
|
}
|
2002-08-04 08:51:23 +02:00
|
|
|
| XCONST
|
|
|
|
|
{
|
|
|
|
|
/* This is a bit constant per SQL99:
|
|
|
|
|
* Without Feature F511, "BIT data type",
|
|
|
|
|
* a <general literal> shall not be a
|
|
|
|
|
* <bit string literal> or a <hex string literal>.
|
|
|
|
|
*/
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeBitStringConst($1, @1);
|
2002-08-04 08:51:23 +02:00
|
|
|
}
|
2006-12-30 22:21:56 +01:00
|
|
|
| func_name Sconst
|
|
|
|
|
{
|
|
|
|
|
/* generic type 'literal' syntax */
|
2022-05-13 07:17:29 +02:00
|
|
|
TypeName *t = makeTypeNameFromNameList($1);
|
|
|
|
|
|
2008-04-29 16:59:17 +02:00
|
|
|
t->location = @1;
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeStringConstCast($2, @2, t);
|
2006-12-30 22:21:56 +01:00
|
|
|
}
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
| func_name '(' func_arg_list opt_sort_clause ')' Sconst
|
2006-12-30 22:21:56 +01:00
|
|
|
{
|
|
|
|
|
/* generic syntax with a type modifier */
|
2022-05-13 07:17:29 +02:00
|
|
|
TypeName *t = makeTypeNameFromNameList($1);
|
|
|
|
|
ListCell *lc;
|
2009-10-08 04:39:25 +02:00
|
|
|
|
|
|
|
|
/*
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
* We must use func_arg_list and opt_sort_clause in the
|
|
|
|
|
* production to avoid reduce/reduce conflicts, but we
|
|
|
|
|
* don't actually wish to allow NamedArgExpr in this
|
|
|
|
|
* context, nor ORDER BY.
|
2009-10-08 04:39:25 +02:00
|
|
|
*/
|
|
|
|
|
foreach(lc, $3)
|
|
|
|
|
{
|
|
|
|
|
NamedArgExpr *arg = (NamedArgExpr *) lfirst(lc);
|
|
|
|
|
|
|
|
|
|
if (IsA(arg, NamedArgExpr))
|
|
|
|
|
ereport(ERROR,
|
2011-11-01 20:50:00 +01:00
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("type modifier cannot have parameter name"),
|
|
|
|
|
parser_errposition(arg->location)));
|
2009-10-08 04:39:25 +02:00
|
|
|
}
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
if ($4 != NIL)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("type modifier cannot have ORDER BY"),
|
|
|
|
|
parser_errposition(@4)));
|
|
|
|
|
|
2008-04-29 16:59:17 +02:00
|
|
|
t->typmods = $3;
|
|
|
|
|
t->location = @1;
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
$$ = makeStringConstCast($6, @6, t);
|
2006-12-30 22:21:56 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| ConstTypename Sconst
|
2000-07-14 17:43:57 +02:00
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeStringConstCast($2, @2, $1);
|
2000-07-14 17:43:57 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| ConstInterval Sconst opt_interval
|
1997-11-17 17:37:24 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
TypeName *t = $1;
|
|
|
|
|
|
2008-09-11 17:27:30 +02:00
|
|
|
t->typmods = $3;
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeStringConstCast($2, @2, t);
|
2001-10-18 19:30:21 +02:00
|
|
|
}
|
2014-10-18 16:31:00 +02:00
|
|
|
| ConstInterval '(' Iconst ')' Sconst
|
2001-10-18 19:30:21 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
TypeName *t = $1;
|
|
|
|
|
|
2014-10-18 16:31:00 +02:00
|
|
|
t->typmods = list_make2(makeIntConst(INTERVAL_FULL_RANGE, -1),
|
|
|
|
|
makeIntConst($3, @3));
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeStringConstCast($5, @5, t);
|
1997-11-17 17:37:24 +01:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| TRUE_P
|
1997-10-25 07:56:41 +02:00
|
|
|
{
|
2017-08-16 06:22:32 +02:00
|
|
|
$$ = makeBoolAConst(true, @1);
|
1997-10-25 07:56:41 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| FALSE_P
|
1997-10-25 07:56:41 +02:00
|
|
|
{
|
2017-08-16 06:22:32 +02:00
|
|
|
$$ = makeBoolAConst(false, @1);
|
1997-10-25 07:56:41 +02:00
|
|
|
}
|
2002-06-17 22:27:43 +02:00
|
|
|
| NULL_P
|
2000-03-12 01:39:52 +01:00
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
$$ = makeNullAConst(@1);
|
2000-03-12 01:39:52 +01:00
|
|
|
}
|
1997-09-08 05:20:18 +02:00
|
|
|
;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-06-17 22:27:43 +02:00
|
|
|
Iconst: ICONST { $$ = $1; };
|
|
|
|
|
Sconst: SCONST { $$ = $1; };
|
2014-01-22 04:49:22 +01:00
|
|
|
|
2008-11-12 16:50:20 +01:00
|
|
|
SignedIconst: Iconst { $$ = $1; }
|
|
|
|
|
| '+' Iconst { $$ = + $2; }
|
|
|
|
|
| '-' Iconst { $$ = - $2; }
|
2005-07-31 19:19:22 +02:00
|
|
|
;
|
|
|
|
|
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
/* Role specifications */
|
|
|
|
|
RoleId: RoleSpec
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
RoleSpec *spc = (RoleSpec *) $1;
|
|
|
|
|
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
switch (spc->roletype)
|
|
|
|
|
{
|
|
|
|
|
case ROLESPEC_CSTRING:
|
|
|
|
|
$$ = spc->rolename;
|
|
|
|
|
break;
|
|
|
|
|
case ROLESPEC_PUBLIC:
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_RESERVED_NAME),
|
|
|
|
|
errmsg("role name \"%s\" is reserved",
|
|
|
|
|
"public"),
|
|
|
|
|
parser_errposition(@1)));
|
2018-05-02 01:35:08 +02:00
|
|
|
break;
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
case ROLESPEC_SESSION_USER:
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_RESERVED_NAME),
|
2015-04-30 21:57:05 +02:00
|
|
|
errmsg("%s cannot be used as a role name here",
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
"SESSION_USER"),
|
|
|
|
|
parser_errposition(@1)));
|
2018-05-02 01:35:08 +02:00
|
|
|
break;
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
case ROLESPEC_CURRENT_USER:
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_RESERVED_NAME),
|
2015-04-30 21:57:05 +02:00
|
|
|
errmsg("%s cannot be used as a role name here",
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
"CURRENT_USER"),
|
|
|
|
|
parser_errposition(@1)));
|
2018-05-02 01:35:08 +02:00
|
|
|
break;
|
2020-09-17 11:39:28 +02:00
|
|
|
case ROLESPEC_CURRENT_ROLE:
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_RESERVED_NAME),
|
|
|
|
|
errmsg("%s cannot be used as a role name here",
|
|
|
|
|
"CURRENT_ROLE"),
|
|
|
|
|
parser_errposition(@1)));
|
|
|
|
|
break;
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
RoleSpec: NonReservedWord
|
2022-05-13 07:17:29 +02:00
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* "public" and "none" are not keywords, but they must
|
|
|
|
|
* be treated specially here.
|
|
|
|
|
*/
|
|
|
|
|
RoleSpec *n;
|
|
|
|
|
|
|
|
|
|
if (strcmp($1, "public") == 0)
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
n = (RoleSpec *) makeRoleSpec(ROLESPEC_PUBLIC, @1);
|
|
|
|
|
n->roletype = ROLESPEC_PUBLIC;
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
}
|
2022-05-13 07:17:29 +02:00
|
|
|
else if (strcmp($1, "none") == 0)
|
2020-09-17 11:39:28 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_RESERVED_NAME),
|
|
|
|
|
errmsg("role name \"%s\" is reserved",
|
|
|
|
|
"none"),
|
|
|
|
|
parser_errposition(@1)));
|
2020-09-17 11:39:28 +02:00
|
|
|
}
|
2022-05-13 07:17:29 +02:00
|
|
|
else
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
n = makeRoleSpec(ROLESPEC_CSTRING, @1);
|
|
|
|
|
n->rolename = pstrdup($1);
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
}
|
2022-05-13 07:17:29 +02:00
|
|
|
$$ = n;
|
|
|
|
|
}
|
|
|
|
|
| CURRENT_ROLE
|
|
|
|
|
{
|
|
|
|
|
$$ = makeRoleSpec(ROLESPEC_CURRENT_ROLE, @1);
|
|
|
|
|
}
|
|
|
|
|
| CURRENT_USER
|
|
|
|
|
{
|
|
|
|
|
$$ = makeRoleSpec(ROLESPEC_CURRENT_USER, @1);
|
|
|
|
|
}
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
| SESSION_USER
|
2022-05-13 07:17:29 +02:00
|
|
|
{
|
|
|
|
|
$$ = makeRoleSpec(ROLESPEC_SESSION_USER, @1);
|
|
|
|
|
}
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
role_list: RoleSpec
|
2022-05-13 07:17:29 +02:00
|
|
|
{ $$ = list_make1($1); }
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
| role_list ',' RoleSpec
|
2022-05-13 07:17:29 +02:00
|
|
|
{ $$ = lappend($1, $3); }
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
;
|
|
|
|
|
|
2021-01-04 17:52:00 +01:00
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* PL/pgSQL extensions
|
|
|
|
|
*
|
|
|
|
|
* You'd think a PL/pgSQL "expression" should be just an a_expr, but
|
|
|
|
|
* historically it can include just about anything that can follow SELECT.
|
|
|
|
|
* Therefore the returned struct is a SelectStmt.
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2021-01-22 22:26:22 +01:00
|
|
|
PLpgSQL_Expr: opt_distinct_clause opt_target_list
|
2021-01-04 17:52:00 +01:00
|
|
|
from_clause where_clause
|
|
|
|
|
group_clause having_clause window_clause
|
|
|
|
|
opt_sort_clause opt_select_limit opt_for_locking_clause
|
|
|
|
|
{
|
|
|
|
|
SelectStmt *n = makeNode(SelectStmt);
|
|
|
|
|
|
2021-01-22 22:26:22 +01:00
|
|
|
n->distinctClause = $1;
|
|
|
|
|
n->targetList = $2;
|
|
|
|
|
n->fromClause = $3;
|
|
|
|
|
n->whereClause = $4;
|
Implement GROUP BY DISTINCT
With grouping sets, it's possible that some of the grouping sets are
duplicate. This is especially common with CUBE and ROLLUP clauses. For
example GROUP BY CUBE (a,b), CUBE (b,c) is equivalent to
GROUP BY GROUPING SETS (
(a, b, c),
(a, b, c),
(a, b, c),
(a, b),
(a, b),
(a, b),
(a),
(a),
(a),
(c, a),
(c, a),
(c, a),
(c),
(b, c),
(b),
()
)
Some of the grouping sets are calculated multiple times, which is mostly
unnecessary. This commit implements a new GROUP BY DISTINCT feature, as
defined in the SQL standard, which eliminates the duplicate sets.
Author: Vik Fearing
Reviewed-by: Erik Rijkers, Georgios Kokolatos, Tomas Vondra
Discussion: https://postgr.es/m/bf3805a8-d7d1-ae61-fece-761b7ff41ecc@postgresfriends.org
2021-03-18 17:45:38 +01:00
|
|
|
n->groupClause = ($5)->list;
|
|
|
|
|
n->groupDistinct = ($5)->distinct;
|
2021-01-22 22:26:22 +01:00
|
|
|
n->havingClause = $6;
|
|
|
|
|
n->windowClause = $7;
|
|
|
|
|
n->sortClause = $8;
|
|
|
|
|
if ($9)
|
2021-01-04 17:52:00 +01:00
|
|
|
{
|
2021-01-22 22:26:22 +01:00
|
|
|
n->limitOffset = $9->limitOffset;
|
|
|
|
|
n->limitCount = $9->limitCount;
|
2021-01-04 17:52:00 +01:00
|
|
|
if (!n->sortClause &&
|
2021-01-22 22:26:22 +01:00
|
|
|
$9->limitOption == LIMIT_OPTION_WITH_TIES)
|
2021-01-04 17:52:00 +01:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("WITH TIES cannot be specified without ORDER BY clause")));
|
2021-01-22 22:26:22 +01:00
|
|
|
n->limitOption = $9->limitOption;
|
2021-01-04 17:52:00 +01:00
|
|
|
}
|
2021-01-22 22:26:22 +01:00
|
|
|
n->lockingClause = $10;
|
2021-01-04 17:52:00 +01:00
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* PL/pgSQL Assignment statement: name opt_indirection := PLpgSQL_Expr
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
PLAssignStmt: plassign_target opt_indirection plassign_equals PLpgSQL_Expr
|
|
|
|
|
{
|
|
|
|
|
PLAssignStmt *n = makeNode(PLAssignStmt);
|
|
|
|
|
|
|
|
|
|
n->name = $1;
|
|
|
|
|
n->indirection = check_indirection($2, yyscanner);
|
|
|
|
|
/* nnames will be filled by calling production */
|
|
|
|
|
n->val = (SelectStmt *) $4;
|
|
|
|
|
n->location = @1;
|
|
|
|
|
$$ = (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
plassign_target: ColId { $$ = $1; }
|
|
|
|
|
| PARAM { $$ = psprintf("$%d", $1); }
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
plassign_equals: COLON_EQUALS
|
|
|
|
|
| '='
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
2001-11-16 05:08:33 +01:00
|
|
|
/*
|
|
|
|
|
* Name classification hierarchy.
|
|
|
|
|
*
|
|
|
|
|
* IDENT is the lexeme returned by the lexer for identifiers that match
|
|
|
|
|
* no known keyword. In most cases, we can accept certain keywords as
|
2002-06-17 22:27:43 +02:00
|
|
|
* names, not only IDENTs. We prefer to accept as many such keywords
|
2001-11-16 05:08:33 +01:00
|
|
|
* as possible to minimize the impact of "reserved words" on programmers.
|
|
|
|
|
* So, we divide names into several possible classes. The classification
|
|
|
|
|
* is chosen in part to make keywords acceptable as names wherever possible.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* Column identifier --- names that can be column, table, etc names.
|
|
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
ColId: IDENT { $$ = $1; }
|
|
|
|
|
| unreserved_keyword { $$ = pstrdup($1); }
|
|
|
|
|
| col_name_keyword { $$ = pstrdup($1); }
|
2001-11-16 05:08:33 +01:00
|
|
|
;
|
|
|
|
|
|
2006-12-30 22:21:56 +01:00
|
|
|
/* Type/function identifier --- names that can be type or function names.
|
2001-11-16 05:08:33 +01:00
|
|
|
*/
|
2006-12-30 22:21:56 +01:00
|
|
|
type_function_name: IDENT { $$ = $1; }
|
2002-06-17 22:27:43 +02:00
|
|
|
| unreserved_keyword { $$ = pstrdup($1); }
|
2006-12-30 22:21:56 +01:00
|
|
|
| type_func_name_keyword { $$ = pstrdup($1); }
|
2001-11-16 05:08:33 +01:00
|
|
|
;
|
|
|
|
|
|
2013-06-03 02:09:20 +02:00
|
|
|
/* Any not-fully-reserved word --- these names can be, eg, role names.
|
|
|
|
|
*/
|
|
|
|
|
NonReservedWord: IDENT { $$ = $1; }
|
|
|
|
|
| unreserved_keyword { $$ = pstrdup($1); }
|
|
|
|
|
| col_name_keyword { $$ = pstrdup($1); }
|
|
|
|
|
| type_func_name_keyword { $$ = pstrdup($1); }
|
|
|
|
|
;
|
|
|
|
|
|
2001-11-16 05:08:33 +01:00
|
|
|
/* Column label --- allowed labels in "AS" clauses.
|
|
|
|
|
* This presently includes *all* Postgres keywords.
|
|
|
|
|
*/
|
2002-06-17 22:27:43 +02:00
|
|
|
ColLabel: IDENT { $$ = $1; }
|
|
|
|
|
| unreserved_keyword { $$ = pstrdup($1); }
|
|
|
|
|
| col_name_keyword { $$ = pstrdup($1); }
|
2006-12-30 22:21:56 +01:00
|
|
|
| type_func_name_keyword { $$ = pstrdup($1); }
|
2002-06-17 22:27:43 +02:00
|
|
|
| reserved_keyword { $$ = pstrdup($1); }
|
2001-11-16 05:08:33 +01:00
|
|
|
;
|
|
|
|
|
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
/* Bare column label --- names that can be column labels without writing "AS".
|
|
|
|
|
* This classification is orthogonal to the other keyword categories.
|
|
|
|
|
*/
|
|
|
|
|
BareColLabel: IDENT { $$ = $1; }
|
|
|
|
|
| bare_label_keyword { $$ = pstrdup($1); }
|
|
|
|
|
;
|
|
|
|
|
|
2001-11-16 05:08:33 +01:00
|
|
|
|
2001-11-10 23:31:49 +01:00
|
|
|
/*
|
2007-06-18 23:40:58 +02:00
|
|
|
* Keyword category lists. Generally, every keyword present in
|
2001-11-16 05:08:33 +01:00
|
|
|
* the Postgres grammar should appear in exactly one of these lists.
|
2001-11-10 23:31:49 +01:00
|
|
|
*
|
2001-11-16 05:08:33 +01:00
|
|
|
* Put a new keyword into the first list that it can go into without causing
|
|
|
|
|
* shift or reduce conflicts. The earlier lists define "less reserved"
|
|
|
|
|
* categories of keywords.
|
2007-06-18 23:40:58 +02:00
|
|
|
*
|
2011-02-10 21:49:46 +01:00
|
|
|
* Make sure that each keyword's category in kwlist.h matches where
|
2007-06-18 23:40:58 +02:00
|
|
|
* it is listed here. (Someday we may be able to generate these lists and
|
2020-06-15 19:14:40 +02:00
|
|
|
* kwlist.h's table from one source of truth.)
|
1997-10-09 07:00:54 +02:00
|
|
|
*/
|
2000-04-07 15:40:45 +02:00
|
|
|
|
2001-11-16 05:08:33 +01:00
|
|
|
/* "Unreserved" keywords --- available for use as any kind of name.
|
2000-04-07 15:40:45 +02:00
|
|
|
*/
|
2001-11-16 05:08:33 +01:00
|
|
|
unreserved_keyword:
|
2003-02-10 05:44:47 +01:00
|
|
|
ABORT_P
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
| ABSENT
|
2003-05-15 18:35:30 +02:00
|
|
|
| ABSOLUTE_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| ACCESS
|
|
|
|
|
| ACTION
|
2005-12-27 05:00:08 +01:00
|
|
|
| ADD_P
|
2005-06-28 21:51:26 +02:00
|
|
|
| ADMIN
|
2002-06-17 22:27:43 +02:00
|
|
|
| AFTER
|
|
|
|
|
| AGGREGATE
|
2004-07-12 07:38:11 +02:00
|
|
|
| ALSO
|
2002-06-17 22:27:43 +02:00
|
|
|
| ALTER
|
2007-03-20 00:38:32 +01:00
|
|
|
| ALWAYS
|
2021-04-07 07:49:27 +02:00
|
|
|
| ASENSITIVE
|
2002-06-17 22:27:43 +02:00
|
|
|
| ASSERTION
|
2002-06-22 04:04:55 +02:00
|
|
|
| ASSIGNMENT
|
2002-06-17 22:27:43 +02:00
|
|
|
| AT
|
2021-04-07 21:30:08 +02:00
|
|
|
| ATOMIC
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
| ATTACH
|
2010-09-26 13:41:03 +02:00
|
|
|
| ATTRIBUTE
|
2002-06-17 22:27:43 +02:00
|
|
|
| BACKWARD
|
|
|
|
|
| BEFORE
|
2003-02-10 05:44:47 +01:00
|
|
|
| BEGIN_P
|
2021-02-01 13:54:59 +01:00
|
|
|
| BREADTH
|
2002-06-17 22:27:43 +02:00
|
|
|
| BY
|
|
|
|
|
| CACHE
|
2017-11-30 14:46:13 +01:00
|
|
|
| CALL
|
2002-06-17 22:27:43 +02:00
|
|
|
| CALLED
|
|
|
|
|
| CASCADE
|
2006-05-27 19:38:46 +02:00
|
|
|
| CASCADED
|
2008-10-27 10:37:47 +01:00
|
|
|
| CATALOG_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| CHAIN
|
|
|
|
|
| CHARACTERISTICS
|
|
|
|
|
| CHECKPOINT
|
2002-07-30 00:14:11 +02:00
|
|
|
| CLASS
|
2002-06-17 22:27:43 +02:00
|
|
|
| CLOSE
|
|
|
|
|
| CLUSTER
|
2017-03-08 16:39:37 +01:00
|
|
|
| COLUMNS
|
2002-06-17 22:27:43 +02:00
|
|
|
| COMMENT
|
2009-10-12 21:49:24 +02:00
|
|
|
| COMMENTS
|
2002-06-17 22:27:43 +02:00
|
|
|
| COMMIT
|
|
|
|
|
| COMMITTED
|
Allow configurable LZ4 TOAST compression.
There is now a per-column COMPRESSION option which can be set to pglz
(the default, and the only option in up until now) or lz4. Or, if you
like, you can set the new default_toast_compression GUC to lz4, and
then that will be the default for new table columns for which no value
is specified. We don't have lz4 support in the PostgreSQL code, so
to use lz4 compression, PostgreSQL must be built --with-lz4.
In general, TOAST compression means compression of individual column
values, not the whole tuple, and those values can either be compressed
inline within the tuple or compressed and then stored externally in
the TOAST table, so those properties also apply to this feature.
Prior to this commit, a TOAST pointer has two unused bits as part of
the va_extsize field, and a compessed datum has two unused bits as
part of the va_rawsize field. These bits are unused because the length
of a varlena is limited to 1GB; we now use them to indicate the
compression type that was used. This means we only have bit space for
2 more built-in compresison types, but we could work around that
problem, if necessary, by introducing a new vartag_external value for
any further types we end up wanting to add. Hopefully, it won't be
too important to offer a wide selection of algorithms here, since
each one we add not only takes more coding but also adds a build
dependency for every packager. Nevertheless, it seems worth doing
at least this much, because LZ4 gets better compression than PGLZ
with less CPU usage.
It's possible for LZ4-compressed datums to leak into composite type
values stored on disk, just as it is for PGLZ. It's also possible for
LZ4-compressed attributes to be copied into a different table via SQL
commands such as CREATE TABLE AS or INSERT .. SELECT. It would be
expensive to force such values to be decompressed, so PostgreSQL has
never done so. For the same reasons, we also don't force recompression
of already-compressed values even if the target table prefers a
different compression method than was used for the source data. These
architectural decisions are perhaps arguable but revisiting them is
well beyond the scope of what seemed possible to do as part of this
project. However, it's relatively cheap to recompress as part of
VACUUM FULL or CLUSTER, so this commit adjusts those commands to do
so, if the configured compression method of the table happens not to
match what was used for some column value stored therein.
Dilip Kumar. The original patches on which this work was based were
written by Ildus Kurbangaliev, and those were patches were based on
even earlier work by Nikita Glukhov, but the design has since changed
very substantially, since allow a potentially large number of
compression methods that could be added and dropped on a running
system proved too problematic given some of the architectural issues
mentioned above; the choice of which specific compression method to
add first is now different; and a lot of the code has been heavily
refactored. More recently, Justin Przyby helped quite a bit with
testing and reviewing and this version also includes some code
contributions from him. Other design input and review from Tomas
Vondra, Álvaro Herrera, Andres Freund, Oleg Bartunov, Alexander
Korotkov, and me.
Discussion: http://postgr.es/m/20170907194236.4cefce96%40wp.localdomain
Discussion: http://postgr.es/m/CAFiTN-uUpX3ck%3DK0mLEk-G_kUQY%3DSNOTeqdaNRR9FMdQrHKebw%40mail.gmail.com
2021-03-19 20:10:38 +01:00
|
|
|
| COMPRESSION
|
2007-08-21 03:11:32 +02:00
|
|
|
| CONFIGURATION
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
| CONFLICT
|
2005-07-31 19:19:22 +02:00
|
|
|
| CONNECTION
|
2002-06-17 22:27:43 +02:00
|
|
|
| CONSTRAINTS
|
2006-12-24 01:29:20 +01:00
|
|
|
| CONTENT_P
|
2008-05-17 01:36:05 +02:00
|
|
|
| CONTINUE_P
|
2002-07-12 20:43:19 +02:00
|
|
|
| CONVERSION_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| COPY
|
2007-01-22 02:35:23 +01:00
|
|
|
| COST
|
2004-04-19 19:22:31 +02:00
|
|
|
| CSV
|
Support GROUPING SETS, CUBE and ROLLUP.
This SQL standard functionality allows to aggregate data by different
GROUP BY clauses at once. Each grouping set returns rows with columns
grouped by in other sets set to NULL.
This could previously be achieved by doing each grouping as a separate
query, conjoined by UNION ALLs. Besides being considerably more concise,
grouping sets will in many cases be faster, requiring only one scan over
the underlying data.
The current implementation of grouping sets only supports using sorting
for input. Individual sets that share a sort order are computed in one
pass. If there are sets that don't share a sort order, additional sort &
aggregation steps are performed. These additional passes are sourced by
the previous sort step; thus avoiding repeated scans of the source data.
The code is structured in a way that adding support for purely using
hash aggregation or a mix of hashing and sorting is possible. Sorting
was chosen to be supported first, as it is the most generic method of
implementation.
Instead of, as in an earlier versions of the patch, representing the
chain of sort and aggregation steps as full blown planner and executor
nodes, all but the first sort are performed inside the aggregation node
itself. This avoids the need to do some unusual gymnastics to handle
having to return aggregated and non-aggregated tuples from underlying
nodes, as well as having to shut down underlying nodes early to limit
memory usage. The optimizer still builds Sort/Agg node to describe each
phase, but they're not part of the plan tree, but instead additional
data for the aggregation node. They're a convenient and preexisting way
to describe aggregation and sorting. The first (and possibly only) sort
step is still performed as a separate execution step. That retains
similarity with existing group by plans, makes rescans fairly simple,
avoids very deep plans (leading to slow explains) and easily allows to
avoid the sorting step if the underlying data is sorted by other means.
A somewhat ugly side of this patch is having to deal with a grammar
ambiguity between the new CUBE keyword and the cube extension/functions
named cube (and rollup). To avoid breaking existing deployments of the
cube extension it has not been renamed, neither has cube been made a
reserved keyword. Instead precedence hacking is used to make GROUP BY
cube(..) refer to the CUBE grouping sets feature, and not the function
cube(). To actually group by a function cube(), unlikely as that might
be, the function name has to be quoted.
Needs a catversion bump because stored rules may change.
Author: Andrew Gierth and Atri Sharma, with contributions from Andres Freund
Reviewed-By: Andres Freund, Noah Misch, Tom Lane, Svenne Krap, Tomas
Vondra, Erik Rijkers, Marti Raudsepp, Pavel Stehule
Discussion: CAOeZVidmVRe2jU6aMk_5qkxnB7dfmPROzM7Ur8JPW5j8Y5X-Lw@mail.gmail.com
2015-05-16 03:40:59 +02:00
|
|
|
| CUBE
|
2007-06-11 03:16:30 +02:00
|
|
|
| CURRENT_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| CURSOR
|
|
|
|
|
| CYCLE
|
2008-10-21 10:38:16 +02:00
|
|
|
| DATA_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| DATABASE
|
|
|
|
|
| DAY_P
|
2002-08-27 06:55:12 +02:00
|
|
|
| DEALLOCATE
|
2002-06-17 22:27:43 +02:00
|
|
|
| DECLARE
|
2003-06-25 05:40:19 +02:00
|
|
|
| DEFAULTS
|
2002-06-17 22:27:43 +02:00
|
|
|
| DEFERRED
|
|
|
|
|
| DEFINER
|
|
|
|
|
| DELETE_P
|
2002-06-20 18:00:44 +02:00
|
|
|
| DELIMITER
|
2002-06-17 22:27:43 +02:00
|
|
|
| DELIMITERS
|
2016-04-05 23:38:54 +02:00
|
|
|
| DEPENDS
|
2021-02-01 13:54:59 +01:00
|
|
|
| DEPTH
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
| DETACH
|
2007-08-21 03:11:32 +02:00
|
|
|
| DICTIONARY
|
2005-08-24 00:40:47 +02:00
|
|
|
| DISABLE_P
|
2007-04-26 18:13:15 +02:00
|
|
|
| DISCARD
|
2006-12-24 01:29:20 +01:00
|
|
|
| DOCUMENT_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| DOMAIN_P
|
2003-05-15 18:35:30 +02:00
|
|
|
| DOUBLE_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| DROP
|
|
|
|
|
| EACH
|
2005-08-24 00:40:47 +02:00
|
|
|
| ENABLE_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| ENCODING
|
|
|
|
|
| ENCRYPTED
|
2007-04-02 05:49:42 +02:00
|
|
|
| ENUM_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| ESCAPE
|
2012-09-27 02:07:36 +02:00
|
|
|
| EVENT
|
2009-12-07 06:22:23 +01:00
|
|
|
| EXCLUDE
|
2003-06-25 05:40:19 +02:00
|
|
|
| EXCLUDING
|
2002-06-17 22:27:43 +02:00
|
|
|
| EXCLUSIVE
|
|
|
|
|
| EXECUTE
|
|
|
|
|
| EXPLAIN
|
2020-01-14 13:09:31 +01:00
|
|
|
| EXPRESSION
|
2011-02-08 22:08:41 +01:00
|
|
|
| EXTENSION
|
2002-06-17 22:27:43 +02:00
|
|
|
| EXTERNAL
|
2007-01-23 06:07:18 +01:00
|
|
|
| FAMILY
|
2013-07-17 02:15:36 +02:00
|
|
|
| FILTER
|
ALTER TABLE ... DETACH PARTITION ... CONCURRENTLY
Allow a partition be detached from its partitioned table without
blocking concurrent queries, by running in two transactions and only
requiring ShareUpdateExclusive in the partitioned table.
Because it runs in two transactions, it cannot be used in a transaction
block. This is the main reason to use dedicated syntax: so that users
can choose to use the original mode if they need it. But also, it
doesn't work when a default partition exists (because an exclusive lock
would still need to be obtained on it, in order to change its partition
constraint.)
In case the second transaction is cancelled or a crash occurs, there's
ALTER TABLE .. DETACH PARTITION .. FINALIZE, which executes the final
steps.
The main trick to make this work is the addition of column
pg_inherits.inhdetachpending, initially false; can only be set true in
the first part of this command. Once that is committed, concurrent
transactions that use a PartitionDirectory will include or ignore
partitions so marked: in optimizer they are ignored if the row is marked
committed for the snapshot; in executor they are always included. As a
result, and because of the way PartitionDirectory caches partition
descriptors, queries that were planned before the detach will see the
rows in the detached partition and queries that are planned after the
detach, won't.
A CHECK constraint is created that duplicates the partition constraint.
This is probably not strictly necessary, and some users will prefer to
remove it afterwards, but if the partition is re-attached to a
partitioned table, the constraint needn't be rechecked.
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Reviewed-by: Amit Langote <amitlangote09@gmail.com>
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>
Discussion: https://postgr.es/m/20200803234854.GA24158@alvherre.pgsql
2021-03-25 22:00:28 +01:00
|
|
|
| FINALIZE
|
2003-03-11 20:40:24 +01:00
|
|
|
| FIRST_P
|
2008-12-31 01:08:39 +01:00
|
|
|
| FOLLOWING
|
2002-06-17 22:27:43 +02:00
|
|
|
| FORCE
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
| FORMAT
|
2002-06-17 22:27:43 +02:00
|
|
|
| FORWARD
|
|
|
|
|
| FUNCTION
|
2009-10-12 22:39:42 +02:00
|
|
|
| FUNCTIONS
|
2017-04-06 14:33:16 +02:00
|
|
|
| GENERATED
|
2002-06-17 22:27:43 +02:00
|
|
|
| GLOBAL
|
2005-06-28 21:51:26 +02:00
|
|
|
| GRANTED
|
Support all SQL:2011 options for window frame clauses.
This patch adds the ability to use "RANGE offset PRECEDING/FOLLOWING"
frame boundaries in window functions. We'd punted on that back in the
original patch to add window functions, because it was not clear how to
do it in a reasonably data-type-extensible fashion. That problem is
resolved here by adding the ability for btree operator classes to provide
an "in_range" support function that defines how to add or subtract the
RANGE offset value. Factoring it this way also allows the operator class
to avoid overflow problems near the ends of the datatype's range, if it
wishes to expend effort on that. (In the committed patch, the integer
opclasses handle that issue, but it did not seem worth the trouble to
avoid overflow failures for datetime types.)
The patch includes in_range support for the integer_ops opfamily
(int2/int4/int8) as well as the standard datetime types. Support for
other numeric types has been requested, but that seems like suitable
material for a follow-on patch.
In addition, the patch adds GROUPS mode which counts the offset in
ORDER-BY peer groups rather than rows, and it adds the frame_exclusion
options specified by SQL:2011. As far as I can see, we are now fully
up to spec on window framing options.
Existing behaviors remain unchanged, except that I changed the errcode
for a couple of existing error reports to meet the SQL spec's expectation
that negative "offset" values should be reported as SQLSTATE 22013.
Internally and in relevant parts of the documentation, we now consistently
use the terminology "offset PRECEDING/FOLLOWING" rather than "value
PRECEDING/FOLLOWING", since the term "value" is confusingly vague.
Oliver Ford, reviewed and whacked around some by me
Discussion: https://postgr.es/m/CAGMVOdu9sivPAxbNN0X+q19Sfv9edEPv=HibOJhB14TJv_RCQg@mail.gmail.com
2018-02-07 06:06:50 +01:00
|
|
|
| GROUPS
|
2002-06-17 22:27:43 +02:00
|
|
|
| HANDLER
|
2005-12-27 05:00:08 +01:00
|
|
|
| HEADER_P
|
2003-04-29 05:21:30 +02:00
|
|
|
| HOLD
|
2002-06-17 22:27:43 +02:00
|
|
|
| HOUR_P
|
2008-05-17 01:36:05 +02:00
|
|
|
| IDENTITY_P
|
2005-11-19 18:39:45 +01:00
|
|
|
| IF_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| IMMEDIATE
|
|
|
|
|
| IMMUTABLE
|
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
2002-09-18 23:35:25 +02:00
|
|
|
| IMPLICIT_P
|
2014-07-10 21:01:31 +02:00
|
|
|
| IMPORT_P
|
2018-04-07 22:00:39 +02:00
|
|
|
| INCLUDE
|
2003-06-25 05:40:19 +02:00
|
|
|
| INCLUDING
|
2002-06-17 22:27:43 +02:00
|
|
|
| INCREMENT
|
2023-03-15 21:58:59 +01:00
|
|
|
| INDENT
|
2002-06-17 22:27:43 +02:00
|
|
|
| INDEX
|
2006-06-27 05:43:20 +02:00
|
|
|
| INDEXES
|
2005-07-26 18:38:29 +02:00
|
|
|
| INHERIT
|
2002-06-17 22:27:43 +02:00
|
|
|
| INHERITS
|
2009-09-23 01:43:43 +02:00
|
|
|
| INLINE_P
|
2003-05-15 18:35:30 +02:00
|
|
|
| INPUT_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| INSENSITIVE
|
|
|
|
|
| INSERT
|
|
|
|
|
| INSTEAD
|
|
|
|
|
| INVOKER
|
|
|
|
|
| ISOLATION
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
| JSON
|
2002-06-17 22:27:43 +02:00
|
|
|
| KEY
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
| KEYS
|
2010-09-28 02:55:27 +02:00
|
|
|
| LABEL
|
2003-01-08 01:22:27 +01:00
|
|
|
| LANGUAGE
|
2003-11-21 23:32:49 +01:00
|
|
|
| LARGE_P
|
2003-03-11 20:40:24 +01:00
|
|
|
| LAST_P
|
2012-02-14 04:20:27 +01:00
|
|
|
| LEAKPROOF
|
2002-06-17 22:27:43 +02:00
|
|
|
| LEVEL
|
|
|
|
|
| LISTEN
|
|
|
|
|
| LOAD
|
|
|
|
|
| LOCAL
|
|
|
|
|
| LOCATION
|
|
|
|
|
| LOCK_P
|
2014-10-07 22:23:34 +02:00
|
|
|
| LOCKED
|
2014-08-22 20:27:00 +02:00
|
|
|
| LOGGED
|
2007-08-21 03:11:32 +02:00
|
|
|
| MAPPING
|
2002-06-17 22:27:43 +02:00
|
|
|
| MATCH
|
2022-03-28 16:45:58 +02:00
|
|
|
| MATCHED
|
2013-03-04 01:23:31 +01:00
|
|
|
| MATERIALIZED
|
2002-06-17 22:27:43 +02:00
|
|
|
| MAXVALUE
|
2022-03-28 16:45:58 +02:00
|
|
|
| MERGE
|
2016-03-24 03:01:35 +01:00
|
|
|
| METHOD
|
2002-06-17 22:27:43 +02:00
|
|
|
| MINUTE_P
|
|
|
|
|
| MINVALUE
|
|
|
|
|
| MODE
|
|
|
|
|
| MONTH_P
|
|
|
|
|
| MOVE
|
2006-12-24 01:29:20 +01:00
|
|
|
| NAME_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| NAMES
|
2016-11-04 16:49:50 +01:00
|
|
|
| NEW
|
2002-06-17 22:27:43 +02:00
|
|
|
| NEXT
|
2020-03-26 08:14:00 +01:00
|
|
|
| NFC
|
|
|
|
|
| NFD
|
|
|
|
|
| NFKC
|
|
|
|
|
| NFKD
|
2002-06-17 22:27:43 +02:00
|
|
|
| NO
|
2020-03-26 08:14:00 +01:00
|
|
|
| NORMALIZED
|
2002-06-17 22:27:43 +02:00
|
|
|
| NOTHING
|
|
|
|
|
| NOTIFY
|
2004-10-01 18:40:05 +02:00
|
|
|
| NOWAIT
|
2007-01-09 03:14:16 +01:00
|
|
|
| NULLS_P
|
2003-11-21 23:32:49 +01:00
|
|
|
| OBJECT_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| OF
|
2010-10-22 16:37:38 +02:00
|
|
|
| OFF
|
2002-06-17 22:27:43 +02:00
|
|
|
| OIDS
|
2016-11-04 16:49:50 +01:00
|
|
|
| OLD
|
2002-06-17 22:27:43 +02:00
|
|
|
| OPERATOR
|
|
|
|
|
| OPTION
|
2008-12-19 17:25:19 +01:00
|
|
|
| OPTIONS
|
2013-07-29 17:38:01 +02:00
|
|
|
| ORDINALITY
|
Support all SQL:2011 options for window frame clauses.
This patch adds the ability to use "RANGE offset PRECEDING/FOLLOWING"
frame boundaries in window functions. We'd punted on that back in the
original patch to add window functions, because it was not clear how to
do it in a reasonably data-type-extensible fashion. That problem is
resolved here by adding the ability for btree operator classes to provide
an "in_range" support function that defines how to add or subtract the
RANGE offset value. Factoring it this way also allows the operator class
to avoid overflow problems near the ends of the datatype's range, if it
wishes to expend effort on that. (In the committed patch, the integer
opclasses handle that issue, but it did not seem worth the trouble to
avoid overflow failures for datetime types.)
The patch includes in_range support for the integer_ops opfamily
(int2/int4/int8) as well as the standard datetime types. Support for
other numeric types has been requested, but that seems like suitable
material for a follow-on patch.
In addition, the patch adds GROUPS mode which counts the offset in
ORDER-BY peer groups rather than rows, and it adds the frame_exclusion
options specified by SQL:2011. As far as I can see, we are now fully
up to spec on window framing options.
Existing behaviors remain unchanged, except that I changed the errcode
for a couple of existing error reports to meet the SQL spec's expectation
that negative "offset" values should be reported as SQLSTATE 22013.
Internally and in relevant parts of the documentation, we now consistently
use the terminology "offset PRECEDING/FOLLOWING" rather than "value
PRECEDING/FOLLOWING", since the term "value" is confusingly vague.
Oliver Ford, reviewed and whacked around some by me
Discussion: https://postgr.es/m/CAGMVOdu9sivPAxbNN0X+q19Sfv9edEPv=HibOJhB14TJv_RCQg@mail.gmail.com
2018-02-07 06:06:50 +01:00
|
|
|
| OTHERS
|
2013-06-28 16:18:00 +02:00
|
|
|
| OVER
|
2017-04-06 14:33:16 +02:00
|
|
|
| OVERRIDING
|
2005-11-21 13:49:33 +01:00
|
|
|
| OWNED
|
2002-06-17 22:27:43 +02:00
|
|
|
| OWNER
|
2015-09-16 21:38:47 +02:00
|
|
|
| PARALLEL
|
2022-04-06 19:24:33 +02:00
|
|
|
| PARAMETER
|
2007-08-21 03:11:32 +02:00
|
|
|
| PARSER
|
2002-06-17 22:27:43 +02:00
|
|
|
| PARTIAL
|
2008-12-28 19:54:01 +01:00
|
|
|
| PARTITION
|
2010-08-05 06:21:54 +02:00
|
|
|
| PASSING
|
2002-06-17 22:27:43 +02:00
|
|
|
| PASSWORD
|
2007-04-26 18:13:15 +02:00
|
|
|
| PLANS
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
| POLICY
|
2008-12-31 01:08:39 +01:00
|
|
|
| PRECEDING
|
2002-08-27 06:55:12 +02:00
|
|
|
| PREPARE
|
2005-06-18 00:32:51 +02:00
|
|
|
| PREPARED
|
2002-11-10 00:56:39 +01:00
|
|
|
| PRESERVE
|
2002-06-17 22:27:43 +02:00
|
|
|
| PRIOR
|
|
|
|
|
| PRIVILEGES
|
|
|
|
|
| PROCEDURAL
|
|
|
|
|
| PROCEDURE
|
2017-11-30 14:46:13 +01:00
|
|
|
| PROCEDURES
|
Add support for piping COPY to/from an external program.
This includes backend "COPY TO/FROM PROGRAM '...'" syntax, and corresponding
psql \copy syntax. Like with reading/writing files, the backend version is
superuser-only, and in the psql version, the program is run in the client.
In the passing, the psql \copy STDIN/STDOUT syntax is subtly changed: if you
the stdin/stdout is quoted, it's now interpreted as a filename. For example,
"\copy foo from 'stdin'" now reads from a file called 'stdin', not from
standard input. Before this, there was no way to specify a filename called
stdin, stdout, pstdin or pstdout.
This creates a new function in pgport, wait_result_to_str(), which can
be used to convert the exit status of a process, as returned by wait(3),
to a human-readable string.
Etsuro Fujita, reviewed by Amit Kapila.
2013-02-27 17:17:21 +01:00
|
|
|
| PROGRAM
|
2017-01-19 18:00:00 +01:00
|
|
|
| PUBLICATION
|
2004-04-19 19:22:31 +02:00
|
|
|
| QUOTE
|
2008-12-31 01:08:39 +01:00
|
|
|
| RANGE
|
2002-06-17 22:27:43 +02:00
|
|
|
| READ
|
2005-11-21 13:49:33 +01:00
|
|
|
| REASSIGN
|
2002-07-30 00:14:11 +02:00
|
|
|
| RECHECK
|
2008-10-04 23:56:55 +02:00
|
|
|
| RECURSIVE
|
Rename parser token REF to REF_P to avoid a symbol conflict.
In the latest version of Apple's macOS SDK, <sys/socket.h>
fails to compile if "REF" is #define'd as something.
Apple may or may not agree that this is a bug, and even if
they do accept the bug report I filed, they probably won't
fix it very quickly. In the meantime, our back branches will all
fail to compile gram.y. v15 and HEAD currently escape the problem
thanks to the refactoring done in 98e93a1fc, but that's purely
accidental. Moreover, since that patch removed a widely-visible
inclusion of <netdb.h>, back-patching it seems too likely to break
third-party code.
Instead, change the token's code name to REF_P, following our usual
convention for naming parser tokens that are likely to have symbol
conflicts. The effects of that should be localized to the grammar
and immediately surrounding files, so it seems like a safer answer.
Per project policy that we want to keep recently-out-of-support
branches buildable on modern systems, back-patch all the way to 9.2.
Discussion: https://postgr.es/m/1803927.1665938411@sss.pgh.pa.us
2022-10-16 21:27:04 +02:00
|
|
|
| REF_P
|
2016-11-04 16:49:50 +01:00
|
|
|
| REFERENCING
|
2013-03-04 01:23:31 +01:00
|
|
|
| REFRESH
|
2002-06-17 22:27:43 +02:00
|
|
|
| REINDEX
|
2003-05-15 18:35:30 +02:00
|
|
|
| RELATIVE_P
|
2004-07-27 07:11:48 +02:00
|
|
|
| RELEASE
|
2002-06-17 22:27:43 +02:00
|
|
|
| RENAME
|
2003-11-06 23:08:15 +01:00
|
|
|
| REPEATABLE
|
2002-06-17 22:27:43 +02:00
|
|
|
| REPLACE
|
2007-03-20 00:38:32 +01:00
|
|
|
| REPLICA
|
2002-06-17 22:27:43 +02:00
|
|
|
| RESET
|
2003-03-20 08:02:11 +01:00
|
|
|
| RESTART
|
2002-06-17 22:27:43 +02:00
|
|
|
| RESTRICT
|
2021-04-07 21:30:08 +02:00
|
|
|
| RETURN
|
2002-06-17 22:27:43 +02:00
|
|
|
| RETURNS
|
|
|
|
|
| REVOKE
|
2005-06-28 21:51:26 +02:00
|
|
|
| ROLE
|
2002-06-17 22:27:43 +02:00
|
|
|
| ROLLBACK
|
Support GROUPING SETS, CUBE and ROLLUP.
This SQL standard functionality allows to aggregate data by different
GROUP BY clauses at once. Each grouping set returns rows with columns
grouped by in other sets set to NULL.
This could previously be achieved by doing each grouping as a separate
query, conjoined by UNION ALLs. Besides being considerably more concise,
grouping sets will in many cases be faster, requiring only one scan over
the underlying data.
The current implementation of grouping sets only supports using sorting
for input. Individual sets that share a sort order are computed in one
pass. If there are sets that don't share a sort order, additional sort &
aggregation steps are performed. These additional passes are sourced by
the previous sort step; thus avoiding repeated scans of the source data.
The code is structured in a way that adding support for purely using
hash aggregation or a mix of hashing and sorting is possible. Sorting
was chosen to be supported first, as it is the most generic method of
implementation.
Instead of, as in an earlier versions of the patch, representing the
chain of sort and aggregation steps as full blown planner and executor
nodes, all but the first sort are performed inside the aggregation node
itself. This avoids the need to do some unusual gymnastics to handle
having to return aggregated and non-aggregated tuples from underlying
nodes, as well as having to shut down underlying nodes early to limit
memory usage. The optimizer still builds Sort/Agg node to describe each
phase, but they're not part of the plan tree, but instead additional
data for the aggregation node. They're a convenient and preexisting way
to describe aggregation and sorting. The first (and possibly only) sort
step is still performed as a separate execution step. That retains
similarity with existing group by plans, makes rescans fairly simple,
avoids very deep plans (leading to slow explains) and easily allows to
avoid the sorting step if the underlying data is sorted by other means.
A somewhat ugly side of this patch is having to deal with a grammar
ambiguity between the new CUBE keyword and the cube extension/functions
named cube (and rollup). To avoid breaking existing deployments of the
cube extension it has not been renamed, neither has cube been made a
reserved keyword. Instead precedence hacking is used to make GROUP BY
cube(..) refer to the CUBE grouping sets feature, and not the function
cube(). To actually group by a function cube(), unlikely as that might
be, the function name has to be quoted.
Needs a catversion bump because stored rules may change.
Author: Andrew Gierth and Atri Sharma, with contributions from Andres Freund
Reviewed-By: Andres Freund, Noah Misch, Tom Lane, Svenne Krap, Tomas
Vondra, Erik Rijkers, Marti Raudsepp, Pavel Stehule
Discussion: CAOeZVidmVRe2jU6aMk_5qkxnB7dfmPROzM7Ur8JPW5j8Y5X-Lw@mail.gmail.com
2015-05-16 03:40:59 +02:00
|
|
|
| ROLLUP
|
2017-11-30 14:46:13 +01:00
|
|
|
| ROUTINE
|
|
|
|
|
| ROUTINES
|
2002-11-10 00:56:39 +01:00
|
|
|
| ROWS
|
2002-06-17 22:27:43 +02:00
|
|
|
| RULE
|
2004-07-27 07:11:48 +02:00
|
|
|
| SAVEPOINT
|
SQL/JSON: support the IS JSON predicate
This patch introduces the SQL standard IS JSON predicate. It operates
on text and bytea values representing JSON, as well as on the json and
jsonb types. Each test has IS and IS NOT variants and supports a WITH
UNIQUE KEYS flag. The tests are:
IS JSON [VALUE]
IS JSON ARRAY
IS JSON OBJECT
IS JSON SCALAR
These should be self-explanatory.
The WITH UNIQUE KEYS flag makes these return false when duplicate keys
exist in any object within the value, not necessarily directly contained
in the outermost object.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Author: Andrew Dunstan <andrew@dunslane.net>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-31 22:34:04 +02:00
|
|
|
| SCALAR
|
2002-06-17 22:27:43 +02:00
|
|
|
| SCHEMA
|
2017-03-28 17:58:55 +02:00
|
|
|
| SCHEMAS
|
2002-06-17 22:27:43 +02:00
|
|
|
| SCROLL
|
2007-08-21 03:11:32 +02:00
|
|
|
| SEARCH
|
2002-06-17 22:27:43 +02:00
|
|
|
| SECOND_P
|
|
|
|
|
| SECURITY
|
|
|
|
|
| SEQUENCE
|
2009-10-12 22:39:42 +02:00
|
|
|
| SEQUENCES
|
2002-06-17 22:27:43 +02:00
|
|
|
| SERIALIZABLE
|
2009-04-28 11:09:41 +02:00
|
|
|
| SERVER
|
2003-03-11 20:40:24 +01:00
|
|
|
| SESSION
|
2002-06-17 22:27:43 +02:00
|
|
|
| SET
|
Support GROUPING SETS, CUBE and ROLLUP.
This SQL standard functionality allows to aggregate data by different
GROUP BY clauses at once. Each grouping set returns rows with columns
grouped by in other sets set to NULL.
This could previously be achieved by doing each grouping as a separate
query, conjoined by UNION ALLs. Besides being considerably more concise,
grouping sets will in many cases be faster, requiring only one scan over
the underlying data.
The current implementation of grouping sets only supports using sorting
for input. Individual sets that share a sort order are computed in one
pass. If there are sets that don't share a sort order, additional sort &
aggregation steps are performed. These additional passes are sourced by
the previous sort step; thus avoiding repeated scans of the source data.
The code is structured in a way that adding support for purely using
hash aggregation or a mix of hashing and sorting is possible. Sorting
was chosen to be supported first, as it is the most generic method of
implementation.
Instead of, as in an earlier versions of the patch, representing the
chain of sort and aggregation steps as full blown planner and executor
nodes, all but the first sort are performed inside the aggregation node
itself. This avoids the need to do some unusual gymnastics to handle
having to return aggregated and non-aggregated tuples from underlying
nodes, as well as having to shut down underlying nodes early to limit
memory usage. The optimizer still builds Sort/Agg node to describe each
phase, but they're not part of the plan tree, but instead additional
data for the aggregation node. They're a convenient and preexisting way
to describe aggregation and sorting. The first (and possibly only) sort
step is still performed as a separate execution step. That retains
similarity with existing group by plans, makes rescans fairly simple,
avoids very deep plans (leading to slow explains) and easily allows to
avoid the sorting step if the underlying data is sorted by other means.
A somewhat ugly side of this patch is having to deal with a grammar
ambiguity between the new CUBE keyword and the cube extension/functions
named cube (and rollup). To avoid breaking existing deployments of the
cube extension it has not been renamed, neither has cube been made a
reserved keyword. Instead precedence hacking is used to make GROUP BY
cube(..) refer to the CUBE grouping sets feature, and not the function
cube(). To actually group by a function cube(), unlikely as that might
be, the function name has to be quoted.
Needs a catversion bump because stored rules may change.
Author: Andrew Gierth and Atri Sharma, with contributions from Andres Freund
Reviewed-By: Andres Freund, Noah Misch, Tom Lane, Svenne Krap, Tomas
Vondra, Erik Rijkers, Marti Raudsepp, Pavel Stehule
Discussion: CAOeZVidmVRe2jU6aMk_5qkxnB7dfmPROzM7Ur8JPW5j8Y5X-Lw@mail.gmail.com
2015-05-16 03:40:59 +02:00
|
|
|
| SETS
|
2002-06-17 22:27:43 +02:00
|
|
|
| SHARE
|
|
|
|
|
| SHOW
|
2002-06-22 04:04:55 +02:00
|
|
|
| SIMPLE
|
2014-10-07 22:23:34 +02:00
|
|
|
| SKIP
|
2012-02-09 10:37:54 +01:00
|
|
|
| SNAPSHOT
|
2015-04-26 16:33:14 +02:00
|
|
|
| SQL_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| STABLE
|
2006-12-24 01:29:20 +01:00
|
|
|
| STANDALONE_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| START
|
|
|
|
|
| STATEMENT
|
|
|
|
|
| STATISTICS
|
|
|
|
|
| STDIN
|
|
|
|
|
| STDOUT
|
|
|
|
|
| STORAGE
|
2019-03-30 08:13:09 +01:00
|
|
|
| STORED
|
2006-12-24 01:29:20 +01:00
|
|
|
| STRICT_P
|
|
|
|
|
| STRIP_P
|
2017-01-19 18:00:00 +01:00
|
|
|
| SUBSCRIPTION
|
2019-02-10 00:08:48 +01:00
|
|
|
| SUPPORT
|
2002-06-17 22:27:43 +02:00
|
|
|
| SYSID
|
2005-06-22 23:14:31 +02:00
|
|
|
| SYSTEM_P
|
2009-10-12 22:39:42 +02:00
|
|
|
| TABLES
|
2004-06-18 08:14:31 +02:00
|
|
|
| TABLESPACE
|
2002-06-17 22:27:43 +02:00
|
|
|
| TEMP
|
|
|
|
|
| TEMPLATE
|
|
|
|
|
| TEMPORARY
|
2007-08-21 17:13:42 +02:00
|
|
|
| TEXT_P
|
Support all SQL:2011 options for window frame clauses.
This patch adds the ability to use "RANGE offset PRECEDING/FOLLOWING"
frame boundaries in window functions. We'd punted on that back in the
original patch to add window functions, because it was not clear how to
do it in a reasonably data-type-extensible fashion. That problem is
resolved here by adding the ability for btree operator classes to provide
an "in_range" support function that defines how to add or subtract the
RANGE offset value. Factoring it this way also allows the operator class
to avoid overflow problems near the ends of the datatype's range, if it
wishes to expend effort on that. (In the committed patch, the integer
opclasses handle that issue, but it did not seem worth the trouble to
avoid overflow failures for datetime types.)
The patch includes in_range support for the integer_ops opfamily
(int2/int4/int8) as well as the standard datetime types. Support for
other numeric types has been requested, but that seems like suitable
material for a follow-on patch.
In addition, the patch adds GROUPS mode which counts the offset in
ORDER-BY peer groups rather than rows, and it adds the frame_exclusion
options specified by SQL:2011. As far as I can see, we are now fully
up to spec on window framing options.
Existing behaviors remain unchanged, except that I changed the errcode
for a couple of existing error reports to meet the SQL spec's expectation
that negative "offset" values should be reported as SQLSTATE 22013.
Internally and in relevant parts of the documentation, we now consistently
use the terminology "offset PRECEDING/FOLLOWING" rather than "value
PRECEDING/FOLLOWING", since the term "value" is confusingly vague.
Oliver Ford, reviewed and whacked around some by me
Discussion: https://postgr.es/m/CAGMVOdu9sivPAxbNN0X+q19Sfv9edEPv=HibOJhB14TJv_RCQg@mail.gmail.com
2018-02-07 06:06:50 +01:00
|
|
|
| TIES
|
2002-06-17 22:27:43 +02:00
|
|
|
| TRANSACTION
|
2015-04-26 16:33:14 +02:00
|
|
|
| TRANSFORM
|
2002-06-17 22:27:43 +02:00
|
|
|
| TRIGGER
|
|
|
|
|
| TRUNCATE
|
|
|
|
|
| TRUSTED
|
|
|
|
|
| TYPE_P
|
2012-02-09 10:37:54 +01:00
|
|
|
| TYPES_P
|
Reduce size of backend scanner's tables.
Previously, the core scanner's yy_transition[] array had 37045 elements.
Since that number is larger than INT16_MAX, Flex generated the array to
contain 32-bit integers. By reimplementing some of the bulkier scanner
rules, this patch reduces the array to 20495 elements. The much smaller
total length, combined with the consequent use of 16-bit integers for
the array elements reduces the binary size by over 200kB. This was
accomplished in two ways:
1. Consolidate handling of quote continuations into a new start condition,
rather than duplicating that logic for five different string types.
2. Treat Unicode strings and identifiers followed by a UESCAPE sequence
as three separate tokens, rather than one. The logic to de-escape
Unicode strings is moved to the filter code in parser.c, which already
had the ability to provide special processing for token sequences.
While we could have implemented the conversion in the grammar, that
approach was rejected for performance and maintainability reasons.
Performance in microbenchmarks of raw parsing seems equal or slightly
faster in most cases, and it's reasonable to expect that in real-world
usage (with more competition for the CPU cache) there will be a larger
win. The exception is UESCAPE sequences; lexing those is about 10%
slower, primarily because the scanner now has to be called three times
rather than one. This seems acceptable since that feature is very
rarely used.
The psql and epcg lexers are likewise modified, primarily because we
want to keep them all in sync. Since those lexers don't use the
space-hogging -CF option, the space savings is much less, but it's
still good for perhaps 10kB apiece.
While at it, merge the ecpg lexer's handling of C-style comments used
in SQL and in C. Those have different rules regarding nested comments,
but since we already have the ability to keep track of the previous
start condition, we can use that to handle both cases within a single
start condition. This matches the core scanner more closely.
John Naylor
Discussion: https://postgr.es/m/CACPNZCvaoa3EgVWm5yZhcSTX6RAtaLgniCPcBVOCwm8h3xpWkw@mail.gmail.com
2020-01-13 21:04:31 +01:00
|
|
|
| UESCAPE
|
2008-12-31 01:08:39 +01:00
|
|
|
| UNBOUNDED
|
2003-11-06 23:08:15 +01:00
|
|
|
| UNCOMMITTED
|
2002-06-17 22:27:43 +02:00
|
|
|
| UNENCRYPTED
|
|
|
|
|
| UNKNOWN
|
|
|
|
|
| UNLISTEN
|
2010-12-29 12:48:53 +01:00
|
|
|
| UNLOGGED
|
2002-06-17 22:27:43 +02:00
|
|
|
| UNTIL
|
|
|
|
|
| UPDATE
|
|
|
|
|
| VACUUM
|
|
|
|
|
| VALID
|
2011-03-08 22:43:02 +01:00
|
|
|
| VALIDATE
|
2002-06-17 22:27:43 +02:00
|
|
|
| VALIDATOR
|
2006-12-24 01:29:20 +01:00
|
|
|
| VALUE_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| VARYING
|
2006-12-24 01:29:20 +01:00
|
|
|
| VERSION_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| VIEW
|
2014-01-19 00:56:40 +01:00
|
|
|
| VIEWS
|
2002-06-17 22:27:43 +02:00
|
|
|
| VOLATILE
|
2006-12-24 01:29:20 +01:00
|
|
|
| WHITESPACE_P
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
| WITHIN
|
2002-06-17 22:27:43 +02:00
|
|
|
| WITHOUT
|
|
|
|
|
| WORK
|
2008-12-19 17:25:19 +01:00
|
|
|
| WRAPPER
|
2003-03-11 20:40:24 +01:00
|
|
|
| WRITE
|
2007-01-25 12:53:52 +01:00
|
|
|
| XML_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| YEAR_P
|
2006-12-24 01:29:20 +01:00
|
|
|
| YES_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| ZONE
|
1997-10-25 07:56:41 +02:00
|
|
|
;
|
|
|
|
|
|
2001-11-16 05:08:33 +01:00
|
|
|
/* Column identifier --- keywords that can be column, table, etc names.
|
2001-11-10 23:31:49 +01:00
|
|
|
*
|
2001-11-16 05:08:33 +01:00
|
|
|
* Many of these keywords will in fact be recognized as type or function
|
|
|
|
|
* names too; but they have special productions for the purpose, and so
|
|
|
|
|
* can't be treated as "generic" type or function names.
|
2001-11-10 23:31:49 +01:00
|
|
|
*
|
2001-11-16 05:08:33 +01:00
|
|
|
* The type names appearing here are not usable as function names
|
|
|
|
|
* because they can be followed by '(' in typename productions, which
|
|
|
|
|
* looks too much like a function call for an LR(1) parser.
|
2001-11-10 23:31:49 +01:00
|
|
|
*/
|
2001-11-16 05:08:33 +01:00
|
|
|
col_name_keyword:
|
2010-02-12 18:33:21 +01:00
|
|
|
BETWEEN
|
|
|
|
|
| BIGINT
|
2002-06-17 22:27:43 +02:00
|
|
|
| BIT
|
2003-05-15 18:35:30 +02:00
|
|
|
| BOOLEAN_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| CHAR_P
|
|
|
|
|
| CHARACTER
|
|
|
|
|
| COALESCE
|
|
|
|
|
| DEC
|
2003-05-15 18:35:30 +02:00
|
|
|
| DECIMAL_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| EXISTS
|
|
|
|
|
| EXTRACT
|
|
|
|
|
| FLOAT_P
|
2005-06-27 00:05:42 +02:00
|
|
|
| GREATEST
|
Support GROUPING SETS, CUBE and ROLLUP.
This SQL standard functionality allows to aggregate data by different
GROUP BY clauses at once. Each grouping set returns rows with columns
grouped by in other sets set to NULL.
This could previously be achieved by doing each grouping as a separate
query, conjoined by UNION ALLs. Besides being considerably more concise,
grouping sets will in many cases be faster, requiring only one scan over
the underlying data.
The current implementation of grouping sets only supports using sorting
for input. Individual sets that share a sort order are computed in one
pass. If there are sets that don't share a sort order, additional sort &
aggregation steps are performed. These additional passes are sourced by
the previous sort step; thus avoiding repeated scans of the source data.
The code is structured in a way that adding support for purely using
hash aggregation or a mix of hashing and sorting is possible. Sorting
was chosen to be supported first, as it is the most generic method of
implementation.
Instead of, as in an earlier versions of the patch, representing the
chain of sort and aggregation steps as full blown planner and executor
nodes, all but the first sort are performed inside the aggregation node
itself. This avoids the need to do some unusual gymnastics to handle
having to return aggregated and non-aggregated tuples from underlying
nodes, as well as having to shut down underlying nodes early to limit
memory usage. The optimizer still builds Sort/Agg node to describe each
phase, but they're not part of the plan tree, but instead additional
data for the aggregation node. They're a convenient and preexisting way
to describe aggregation and sorting. The first (and possibly only) sort
step is still performed as a separate execution step. That retains
similarity with existing group by plans, makes rescans fairly simple,
avoids very deep plans (leading to slow explains) and easily allows to
avoid the sorting step if the underlying data is sorted by other means.
A somewhat ugly side of this patch is having to deal with a grammar
ambiguity between the new CUBE keyword and the cube extension/functions
named cube (and rollup). To avoid breaking existing deployments of the
cube extension it has not been renamed, neither has cube been made a
reserved keyword. Instead precedence hacking is used to make GROUP BY
cube(..) refer to the CUBE grouping sets feature, and not the function
cube(). To actually group by a function cube(), unlikely as that might
be, the function name has to be quoted.
Needs a catversion bump because stored rules may change.
Author: Andrew Gierth and Atri Sharma, with contributions from Andres Freund
Reviewed-By: Andres Freund, Noah Misch, Tom Lane, Svenne Krap, Tomas
Vondra, Erik Rijkers, Marti Raudsepp, Pavel Stehule
Discussion: CAOeZVidmVRe2jU6aMk_5qkxnB7dfmPROzM7Ur8JPW5j8Y5X-Lw@mail.gmail.com
2015-05-16 03:40:59 +02:00
|
|
|
| GROUPING
|
2004-01-07 00:55:19 +01:00
|
|
|
| INOUT
|
2003-05-15 18:35:30 +02:00
|
|
|
| INT_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| INTEGER
|
|
|
|
|
| INTERVAL
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
| JSON_ARRAY
|
|
|
|
|
| JSON_ARRAYAGG
|
|
|
|
|
| JSON_OBJECT
|
|
|
|
|
| JSON_OBJECTAGG
|
2005-06-27 00:05:42 +02:00
|
|
|
| LEAST
|
2004-01-07 00:55:19 +01:00
|
|
|
| NATIONAL
|
2002-06-17 22:27:43 +02:00
|
|
|
| NCHAR
|
|
|
|
|
| NONE
|
2020-03-26 08:14:00 +01:00
|
|
|
| NORMALIZE
|
2002-06-17 22:27:43 +02:00
|
|
|
| NULLIF
|
|
|
|
|
| NUMERIC
|
2004-01-07 00:55:19 +01:00
|
|
|
| OUT_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| OVERLAY
|
|
|
|
|
| POSITION
|
2004-01-07 00:55:19 +01:00
|
|
|
| PRECISION
|
2002-06-17 22:27:43 +02:00
|
|
|
| REAL
|
2002-07-04 17:24:11 +02:00
|
|
|
| ROW
|
2002-06-17 22:27:43 +02:00
|
|
|
| SETOF
|
|
|
|
|
| SMALLINT
|
|
|
|
|
| SUBSTRING
|
|
|
|
|
| TIME
|
|
|
|
|
| TIMESTAMP
|
2002-07-12 20:43:19 +02:00
|
|
|
| TREAT
|
2002-06-17 22:27:43 +02:00
|
|
|
| TRIM
|
2006-08-02 03:59:48 +02:00
|
|
|
| VALUES
|
2002-06-17 22:27:43 +02:00
|
|
|
| VARCHAR
|
2006-12-21 17:05:16 +01:00
|
|
|
| XMLATTRIBUTES
|
|
|
|
|
| XMLCONCAT
|
2006-12-24 01:29:20 +01:00
|
|
|
| XMLELEMENT
|
2010-08-05 06:21:54 +02:00
|
|
|
| XMLEXISTS
|
2006-12-21 17:05:16 +01:00
|
|
|
| XMLFOREST
|
2017-03-08 16:39:37 +01:00
|
|
|
| XMLNAMESPACES
|
2006-12-21 17:05:16 +01:00
|
|
|
| XMLPARSE
|
|
|
|
|
| XMLPI
|
|
|
|
|
| XMLROOT
|
|
|
|
|
| XMLSERIALIZE
|
2017-03-08 16:39:37 +01:00
|
|
|
| XMLTABLE
|
2001-11-10 23:31:49 +01:00
|
|
|
;
|
|
|
|
|
|
2006-12-30 22:21:56 +01:00
|
|
|
/* Type/function identifier --- keywords that can be type or function names.
|
2001-11-16 05:08:33 +01:00
|
|
|
*
|
|
|
|
|
* Most of these are keywords that are used as operators in expressions;
|
|
|
|
|
* in general such keywords can't be column names because they would be
|
|
|
|
|
* ambiguous with variables, but they are unambiguous as function identifiers.
|
|
|
|
|
*
|
|
|
|
|
* Do not include POSITION, SUBSTRING, etc here since they have explicit
|
|
|
|
|
* productions in a_expr to support the goofy SQL9x argument syntax.
|
2002-06-11 17:44:38 +02:00
|
|
|
* - thomas 2000-11-28
|
2001-11-16 05:08:33 +01:00
|
|
|
*/
|
2006-12-30 22:21:56 +01:00
|
|
|
type_func_name_keyword:
|
2002-06-17 22:27:43 +02:00
|
|
|
AUTHORIZATION
|
|
|
|
|
| BINARY
|
2012-05-16 19:19:44 +02:00
|
|
|
| COLLATION
|
2009-12-23 18:41:45 +01:00
|
|
|
| CONCURRENTLY
|
2002-06-17 22:27:43 +02:00
|
|
|
| CROSS
|
2008-10-27 10:37:47 +01:00
|
|
|
| CURRENT_SCHEMA
|
2002-06-17 22:27:43 +02:00
|
|
|
| FREEZE
|
|
|
|
|
| FULL
|
|
|
|
|
| ILIKE
|
|
|
|
|
| INNER_P
|
|
|
|
|
| IS
|
|
|
|
|
| ISNULL
|
|
|
|
|
| JOIN
|
|
|
|
|
| LEFT
|
|
|
|
|
| LIKE
|
|
|
|
|
| NATURAL
|
|
|
|
|
| NOTNULL
|
|
|
|
|
| OUTER_P
|
|
|
|
|
| OVERLAPS
|
|
|
|
|
| RIGHT
|
|
|
|
|
| SIMILAR
|
2015-05-15 20:37:10 +02:00
|
|
|
| TABLESAMPLE
|
2002-06-17 22:27:43 +02:00
|
|
|
| VERBOSE
|
2001-11-16 05:08:33 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/* Reserved keyword --- these keywords are usable only as a ColLabel.
|
2001-11-10 23:31:49 +01:00
|
|
|
*
|
|
|
|
|
* Keywords appear here if they could not be distinguished from variable,
|
2001-11-16 05:08:33 +01:00
|
|
|
* type, or function names in some contexts. Don't put things here unless
|
|
|
|
|
* forced to.
|
1997-10-25 07:56:41 +02:00
|
|
|
*/
|
2001-11-16 05:08:33 +01:00
|
|
|
reserved_keyword:
|
2002-06-17 22:27:43 +02:00
|
|
|
ALL
|
|
|
|
|
| ANALYSE
|
|
|
|
|
| ANALYZE
|
|
|
|
|
| AND
|
|
|
|
|
| ANY
|
2003-04-09 01:20:04 +02:00
|
|
|
| ARRAY
|
2002-06-17 22:27:43 +02:00
|
|
|
| AS
|
|
|
|
|
| ASC
|
2005-06-15 21:44:05 +02:00
|
|
|
| ASYMMETRIC
|
2002-06-17 22:27:43 +02:00
|
|
|
| BOTH
|
|
|
|
|
| CASE
|
|
|
|
|
| CAST
|
|
|
|
|
| CHECK
|
|
|
|
|
| COLLATE
|
|
|
|
|
| COLUMN
|
|
|
|
|
| CONSTRAINT
|
|
|
|
|
| CREATE
|
2008-10-27 10:37:47 +01:00
|
|
|
| CURRENT_CATALOG
|
2002-06-17 22:27:43 +02:00
|
|
|
| CURRENT_DATE
|
2005-06-28 21:51:26 +02:00
|
|
|
| CURRENT_ROLE
|
2002-06-17 22:27:43 +02:00
|
|
|
| CURRENT_TIME
|
|
|
|
|
| CURRENT_TIMESTAMP
|
|
|
|
|
| CURRENT_USER
|
|
|
|
|
| DEFAULT
|
|
|
|
|
| DEFERRABLE
|
|
|
|
|
| DESC
|
|
|
|
|
| DISTINCT
|
|
|
|
|
| DO
|
|
|
|
|
| ELSE
|
2003-02-10 05:44:47 +01:00
|
|
|
| END_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| EXCEPT
|
|
|
|
|
| FALSE_P
|
2008-10-22 13:00:34 +02:00
|
|
|
| FETCH
|
2002-06-17 22:27:43 +02:00
|
|
|
| FOR
|
|
|
|
|
| FOREIGN
|
|
|
|
|
| FROM
|
|
|
|
|
| GRANT
|
|
|
|
|
| GROUP_P
|
|
|
|
|
| HAVING
|
2004-01-07 00:55:19 +01:00
|
|
|
| IN_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| INITIALLY
|
|
|
|
|
| INTERSECT
|
|
|
|
|
| INTO
|
2012-08-08 01:02:54 +02:00
|
|
|
| LATERAL_P
|
2002-06-17 22:27:43 +02:00
|
|
|
| LEADING
|
|
|
|
|
| LIMIT
|
|
|
|
|
| LOCALTIME
|
|
|
|
|
| LOCALTIMESTAMP
|
|
|
|
|
| NOT
|
|
|
|
|
| NULL_P
|
|
|
|
|
| OFFSET
|
|
|
|
|
| ON
|
|
|
|
|
| ONLY
|
|
|
|
|
| OR
|
|
|
|
|
| ORDER
|
|
|
|
|
| PLACING
|
|
|
|
|
| PRIMARY
|
|
|
|
|
| REFERENCES
|
2006-08-12 04:52:06 +02:00
|
|
|
| RETURNING
|
2002-06-17 22:27:43 +02:00
|
|
|
| SELECT
|
|
|
|
|
| SESSION_USER
|
|
|
|
|
| SOME
|
2005-06-15 21:44:05 +02:00
|
|
|
| SYMMETRIC
|
Introduce SYSTEM_USER
SYSTEM_USER is a reserved keyword of the SQL specification that,
roughly described, is aimed at reporting some information about the
system user who has connected to the database server. It may include
implementation-specific information about the means by the user
connected, like an authentication method.
This commit implements SYSTEM_USER as of auth_method:identity, where
"auth_method" is a keyword about the authentication method used to log
into the server (like peer, md5, scram-sha-256, gss, etc.) and
"identity" is the authentication identity as introduced by 9afffcb (peer
sets authn to the OS user name, gss to the user principal, etc.). This
format has been suggested by Tom Lane.
Note that thanks to d951052, SYSTEM_USER is available to parallel
workers.
Bump catalog version.
Author: Bertrand Drouvot
Reviewed-by: Jacob Champion, Joe Conway, Álvaro Herrera, Michael Paquier
Discussion: https://postgr.es/m/7e692b8c-0b11-45db-1cad-3afc5b57409f@amazon.com
2022-09-29 08:05:40 +02:00
|
|
|
| SYSTEM_USER
|
2002-06-17 22:27:43 +02:00
|
|
|
| TABLE
|
|
|
|
|
| THEN
|
|
|
|
|
| TO
|
|
|
|
|
| TRAILING
|
|
|
|
|
| TRUE_P
|
|
|
|
|
| UNION
|
|
|
|
|
| UNIQUE
|
|
|
|
|
| USER
|
|
|
|
|
| USING
|
2008-07-16 03:30:23 +02:00
|
|
|
| VARIADIC
|
2002-06-17 22:27:43 +02:00
|
|
|
| WHEN
|
|
|
|
|
| WHERE
|
2008-12-28 19:54:01 +01:00
|
|
|
| WINDOW
|
2008-10-04 23:56:55 +02:00
|
|
|
| WITH
|
2002-06-17 22:27:43 +02:00
|
|
|
;
|
|
|
|
|
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
/*
|
|
|
|
|
* While all keywords can be used as column labels when preceded by AS,
|
|
|
|
|
* not all of them can be used as a "bare" column label without AS.
|
|
|
|
|
* Those that can be used as a bare label must be listed here,
|
|
|
|
|
* in addition to appearing in one of the category lists above.
|
|
|
|
|
*
|
|
|
|
|
* Always add a new keyword to this list if possible. Mark it BARE_LABEL
|
|
|
|
|
* in kwlist.h if it is included here, or AS_LABEL if it is not.
|
|
|
|
|
*/
|
|
|
|
|
bare_label_keyword:
|
|
|
|
|
ABORT_P
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
| ABSENT
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
| ABSOLUTE_P
|
|
|
|
|
| ACCESS
|
|
|
|
|
| ACTION
|
|
|
|
|
| ADD_P
|
|
|
|
|
| ADMIN
|
|
|
|
|
| AFTER
|
|
|
|
|
| AGGREGATE
|
|
|
|
|
| ALL
|
|
|
|
|
| ALSO
|
|
|
|
|
| ALTER
|
|
|
|
|
| ALWAYS
|
|
|
|
|
| ANALYSE
|
|
|
|
|
| ANALYZE
|
|
|
|
|
| AND
|
|
|
|
|
| ANY
|
|
|
|
|
| ASC
|
2021-04-07 07:49:27 +02:00
|
|
|
| ASENSITIVE
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
| ASSERTION
|
|
|
|
|
| ASSIGNMENT
|
|
|
|
|
| ASYMMETRIC
|
|
|
|
|
| AT
|
2021-04-07 21:30:08 +02:00
|
|
|
| ATOMIC
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
| ATTACH
|
|
|
|
|
| ATTRIBUTE
|
|
|
|
|
| AUTHORIZATION
|
|
|
|
|
| BACKWARD
|
|
|
|
|
| BEFORE
|
|
|
|
|
| BEGIN_P
|
|
|
|
|
| BETWEEN
|
|
|
|
|
| BIGINT
|
|
|
|
|
| BINARY
|
|
|
|
|
| BIT
|
|
|
|
|
| BOOLEAN_P
|
|
|
|
|
| BOTH
|
2021-02-01 13:54:59 +01:00
|
|
|
| BREADTH
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
| BY
|
|
|
|
|
| CACHE
|
|
|
|
|
| CALL
|
|
|
|
|
| CALLED
|
|
|
|
|
| CASCADE
|
|
|
|
|
| CASCADED
|
|
|
|
|
| CASE
|
|
|
|
|
| CAST
|
|
|
|
|
| CATALOG_P
|
|
|
|
|
| CHAIN
|
|
|
|
|
| CHARACTERISTICS
|
|
|
|
|
| CHECK
|
|
|
|
|
| CHECKPOINT
|
|
|
|
|
| CLASS
|
|
|
|
|
| CLOSE
|
|
|
|
|
| CLUSTER
|
|
|
|
|
| COALESCE
|
|
|
|
|
| COLLATE
|
|
|
|
|
| COLLATION
|
|
|
|
|
| COLUMN
|
|
|
|
|
| COLUMNS
|
|
|
|
|
| COMMENT
|
|
|
|
|
| COMMENTS
|
|
|
|
|
| COMMIT
|
|
|
|
|
| COMMITTED
|
Allow configurable LZ4 TOAST compression.
There is now a per-column COMPRESSION option which can be set to pglz
(the default, and the only option in up until now) or lz4. Or, if you
like, you can set the new default_toast_compression GUC to lz4, and
then that will be the default for new table columns for which no value
is specified. We don't have lz4 support in the PostgreSQL code, so
to use lz4 compression, PostgreSQL must be built --with-lz4.
In general, TOAST compression means compression of individual column
values, not the whole tuple, and those values can either be compressed
inline within the tuple or compressed and then stored externally in
the TOAST table, so those properties also apply to this feature.
Prior to this commit, a TOAST pointer has two unused bits as part of
the va_extsize field, and a compessed datum has two unused bits as
part of the va_rawsize field. These bits are unused because the length
of a varlena is limited to 1GB; we now use them to indicate the
compression type that was used. This means we only have bit space for
2 more built-in compresison types, but we could work around that
problem, if necessary, by introducing a new vartag_external value for
any further types we end up wanting to add. Hopefully, it won't be
too important to offer a wide selection of algorithms here, since
each one we add not only takes more coding but also adds a build
dependency for every packager. Nevertheless, it seems worth doing
at least this much, because LZ4 gets better compression than PGLZ
with less CPU usage.
It's possible for LZ4-compressed datums to leak into composite type
values stored on disk, just as it is for PGLZ. It's also possible for
LZ4-compressed attributes to be copied into a different table via SQL
commands such as CREATE TABLE AS or INSERT .. SELECT. It would be
expensive to force such values to be decompressed, so PostgreSQL has
never done so. For the same reasons, we also don't force recompression
of already-compressed values even if the target table prefers a
different compression method than was used for the source data. These
architectural decisions are perhaps arguable but revisiting them is
well beyond the scope of what seemed possible to do as part of this
project. However, it's relatively cheap to recompress as part of
VACUUM FULL or CLUSTER, so this commit adjusts those commands to do
so, if the configured compression method of the table happens not to
match what was used for some column value stored therein.
Dilip Kumar. The original patches on which this work was based were
written by Ildus Kurbangaliev, and those were patches were based on
even earlier work by Nikita Glukhov, but the design has since changed
very substantially, since allow a potentially large number of
compression methods that could be added and dropped on a running
system proved too problematic given some of the architectural issues
mentioned above; the choice of which specific compression method to
add first is now different; and a lot of the code has been heavily
refactored. More recently, Justin Przyby helped quite a bit with
testing and reviewing and this version also includes some code
contributions from him. Other design input and review from Tomas
Vondra, Álvaro Herrera, Andres Freund, Oleg Bartunov, Alexander
Korotkov, and me.
Discussion: http://postgr.es/m/20170907194236.4cefce96%40wp.localdomain
Discussion: http://postgr.es/m/CAFiTN-uUpX3ck%3DK0mLEk-G_kUQY%3DSNOTeqdaNRR9FMdQrHKebw%40mail.gmail.com
2021-03-19 20:10:38 +01:00
|
|
|
| COMPRESSION
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
| CONCURRENTLY
|
|
|
|
|
| CONFIGURATION
|
|
|
|
|
| CONFLICT
|
|
|
|
|
| CONNECTION
|
|
|
|
|
| CONSTRAINT
|
|
|
|
|
| CONSTRAINTS
|
|
|
|
|
| CONTENT_P
|
|
|
|
|
| CONTINUE_P
|
|
|
|
|
| CONVERSION_P
|
|
|
|
|
| COPY
|
|
|
|
|
| COST
|
|
|
|
|
| CROSS
|
|
|
|
|
| CSV
|
|
|
|
|
| CUBE
|
|
|
|
|
| CURRENT_P
|
|
|
|
|
| CURRENT_CATALOG
|
|
|
|
|
| CURRENT_DATE
|
|
|
|
|
| CURRENT_ROLE
|
|
|
|
|
| CURRENT_SCHEMA
|
|
|
|
|
| CURRENT_TIME
|
|
|
|
|
| CURRENT_TIMESTAMP
|
|
|
|
|
| CURRENT_USER
|
|
|
|
|
| CURSOR
|
|
|
|
|
| CYCLE
|
|
|
|
|
| DATA_P
|
|
|
|
|
| DATABASE
|
|
|
|
|
| DEALLOCATE
|
|
|
|
|
| DEC
|
|
|
|
|
| DECIMAL_P
|
|
|
|
|
| DECLARE
|
|
|
|
|
| DEFAULT
|
|
|
|
|
| DEFAULTS
|
|
|
|
|
| DEFERRABLE
|
|
|
|
|
| DEFERRED
|
|
|
|
|
| DEFINER
|
|
|
|
|
| DELETE_P
|
|
|
|
|
| DELIMITER
|
|
|
|
|
| DELIMITERS
|
|
|
|
|
| DEPENDS
|
2021-02-01 13:54:59 +01:00
|
|
|
| DEPTH
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
| DESC
|
|
|
|
|
| DETACH
|
|
|
|
|
| DICTIONARY
|
|
|
|
|
| DISABLE_P
|
|
|
|
|
| DISCARD
|
|
|
|
|
| DISTINCT
|
|
|
|
|
| DO
|
|
|
|
|
| DOCUMENT_P
|
|
|
|
|
| DOMAIN_P
|
|
|
|
|
| DOUBLE_P
|
|
|
|
|
| DROP
|
|
|
|
|
| EACH
|
|
|
|
|
| ELSE
|
|
|
|
|
| ENABLE_P
|
|
|
|
|
| ENCODING
|
|
|
|
|
| ENCRYPTED
|
|
|
|
|
| END_P
|
|
|
|
|
| ENUM_P
|
|
|
|
|
| ESCAPE
|
|
|
|
|
| EVENT
|
|
|
|
|
| EXCLUDE
|
|
|
|
|
| EXCLUDING
|
|
|
|
|
| EXCLUSIVE
|
|
|
|
|
| EXECUTE
|
|
|
|
|
| EXISTS
|
|
|
|
|
| EXPLAIN
|
|
|
|
|
| EXPRESSION
|
|
|
|
|
| EXTENSION
|
|
|
|
|
| EXTERNAL
|
|
|
|
|
| EXTRACT
|
|
|
|
|
| FALSE_P
|
|
|
|
|
| FAMILY
|
ALTER TABLE ... DETACH PARTITION ... CONCURRENTLY
Allow a partition be detached from its partitioned table without
blocking concurrent queries, by running in two transactions and only
requiring ShareUpdateExclusive in the partitioned table.
Because it runs in two transactions, it cannot be used in a transaction
block. This is the main reason to use dedicated syntax: so that users
can choose to use the original mode if they need it. But also, it
doesn't work when a default partition exists (because an exclusive lock
would still need to be obtained on it, in order to change its partition
constraint.)
In case the second transaction is cancelled or a crash occurs, there's
ALTER TABLE .. DETACH PARTITION .. FINALIZE, which executes the final
steps.
The main trick to make this work is the addition of column
pg_inherits.inhdetachpending, initially false; can only be set true in
the first part of this command. Once that is committed, concurrent
transactions that use a PartitionDirectory will include or ignore
partitions so marked: in optimizer they are ignored if the row is marked
committed for the snapshot; in executor they are always included. As a
result, and because of the way PartitionDirectory caches partition
descriptors, queries that were planned before the detach will see the
rows in the detached partition and queries that are planned after the
detach, won't.
A CHECK constraint is created that duplicates the partition constraint.
This is probably not strictly necessary, and some users will prefer to
remove it afterwards, but if the partition is re-attached to a
partitioned table, the constraint needn't be rechecked.
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Reviewed-by: Amit Langote <amitlangote09@gmail.com>
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>
Discussion: https://postgr.es/m/20200803234854.GA24158@alvherre.pgsql
2021-03-25 22:00:28 +01:00
|
|
|
| FINALIZE
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
| FIRST_P
|
|
|
|
|
| FLOAT_P
|
|
|
|
|
| FOLLOWING
|
|
|
|
|
| FORCE
|
|
|
|
|
| FOREIGN
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
| FORMAT
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
| FORWARD
|
|
|
|
|
| FREEZE
|
|
|
|
|
| FULL
|
|
|
|
|
| FUNCTION
|
|
|
|
|
| FUNCTIONS
|
|
|
|
|
| GENERATED
|
|
|
|
|
| GLOBAL
|
|
|
|
|
| GRANTED
|
|
|
|
|
| GREATEST
|
|
|
|
|
| GROUPING
|
|
|
|
|
| GROUPS
|
|
|
|
|
| HANDLER
|
|
|
|
|
| HEADER_P
|
|
|
|
|
| HOLD
|
|
|
|
|
| IDENTITY_P
|
|
|
|
|
| IF_P
|
|
|
|
|
| ILIKE
|
|
|
|
|
| IMMEDIATE
|
|
|
|
|
| IMMUTABLE
|
|
|
|
|
| IMPLICIT_P
|
|
|
|
|
| IMPORT_P
|
|
|
|
|
| IN_P
|
|
|
|
|
| INCLUDE
|
|
|
|
|
| INCLUDING
|
|
|
|
|
| INCREMENT
|
2023-03-15 21:58:59 +01:00
|
|
|
| INDENT
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
| INDEX
|
|
|
|
|
| INDEXES
|
|
|
|
|
| INHERIT
|
|
|
|
|
| INHERITS
|
|
|
|
|
| INITIALLY
|
|
|
|
|
| INLINE_P
|
|
|
|
|
| INNER_P
|
|
|
|
|
| INOUT
|
|
|
|
|
| INPUT_P
|
|
|
|
|
| INSENSITIVE
|
|
|
|
|
| INSERT
|
|
|
|
|
| INSTEAD
|
|
|
|
|
| INT_P
|
|
|
|
|
| INTEGER
|
|
|
|
|
| INTERVAL
|
|
|
|
|
| INVOKER
|
|
|
|
|
| IS
|
|
|
|
|
| ISOLATION
|
|
|
|
|
| JOIN
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
| JSON
|
|
|
|
|
| JSON_ARRAY
|
|
|
|
|
| JSON_ARRAYAGG
|
|
|
|
|
| JSON_OBJECT
|
|
|
|
|
| JSON_OBJECTAGG
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
| KEY
|
SQL/JSON: add standard JSON constructor functions
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:
JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()
Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-29 12:11:36 +02:00
|
|
|
| KEYS
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
| LABEL
|
|
|
|
|
| LANGUAGE
|
|
|
|
|
| LARGE_P
|
|
|
|
|
| LAST_P
|
|
|
|
|
| LATERAL_P
|
|
|
|
|
| LEADING
|
|
|
|
|
| LEAKPROOF
|
|
|
|
|
| LEAST
|
|
|
|
|
| LEFT
|
|
|
|
|
| LEVEL
|
|
|
|
|
| LIKE
|
|
|
|
|
| LISTEN
|
|
|
|
|
| LOAD
|
|
|
|
|
| LOCAL
|
|
|
|
|
| LOCALTIME
|
|
|
|
|
| LOCALTIMESTAMP
|
|
|
|
|
| LOCATION
|
|
|
|
|
| LOCK_P
|
|
|
|
|
| LOCKED
|
|
|
|
|
| LOGGED
|
|
|
|
|
| MAPPING
|
|
|
|
|
| MATCH
|
2022-03-28 16:45:58 +02:00
|
|
|
| MATCHED
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
| MATERIALIZED
|
|
|
|
|
| MAXVALUE
|
2022-03-28 16:45:58 +02:00
|
|
|
| MERGE
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
| METHOD
|
|
|
|
|
| MINVALUE
|
|
|
|
|
| MODE
|
|
|
|
|
| MOVE
|
|
|
|
|
| NAME_P
|
|
|
|
|
| NAMES
|
|
|
|
|
| NATIONAL
|
|
|
|
|
| NATURAL
|
|
|
|
|
| NCHAR
|
|
|
|
|
| NEW
|
|
|
|
|
| NEXT
|
|
|
|
|
| NFC
|
|
|
|
|
| NFD
|
|
|
|
|
| NFKC
|
|
|
|
|
| NFKD
|
|
|
|
|
| NO
|
|
|
|
|
| NONE
|
|
|
|
|
| NORMALIZE
|
|
|
|
|
| NORMALIZED
|
|
|
|
|
| NOT
|
|
|
|
|
| NOTHING
|
|
|
|
|
| NOTIFY
|
|
|
|
|
| NOWAIT
|
|
|
|
|
| NULL_P
|
|
|
|
|
| NULLIF
|
|
|
|
|
| NULLS_P
|
|
|
|
|
| NUMERIC
|
|
|
|
|
| OBJECT_P
|
|
|
|
|
| OF
|
|
|
|
|
| OFF
|
|
|
|
|
| OIDS
|
|
|
|
|
| OLD
|
|
|
|
|
| ONLY
|
|
|
|
|
| OPERATOR
|
|
|
|
|
| OPTION
|
|
|
|
|
| OPTIONS
|
|
|
|
|
| OR
|
|
|
|
|
| ORDINALITY
|
|
|
|
|
| OTHERS
|
|
|
|
|
| OUT_P
|
|
|
|
|
| OUTER_P
|
|
|
|
|
| OVERLAY
|
|
|
|
|
| OVERRIDING
|
|
|
|
|
| OWNED
|
|
|
|
|
| OWNER
|
|
|
|
|
| PARALLEL
|
2022-04-06 19:24:33 +02:00
|
|
|
| PARAMETER
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
| PARSER
|
|
|
|
|
| PARTIAL
|
|
|
|
|
| PARTITION
|
|
|
|
|
| PASSING
|
|
|
|
|
| PASSWORD
|
|
|
|
|
| PLACING
|
|
|
|
|
| PLANS
|
|
|
|
|
| POLICY
|
|
|
|
|
| POSITION
|
|
|
|
|
| PRECEDING
|
|
|
|
|
| PREPARE
|
|
|
|
|
| PREPARED
|
|
|
|
|
| PRESERVE
|
|
|
|
|
| PRIMARY
|
|
|
|
|
| PRIOR
|
|
|
|
|
| PRIVILEGES
|
|
|
|
|
| PROCEDURAL
|
|
|
|
|
| PROCEDURE
|
|
|
|
|
| PROCEDURES
|
|
|
|
|
| PROGRAM
|
|
|
|
|
| PUBLICATION
|
|
|
|
|
| QUOTE
|
|
|
|
|
| RANGE
|
|
|
|
|
| READ
|
|
|
|
|
| REAL
|
|
|
|
|
| REASSIGN
|
|
|
|
|
| RECHECK
|
|
|
|
|
| RECURSIVE
|
Rename parser token REF to REF_P to avoid a symbol conflict.
In the latest version of Apple's macOS SDK, <sys/socket.h>
fails to compile if "REF" is #define'd as something.
Apple may or may not agree that this is a bug, and even if
they do accept the bug report I filed, they probably won't
fix it very quickly. In the meantime, our back branches will all
fail to compile gram.y. v15 and HEAD currently escape the problem
thanks to the refactoring done in 98e93a1fc, but that's purely
accidental. Moreover, since that patch removed a widely-visible
inclusion of <netdb.h>, back-patching it seems too likely to break
third-party code.
Instead, change the token's code name to REF_P, following our usual
convention for naming parser tokens that are likely to have symbol
conflicts. The effects of that should be localized to the grammar
and immediately surrounding files, so it seems like a safer answer.
Per project policy that we want to keep recently-out-of-support
branches buildable on modern systems, back-patch all the way to 9.2.
Discussion: https://postgr.es/m/1803927.1665938411@sss.pgh.pa.us
2022-10-16 21:27:04 +02:00
|
|
|
| REF_P
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
| REFERENCES
|
|
|
|
|
| REFERENCING
|
|
|
|
|
| REFRESH
|
|
|
|
|
| REINDEX
|
|
|
|
|
| RELATIVE_P
|
|
|
|
|
| RELEASE
|
|
|
|
|
| RENAME
|
|
|
|
|
| REPEATABLE
|
|
|
|
|
| REPLACE
|
|
|
|
|
| REPLICA
|
|
|
|
|
| RESET
|
|
|
|
|
| RESTART
|
|
|
|
|
| RESTRICT
|
2021-04-07 21:30:08 +02:00
|
|
|
| RETURN
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
| RETURNS
|
|
|
|
|
| REVOKE
|
|
|
|
|
| RIGHT
|
|
|
|
|
| ROLE
|
|
|
|
|
| ROLLBACK
|
|
|
|
|
| ROLLUP
|
|
|
|
|
| ROUTINE
|
|
|
|
|
| ROUTINES
|
|
|
|
|
| ROW
|
|
|
|
|
| ROWS
|
|
|
|
|
| RULE
|
|
|
|
|
| SAVEPOINT
|
SQL/JSON: support the IS JSON predicate
This patch introduces the SQL standard IS JSON predicate. It operates
on text and bytea values representing JSON, as well as on the json and
jsonb types. Each test has IS and IS NOT variants and supports a WITH
UNIQUE KEYS flag. The tests are:
IS JSON [VALUE]
IS JSON ARRAY
IS JSON OBJECT
IS JSON SCALAR
These should be self-explanatory.
The WITH UNIQUE KEYS flag makes these return false when duplicate keys
exist in any object within the value, not necessarily directly contained
in the outermost object.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Author: Andrew Dunstan <andrew@dunslane.net>
Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.
Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
2023-03-31 22:34:04 +02:00
|
|
|
| SCALAR
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
| SCHEMA
|
|
|
|
|
| SCHEMAS
|
|
|
|
|
| SCROLL
|
|
|
|
|
| SEARCH
|
|
|
|
|
| SECURITY
|
|
|
|
|
| SELECT
|
|
|
|
|
| SEQUENCE
|
|
|
|
|
| SEQUENCES
|
|
|
|
|
| SERIALIZABLE
|
|
|
|
|
| SERVER
|
|
|
|
|
| SESSION
|
|
|
|
|
| SESSION_USER
|
|
|
|
|
| SET
|
|
|
|
|
| SETOF
|
|
|
|
|
| SETS
|
|
|
|
|
| SHARE
|
|
|
|
|
| SHOW
|
|
|
|
|
| SIMILAR
|
|
|
|
|
| SIMPLE
|
|
|
|
|
| SKIP
|
|
|
|
|
| SMALLINT
|
|
|
|
|
| SNAPSHOT
|
|
|
|
|
| SOME
|
|
|
|
|
| SQL_P
|
|
|
|
|
| STABLE
|
|
|
|
|
| STANDALONE_P
|
|
|
|
|
| START
|
|
|
|
|
| STATEMENT
|
|
|
|
|
| STATISTICS
|
|
|
|
|
| STDIN
|
|
|
|
|
| STDOUT
|
|
|
|
|
| STORAGE
|
|
|
|
|
| STORED
|
|
|
|
|
| STRICT_P
|
|
|
|
|
| STRIP_P
|
|
|
|
|
| SUBSCRIPTION
|
|
|
|
|
| SUBSTRING
|
|
|
|
|
| SUPPORT
|
|
|
|
|
| SYMMETRIC
|
|
|
|
|
| SYSID
|
|
|
|
|
| SYSTEM_P
|
Introduce SYSTEM_USER
SYSTEM_USER is a reserved keyword of the SQL specification that,
roughly described, is aimed at reporting some information about the
system user who has connected to the database server. It may include
implementation-specific information about the means by the user
connected, like an authentication method.
This commit implements SYSTEM_USER as of auth_method:identity, where
"auth_method" is a keyword about the authentication method used to log
into the server (like peer, md5, scram-sha-256, gss, etc.) and
"identity" is the authentication identity as introduced by 9afffcb (peer
sets authn to the OS user name, gss to the user principal, etc.). This
format has been suggested by Tom Lane.
Note that thanks to d951052, SYSTEM_USER is available to parallel
workers.
Bump catalog version.
Author: Bertrand Drouvot
Reviewed-by: Jacob Champion, Joe Conway, Álvaro Herrera, Michael Paquier
Discussion: https://postgr.es/m/7e692b8c-0b11-45db-1cad-3afc5b57409f@amazon.com
2022-09-29 08:05:40 +02:00
|
|
|
| SYSTEM_USER
|
Allow most keywords to be used as column labels without requiring AS.
Up to now, if you tried to omit "AS" before a column label in a SELECT
list, it would only work if the column label was an IDENT, that is not
any known keyword. This is rather unfriendly considering that we have
so many keywords and are constantly growing more. In the wake of commit
1ed6b8956 it's possible to improve matters quite a bit.
We'd originally tried to make this work by having some of the existing
keyword categories be allowed without AS, but that didn't work too well,
because each category contains a few special cases that don't work
without AS. Instead, invent an entirely orthogonal keyword property
"can be bare column label", and mark all keywords that way for which
we don't get shift/reduce errors by doing so.
It turns out that of our 450 current keywords, all but 39 can be made
bare column labels, improving the situation by over 90%. This number
might move around a little depending on future grammar work, but it's
a pretty nice improvement.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 22:46:26 +02:00
|
|
|
| TABLE
|
|
|
|
|
| TABLES
|
|
|
|
|
| TABLESAMPLE
|
|
|
|
|
| TABLESPACE
|
|
|
|
|
| TEMP
|
|
|
|
|
| TEMPLATE
|
|
|
|
|
| TEMPORARY
|
|
|
|
|
| TEXT_P
|
|
|
|
|
| THEN
|
|
|
|
|
| TIES
|
|
|
|
|
| TIME
|
|
|
|
|
| TIMESTAMP
|
|
|
|
|
| TRAILING
|
|
|
|
|
| TRANSACTION
|
|
|
|
|
| TRANSFORM
|
|
|
|
|
| TREAT
|
|
|
|
|
| TRIGGER
|
|
|
|
|
| TRIM
|
|
|
|
|
| TRUE_P
|
|
|
|
|
| TRUNCATE
|
|
|
|
|
| TRUSTED
|
|
|
|
|
| TYPE_P
|
|
|
|
|
| TYPES_P
|
|
|
|
|
| UESCAPE
|
|
|
|
|
| UNBOUNDED
|
|
|
|
|
| UNCOMMITTED
|
|
|
|
|
| UNENCRYPTED
|
|
|
|
|
| UNIQUE
|
|
|
|
|
| UNKNOWN
|
|
|
|
|
| UNLISTEN
|
|
|
|
|
| UNLOGGED
|
|
|
|
|
| UNTIL
|
|
|
|
|
| UPDATE
|
|
|
|
|
| USER
|
|
|
|
|
| USING
|
|
|
|
|
| VACUUM
|
|
|
|
|
| VALID
|
|
|
|
|
| VALIDATE
|
|
|
|
|
| VALIDATOR
|
|
|
|
|
| VALUE_P
|
|
|
|
|
| VALUES
|
|
|
|
|
| VARCHAR
|
|
|
|
|
| VARIADIC
|
|
|
|
|
| VERBOSE
|
|
|
|
|
| VERSION_P
|
|
|
|
|
| VIEW
|
|
|
|
|
| VIEWS
|
|
|
|
|
| VOLATILE
|
|
|
|
|
| WHEN
|
|
|
|
|
| WHITESPACE_P
|
|
|
|
|
| WORK
|
|
|
|
|
| WRAPPER
|
|
|
|
|
| WRITE
|
|
|
|
|
| XML_P
|
|
|
|
|
| XMLATTRIBUTES
|
|
|
|
|
| XMLCONCAT
|
|
|
|
|
| XMLELEMENT
|
|
|
|
|
| XMLEXISTS
|
|
|
|
|
| XMLFOREST
|
|
|
|
|
| XMLNAMESPACES
|
|
|
|
|
| XMLPARSE
|
|
|
|
|
| XMLPI
|
|
|
|
|
| XMLROOT
|
|
|
|
|
| XMLSERIALIZE
|
|
|
|
|
| XMLTABLE
|
|
|
|
|
| YES_P
|
|
|
|
|
| ZONE
|
|
|
|
|
;
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
%%
|
|
|
|
|
|
2009-07-13 04:02:20 +02:00
|
|
|
/*
|
|
|
|
|
* The signature of this function is required by bison. However, we
|
|
|
|
|
* ignore the passed yylloc and instead use the last token position
|
|
|
|
|
* available from the scanner.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
2009-11-09 19:38:48 +01:00
|
|
|
base_yyerror(YYLTYPE *yylloc, core_yyscan_t yyscanner, const char *msg)
|
2009-07-13 04:02:20 +02:00
|
|
|
{
|
|
|
|
|
parser_yyerror(msg);
|
|
|
|
|
}
|
|
|
|
|
|
Change representation of statement lists, and add statement location info.
This patch makes several changes that improve the consistency of
representation of lists of statements. It's always been the case
that the output of parse analysis is a list of Query nodes, whatever
the types of the individual statements in the list. This patch brings
similar consistency to the outputs of raw parsing and planning steps:
* The output of raw parsing is now always a list of RawStmt nodes;
the statement-type-dependent nodes are one level down from that.
* The output of pg_plan_queries() is now always a list of PlannedStmt
nodes, even for utility statements. In the case of a utility statement,
"planning" just consists of wrapping a CMD_UTILITY PlannedStmt around
the utility node. This list representation is now used in Portal and
CachedPlan plan lists, replacing the former convention of intermixing
PlannedStmts with bare utility-statement nodes.
Now, every list of statements has a consistent head-node type depending
on how far along it is in processing. This allows changing many places
that formerly used generic "Node *" pointers to use a more specific
pointer type, thus reducing the number of IsA() tests and casts needed,
as well as improving code clarity.
Also, the post-parse-analysis representation of DECLARE CURSOR is changed
so that it looks more like EXPLAIN, PREPARE, etc. That is, the contained
SELECT remains a child of the DeclareCursorStmt rather than getting flipped
around to be the other way. It's now true for both Query and PlannedStmt
that utilityStmt is non-null if and only if commandType is CMD_UTILITY.
That allows simplifying a lot of places that were testing both fields.
(I think some of those were just defensive programming, but in many places,
it was actually necessary to avoid confusing DECLARE CURSOR with SELECT.)
Because PlannedStmt carries a canSetTag field, we're also able to get rid
of some ad-hoc rules about how to reconstruct canSetTag for a bare utility
statement; specifically, the assumption that a utility is canSetTag if and
only if it's the only one in its list. While I see no near-term need for
relaxing that restriction, it's nice to get rid of the ad-hocery.
The API of ProcessUtility() is changed so that what it's passed is the
wrapper PlannedStmt not just the bare utility statement. This will affect
all users of ProcessUtility_hook, but the changes are pretty trivial; see
the affected contrib modules for examples of the minimum change needed.
(Most compilers should give pointer-type-mismatch warnings for uncorrected
code.)
There's also a change in the API of ExplainOneQuery_hook, to pass through
cursorOptions instead of expecting hook functions to know what to pick.
This is needed because of the DECLARE CURSOR changes, but really should
have been done in 9.6; it's unlikely that any extant hook functions
know about using CURSOR_OPT_PARALLEL_OK.
Finally, teach gram.y to save statement boundary locations in RawStmt
nodes, and pass those through to Query and PlannedStmt nodes. This allows
more intelligent handling of cases where a source query string contains
multiple statements. This patch doesn't actually do anything with the
information, but a follow-on patch will. (Passing this information through
cleanly is the true motivation for these changes; while I think this is all
good cleanup, it's unlikely we'd have bothered without this end goal.)
catversion bump because addition of location fields to struct Query
affects stored rules.
This patch is by me, but it owes a good deal to Fabien Coelho who did
a lot of preliminary work on the problem, and also reviewed the patch.
Discussion: https://postgr.es/m/alpine.DEB.2.20.1612200926310.29821@lancre
2017-01-14 22:02:35 +01:00
|
|
|
static RawStmt *
|
|
|
|
|
makeRawStmt(Node *stmt, int stmt_location)
|
|
|
|
|
{
|
|
|
|
|
RawStmt *rs = makeNode(RawStmt);
|
|
|
|
|
|
|
|
|
|
rs->stmt = stmt;
|
|
|
|
|
rs->stmt_location = stmt_location;
|
|
|
|
|
rs->stmt_len = 0; /* might get changed later */
|
|
|
|
|
return rs;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Adjust a RawStmt to reflect that it doesn't run to the end of the string */
|
|
|
|
|
static void
|
|
|
|
|
updateRawStmtEnd(RawStmt *rs, int end_location)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* If we already set the length, don't change it. This is for situations
|
|
|
|
|
* like "select foo ;; select bar" where the same statement will be last
|
|
|
|
|
* in the string for more than one semicolon.
|
|
|
|
|
*/
|
|
|
|
|
if (rs->stmt_len > 0)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
/* OK, update length of RawStmt */
|
|
|
|
|
rs->stmt_len = end_location - rs->stmt_location;
|
|
|
|
|
}
|
|
|
|
|
|
2004-06-09 21:08:20 +02:00
|
|
|
static Node *
|
2009-07-13 04:02:20 +02:00
|
|
|
makeColumnRef(char *colname, List *indirection,
|
2009-11-09 19:38:48 +01:00
|
|
|
int location, core_yyscan_t yyscanner)
|
2004-06-09 21:08:20 +02:00
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* Generate a ColumnRef node, with an A_Indirection node added if there
|
|
|
|
|
* is any subscripting in the specified indirection list. However,
|
|
|
|
|
* any field selection at the start of the indirection list must be
|
|
|
|
|
* transposed into the "fields" part of the ColumnRef node.
|
|
|
|
|
*/
|
|
|
|
|
ColumnRef *c = makeNode(ColumnRef);
|
2022-05-13 07:17:29 +02:00
|
|
|
int nfields = 0;
|
|
|
|
|
ListCell *l;
|
2004-06-09 21:08:20 +02:00
|
|
|
|
2006-03-14 23:48:25 +01:00
|
|
|
c->location = location;
|
2004-06-09 21:08:20 +02:00
|
|
|
foreach(l, indirection)
|
|
|
|
|
{
|
|
|
|
|
if (IsA(lfirst(l), A_Indices))
|
|
|
|
|
{
|
|
|
|
|
A_Indirection *i = makeNode(A_Indirection);
|
|
|
|
|
|
|
|
|
|
if (nfields == 0)
|
|
|
|
|
{
|
|
|
|
|
/* easy case - all indirection goes to A_Indirection */
|
2008-08-30 03:39:14 +02:00
|
|
|
c->fields = list_make1(makeString(colname));
|
2009-07-13 04:02:20 +02:00
|
|
|
i->indirection = check_indirection(indirection, yyscanner);
|
2004-06-09 21:08:20 +02:00
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
/* got to split the list in two */
|
2008-08-30 03:39:14 +02:00
|
|
|
i->indirection = check_indirection(list_copy_tail(indirection,
|
2009-07-13 04:02:20 +02:00
|
|
|
nfields),
|
|
|
|
|
yyscanner);
|
2004-06-09 21:08:20 +02:00
|
|
|
indirection = list_truncate(indirection, nfields);
|
2008-08-30 03:39:14 +02:00
|
|
|
c->fields = lcons(makeString(colname), indirection);
|
2004-06-09 21:08:20 +02:00
|
|
|
}
|
|
|
|
|
i->arg = (Node *) c;
|
|
|
|
|
return (Node *) i;
|
|
|
|
|
}
|
2008-08-30 03:39:14 +02:00
|
|
|
else if (IsA(lfirst(l), A_Star))
|
|
|
|
|
{
|
|
|
|
|
/* We only allow '*' at the end of a ColumnRef */
|
Represent Lists as expansible arrays, not chains of cons-cells.
Originally, Postgres Lists were a more or less exact reimplementation of
Lisp lists, which consist of chains of separately-allocated cons cells,
each having a value and a next-cell link. We'd hacked that once before
(commit d0b4399d8) to add a separate List header, but the data was still
in cons cells. That makes some operations -- notably list_nth() -- O(N),
and it's bulky because of the next-cell pointers and per-cell palloc
overhead, and it's very cache-unfriendly if the cons cells end up
scattered around rather than being adjacent.
In this rewrite, we still have List headers, but the data is in a
resizable array of values, with no next-cell links. Now we need at
most two palloc's per List, and often only one, since we can allocate
some values in the same palloc call as the List header. (Of course,
extending an existing List may require repalloc's to enlarge the array.
But this involves just O(log N) allocations not O(N).)
Of course this is not without downsides. The key difficulty is that
addition or deletion of a list entry may now cause other entries to
move, which it did not before.
For example, that breaks foreach() and sister macros, which historically
used a pointer to the current cons-cell as loop state. We can repair
those macros transparently by making their actual loop state be an
integer list index; the exposed "ListCell *" pointer is no longer state
carried across loop iterations, but is just a derived value. (In
practice, modern compilers can optimize things back to having just one
loop state value, at least for simple cases with inline loop bodies.)
In principle, this is a semantics change for cases where the loop body
inserts or deletes list entries ahead of the current loop index; but
I found no such cases in the Postgres code.
The change is not at all transparent for code that doesn't use foreach()
but chases lists "by hand" using lnext(). The largest share of such
code in the backend is in loops that were maintaining "prev" and "next"
variables in addition to the current-cell pointer, in order to delete
list cells efficiently using list_delete_cell(). However, we no longer
need a previous-cell pointer to delete a list cell efficiently. Keeping
a next-cell pointer doesn't work, as explained above, but we can improve
matters by changing such code to use a regular foreach() loop and then
using the new macro foreach_delete_current() to delete the current cell.
(This macro knows how to update the associated foreach loop's state so
that no cells will be missed in the traversal.)
There remains a nontrivial risk of code assuming that a ListCell *
pointer will remain good over an operation that could now move the list
contents. To help catch such errors, list.c can be compiled with a new
define symbol DEBUG_LIST_MEMORY_USAGE that forcibly moves list contents
whenever that could possibly happen. This makes list operations
significantly more expensive so it's not normally turned on (though it
is on by default if USE_VALGRIND is on).
There are two notable API differences from the previous code:
* lnext() now requires the List's header pointer in addition to the
current cell's address.
* list_delete_cell() no longer requires a previous-cell argument.
These changes are somewhat unfortunate, but on the other hand code using
either function needs inspection to see if it is assuming anything
it shouldn't, so it's not all bad.
Programmers should be aware of these significant performance changes:
* list_nth() and related functions are now O(1); so there's no
major access-speed difference between a list and an array.
* Inserting or deleting a list element now takes time proportional to
the distance to the end of the list, due to moving the array elements.
(However, it typically *doesn't* require palloc or pfree, so except in
long lists it's probably still faster than before.) Notably, lcons()
used to be about the same cost as lappend(), but that's no longer true
if the list is long. Code that uses lcons() and list_delete_first()
to maintain a stack might usefully be rewritten to push and pop at the
end of the list rather than the beginning.
* There are now list_insert_nth...() and list_delete_nth...() functions
that add or remove a list cell identified by index. These have the
data-movement penalty explained above, but there's no search penalty.
* list_concat() and variants now copy the second list's data into
storage belonging to the first list, so there is no longer any
sharing of cells between the input lists. The second argument is
now declared "const List *" to reflect that it isn't changed.
This patch just does the minimum needed to get the new implementation
in place and fix bugs exposed by the regression tests. As suggested
by the foregoing, there's a fair amount of followup work remaining to
do.
Also, the ENABLE_LIST_COMPAT macros are finally removed in this
commit. Code using those should have been gone a dozen years ago.
Patch by me; thanks to David Rowley, Jesper Pedersen, and others
for review.
Discussion: https://postgr.es/m/11587.1550975080@sss.pgh.pa.us
2019-07-15 19:41:58 +02:00
|
|
|
if (lnext(indirection, l) != NULL)
|
2009-07-13 04:02:20 +02:00
|
|
|
parser_yyerror("improper use of \"*\"");
|
2008-08-30 03:39:14 +02:00
|
|
|
}
|
2004-06-09 21:08:20 +02:00
|
|
|
nfields++;
|
|
|
|
|
}
|
|
|
|
|
/* No subscripting, so all indirection gets added to field list */
|
2008-08-30 03:39:14 +02:00
|
|
|
c->fields = lcons(makeString(colname), indirection);
|
2004-06-09 21:08:20 +02:00
|
|
|
return (Node *) c;
|
|
|
|
|
}
|
|
|
|
|
|
2000-01-17 01:14:49 +01:00
|
|
|
static Node *
|
2008-08-29 01:09:48 +02:00
|
|
|
makeTypeCast(Node *arg, TypeName *typename, int location)
|
2000-01-17 01:14:49 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
TypeCast *n = makeNode(TypeCast);
|
|
|
|
|
|
2002-07-06 22:16:36 +02:00
|
|
|
n->arg = arg;
|
2009-07-16 08:33:46 +02:00
|
|
|
n->typeName = typename;
|
2008-08-29 01:09:48 +02:00
|
|
|
n->location = location;
|
2002-07-06 22:16:36 +02:00
|
|
|
return (Node *) n;
|
2000-01-17 01:14:49 +01:00
|
|
|
}
|
|
|
|
|
|
2001-10-18 19:30:21 +02:00
|
|
|
static Node *
|
2008-08-29 01:09:48 +02:00
|
|
|
makeStringConst(char *str, int location)
|
2001-10-18 19:30:21 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
A_Const *n = makeNode(A_Const);
|
2002-03-29 20:06:29 +01:00
|
|
|
|
Remove Value node struct
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and the node
type don't match most of the time, and so it has to be treated
specially a lot. There doesn't seem to be any value in the special
construct. There is very little code that wants to accept all Value
variants but nothing else (and even if it did, this doesn't provide
any convenient way to check it), and most code wants either just one
particular node type (usually String), or it accepts a broader set of
node types besides just Value.
This change removes the Value struct and node type and replaces them
by separate Integer, Float, String, and BitString node types that are
proper node types and structs of their own and behave mostly like
normal node types.
Also, this removes the T_Null node tag, which was previously also a
possible variant of Value but wasn't actually used outside of the
Value contained in A_Const. Replace that by an isnull field in
A_Const.
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/5ba6bc5b-3f95-04f2-2419-f8ddb4c046fb@enterprisedb.com
2021-09-09 07:58:12 +02:00
|
|
|
n->val.sval.type = T_String;
|
2022-01-14 10:46:49 +01:00
|
|
|
n->val.sval.sval = str;
|
2008-08-29 01:09:48 +02:00
|
|
|
n->location = location;
|
2001-10-18 19:30:21 +02:00
|
|
|
|
2022-05-13 07:17:29 +02:00
|
|
|
return (Node *) n;
|
2001-10-18 19:30:21 +02:00
|
|
|
}
|
|
|
|
|
|
2008-04-29 16:59:17 +02:00
|
|
|
static Node *
|
2008-08-29 01:09:48 +02:00
|
|
|
makeStringConstCast(char *str, int location, TypeName *typename)
|
2008-04-29 16:59:17 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
Node *s = makeStringConst(str, location);
|
2008-04-29 16:59:17 +02:00
|
|
|
|
2008-08-29 01:09:48 +02:00
|
|
|
return makeTypeCast(s, typename, -1);
|
2008-04-29 16:59:17 +02:00
|
|
|
}
|
|
|
|
|
|
2002-04-21 21:21:49 +02:00
|
|
|
static Node *
|
2008-08-29 01:09:48 +02:00
|
|
|
makeIntConst(int val, int location)
|
2002-04-21 21:21:49 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
A_Const *n = makeNode(A_Const);
|
2008-04-29 16:59:17 +02:00
|
|
|
|
Remove Value node struct
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and the node
type don't match most of the time, and so it has to be treated
specially a lot. There doesn't seem to be any value in the special
construct. There is very little code that wants to accept all Value
variants but nothing else (and even if it did, this doesn't provide
any convenient way to check it), and most code wants either just one
particular node type (usually String), or it accepts a broader set of
node types besides just Value.
This change removes the Value struct and node type and replaces them
by separate Integer, Float, String, and BitString node types that are
proper node types and structs of their own and behave mostly like
normal node types.
Also, this removes the T_Null node tag, which was previously also a
possible variant of Value but wasn't actually used outside of the
Value contained in A_Const. Replace that by an isnull field in
A_Const.
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/5ba6bc5b-3f95-04f2-2419-f8ddb4c046fb@enterprisedb.com
2021-09-09 07:58:12 +02:00
|
|
|
n->val.ival.type = T_Integer;
|
2022-01-14 10:46:49 +01:00
|
|
|
n->val.ival.ival = val;
|
2008-08-29 01:09:48 +02:00
|
|
|
n->location = location;
|
2002-04-21 21:21:49 +02:00
|
|
|
|
2022-05-13 07:17:29 +02:00
|
|
|
return (Node *) n;
|
2002-04-21 21:21:49 +02:00
|
|
|
}
|
|
|
|
|
|
2001-10-18 19:30:21 +02:00
|
|
|
static Node *
|
2008-08-29 01:09:48 +02:00
|
|
|
makeFloatConst(char *str, int location)
|
2001-10-18 19:30:21 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
A_Const *n = makeNode(A_Const);
|
2002-03-29 20:06:29 +01:00
|
|
|
|
Remove Value node struct
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and the node
type don't match most of the time, and so it has to be treated
specially a lot. There doesn't seem to be any value in the special
construct. There is very little code that wants to accept all Value
variants but nothing else (and even if it did, this doesn't provide
any convenient way to check it), and most code wants either just one
particular node type (usually String), or it accepts a broader set of
node types besides just Value.
This change removes the Value struct and node type and replaces them
by separate Integer, Float, String, and BitString node types that are
proper node types and structs of their own and behave mostly like
normal node types.
Also, this removes the T_Null node tag, which was previously also a
possible variant of Value but wasn't actually used outside of the
Value contained in A_Const. Replace that by an isnull field in
A_Const.
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/5ba6bc5b-3f95-04f2-2419-f8ddb4c046fb@enterprisedb.com
2021-09-09 07:58:12 +02:00
|
|
|
n->val.fval.type = T_Float;
|
2022-01-14 10:46:49 +01:00
|
|
|
n->val.fval.fval = str;
|
2008-08-29 01:09:48 +02:00
|
|
|
n->location = location;
|
2001-10-18 19:30:21 +02:00
|
|
|
|
2022-05-13 07:17:29 +02:00
|
|
|
return (Node *) n;
|
2008-04-29 22:44:49 +02:00
|
|
|
}
|
|
|
|
|
|
2022-01-14 10:46:49 +01:00
|
|
|
static Node *
|
|
|
|
|
makeBoolAConst(bool state, int location)
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
A_Const *n = makeNode(A_Const);
|
2022-01-14 10:46:49 +01:00
|
|
|
|
|
|
|
|
n->val.boolval.type = T_Boolean;
|
|
|
|
|
n->val.boolval.boolval = state;
|
|
|
|
|
n->location = location;
|
|
|
|
|
|
2022-05-13 07:17:29 +02:00
|
|
|
return (Node *) n;
|
2022-01-14 10:46:49 +01:00
|
|
|
}
|
|
|
|
|
|
2008-04-29 22:44:49 +02:00
|
|
|
static Node *
|
2008-08-29 01:09:48 +02:00
|
|
|
makeBitStringConst(char *str, int location)
|
2008-04-29 22:44:49 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
A_Const *n = makeNode(A_Const);
|
2008-04-29 22:44:49 +02:00
|
|
|
|
Remove Value node struct
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and the node
type don't match most of the time, and so it has to be treated
specially a lot. There doesn't seem to be any value in the special
construct. There is very little code that wants to accept all Value
variants but nothing else (and even if it did, this doesn't provide
any convenient way to check it), and most code wants either just one
particular node type (usually String), or it accepts a broader set of
node types besides just Value.
This change removes the Value struct and node type and replaces them
by separate Integer, Float, String, and BitString node types that are
proper node types and structs of their own and behave mostly like
normal node types.
Also, this removes the T_Null node tag, which was previously also a
possible variant of Value but wasn't actually used outside of the
Value contained in A_Const. Replace that by an isnull field in
A_Const.
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/5ba6bc5b-3f95-04f2-2419-f8ddb4c046fb@enterprisedb.com
2021-09-09 07:58:12 +02:00
|
|
|
n->val.bsval.type = T_BitString;
|
2022-01-14 10:46:49 +01:00
|
|
|
n->val.bsval.bsval = str;
|
2008-08-29 01:09:48 +02:00
|
|
|
n->location = location;
|
2008-04-29 22:44:49 +02:00
|
|
|
|
2022-05-13 07:17:29 +02:00
|
|
|
return (Node *) n;
|
2008-04-29 22:44:49 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static Node *
|
2008-08-29 01:09:48 +02:00
|
|
|
makeNullAConst(int location)
|
2008-04-29 22:44:49 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
A_Const *n = makeNode(A_Const);
|
2008-04-29 22:44:49 +02:00
|
|
|
|
Remove Value node struct
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and the node
type don't match most of the time, and so it has to be treated
specially a lot. There doesn't seem to be any value in the special
construct. There is very little code that wants to accept all Value
variants but nothing else (and even if it did, this doesn't provide
any convenient way to check it), and most code wants either just one
particular node type (usually String), or it accepts a broader set of
node types besides just Value.
This change removes the Value struct and node type and replaces them
by separate Integer, Float, String, and BitString node types that are
proper node types and structs of their own and behave mostly like
normal node types.
Also, this removes the T_Null node tag, which was previously also a
possible variant of Value but wasn't actually used outside of the
Value contained in A_Const. Replace that by an isnull field in
A_Const.
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/5ba6bc5b-3f95-04f2-2419-f8ddb4c046fb@enterprisedb.com
2021-09-09 07:58:12 +02:00
|
|
|
n->isnull = true;
|
2008-08-29 01:09:48 +02:00
|
|
|
n->location = location;
|
2008-04-29 22:44:49 +02:00
|
|
|
|
2022-05-13 07:17:29 +02:00
|
|
|
return (Node *) n;
|
2001-10-18 19:30:21 +02:00
|
|
|
}
|
|
|
|
|
|
2002-04-21 21:21:49 +02:00
|
|
|
static Node *
|
Remove Value node struct
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and the node
type don't match most of the time, and so it has to be treated
specially a lot. There doesn't seem to be any value in the special
construct. There is very little code that wants to accept all Value
variants but nothing else (and even if it did, this doesn't provide
any convenient way to check it), and most code wants either just one
particular node type (usually String), or it accepts a broader set of
node types besides just Value.
This change removes the Value struct and node type and replaces them
by separate Integer, Float, String, and BitString node types that are
proper node types and structs of their own and behave mostly like
normal node types.
Also, this removes the T_Null node tag, which was previously also a
possible variant of Value but wasn't actually used outside of the
Value contained in A_Const. Replace that by an isnull field in
A_Const.
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/5ba6bc5b-3f95-04f2-2419-f8ddb4c046fb@enterprisedb.com
2021-09-09 07:58:12 +02:00
|
|
|
makeAConst(Node *v, int location)
|
2002-04-21 21:21:49 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
Node *n;
|
2002-04-21 21:21:49 +02:00
|
|
|
|
|
|
|
|
switch (v->type)
|
|
|
|
|
{
|
|
|
|
|
case T_Float:
|
2022-01-14 10:46:49 +01:00
|
|
|
n = makeFloatConst(castNode(Float, v)->fval, location);
|
2002-04-21 21:21:49 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case T_Integer:
|
2022-01-14 10:46:49 +01:00
|
|
|
n = makeIntConst(castNode(Integer, v)->ival, location);
|
2002-04-21 21:21:49 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
default:
|
2022-01-14 10:46:49 +01:00
|
|
|
/* currently not used */
|
|
|
|
|
Assert(false);
|
|
|
|
|
n = NULL;
|
2002-04-21 21:21:49 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return n;
|
|
|
|
|
}
|
|
|
|
|
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
/* makeRoleSpec
|
|
|
|
|
* Create a RoleSpec with the given type
|
|
|
|
|
*/
|
2016-12-28 18:00:00 +01:00
|
|
|
static RoleSpec *
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
makeRoleSpec(RoleSpecType type, int location)
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
RoleSpec *spec = makeNode(RoleSpec);
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
|
|
|
|
|
spec->roletype = type;
|
|
|
|
|
spec->location = location;
|
|
|
|
|
|
2016-12-28 18:00:00 +01:00
|
|
|
return spec;
|
Allow CURRENT/SESSION_USER to be used in certain commands
Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.
This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named "current_user".
The special role specifiers PUBLIC and NONE also have more consistent
handling now.
Also take the opportunity to add location tracking to user specifiers.
Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.
2015-03-09 19:41:54 +01:00
|
|
|
}
|
|
|
|
|
|
2004-11-08 05:02:20 +01:00
|
|
|
/* check_qualified_name --- check the result of qualified_name production
|
|
|
|
|
*
|
|
|
|
|
* It's easiest to let the grammar production for qualified_name allow
|
|
|
|
|
* subscripts and '*', which we then must reject here.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
2009-11-09 19:38:48 +01:00
|
|
|
check_qualified_name(List *names, core_yyscan_t yyscanner)
|
2004-11-08 05:02:20 +01:00
|
|
|
{
|
|
|
|
|
ListCell *i;
|
|
|
|
|
|
|
|
|
|
foreach(i, names)
|
|
|
|
|
{
|
|
|
|
|
if (!IsA(lfirst(i), String))
|
2009-07-13 04:02:20 +02:00
|
|
|
parser_yyerror("syntax error");
|
2004-11-08 05:02:20 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2004-06-09 21:08:20 +02:00
|
|
|
/* check_func_name --- check the result of func_name production
|
|
|
|
|
*
|
|
|
|
|
* It's easiest to let the grammar production for func_name allow subscripts
|
|
|
|
|
* and '*', which we then must reject here.
|
|
|
|
|
*/
|
|
|
|
|
static List *
|
2009-11-09 19:38:48 +01:00
|
|
|
check_func_name(List *names, core_yyscan_t yyscanner)
|
2004-06-09 21:08:20 +02:00
|
|
|
{
|
|
|
|
|
ListCell *i;
|
|
|
|
|
|
|
|
|
|
foreach(i, names)
|
|
|
|
|
{
|
|
|
|
|
if (!IsA(lfirst(i), String))
|
2009-07-13 04:02:20 +02:00
|
|
|
parser_yyerror("syntax error");
|
2004-06-09 21:08:20 +02:00
|
|
|
}
|
|
|
|
|
return names;
|
|
|
|
|
}
|
|
|
|
|
|
2008-08-30 03:39:14 +02:00
|
|
|
/* check_indirection --- check the result of indirection production
|
|
|
|
|
*
|
|
|
|
|
* We only allow '*' at the end of the list, but it's hard to enforce that
|
|
|
|
|
* in the grammar, so do it here.
|
|
|
|
|
*/
|
|
|
|
|
static List *
|
2009-11-09 19:38:48 +01:00
|
|
|
check_indirection(List *indirection, core_yyscan_t yyscanner)
|
2008-08-30 03:39:14 +02:00
|
|
|
{
|
|
|
|
|
ListCell *l;
|
|
|
|
|
|
|
|
|
|
foreach(l, indirection)
|
|
|
|
|
{
|
|
|
|
|
if (IsA(lfirst(l), A_Star))
|
|
|
|
|
{
|
Represent Lists as expansible arrays, not chains of cons-cells.
Originally, Postgres Lists were a more or less exact reimplementation of
Lisp lists, which consist of chains of separately-allocated cons cells,
each having a value and a next-cell link. We'd hacked that once before
(commit d0b4399d8) to add a separate List header, but the data was still
in cons cells. That makes some operations -- notably list_nth() -- O(N),
and it's bulky because of the next-cell pointers and per-cell palloc
overhead, and it's very cache-unfriendly if the cons cells end up
scattered around rather than being adjacent.
In this rewrite, we still have List headers, but the data is in a
resizable array of values, with no next-cell links. Now we need at
most two palloc's per List, and often only one, since we can allocate
some values in the same palloc call as the List header. (Of course,
extending an existing List may require repalloc's to enlarge the array.
But this involves just O(log N) allocations not O(N).)
Of course this is not without downsides. The key difficulty is that
addition or deletion of a list entry may now cause other entries to
move, which it did not before.
For example, that breaks foreach() and sister macros, which historically
used a pointer to the current cons-cell as loop state. We can repair
those macros transparently by making their actual loop state be an
integer list index; the exposed "ListCell *" pointer is no longer state
carried across loop iterations, but is just a derived value. (In
practice, modern compilers can optimize things back to having just one
loop state value, at least for simple cases with inline loop bodies.)
In principle, this is a semantics change for cases where the loop body
inserts or deletes list entries ahead of the current loop index; but
I found no such cases in the Postgres code.
The change is not at all transparent for code that doesn't use foreach()
but chases lists "by hand" using lnext(). The largest share of such
code in the backend is in loops that were maintaining "prev" and "next"
variables in addition to the current-cell pointer, in order to delete
list cells efficiently using list_delete_cell(). However, we no longer
need a previous-cell pointer to delete a list cell efficiently. Keeping
a next-cell pointer doesn't work, as explained above, but we can improve
matters by changing such code to use a regular foreach() loop and then
using the new macro foreach_delete_current() to delete the current cell.
(This macro knows how to update the associated foreach loop's state so
that no cells will be missed in the traversal.)
There remains a nontrivial risk of code assuming that a ListCell *
pointer will remain good over an operation that could now move the list
contents. To help catch such errors, list.c can be compiled with a new
define symbol DEBUG_LIST_MEMORY_USAGE that forcibly moves list contents
whenever that could possibly happen. This makes list operations
significantly more expensive so it's not normally turned on (though it
is on by default if USE_VALGRIND is on).
There are two notable API differences from the previous code:
* lnext() now requires the List's header pointer in addition to the
current cell's address.
* list_delete_cell() no longer requires a previous-cell argument.
These changes are somewhat unfortunate, but on the other hand code using
either function needs inspection to see if it is assuming anything
it shouldn't, so it's not all bad.
Programmers should be aware of these significant performance changes:
* list_nth() and related functions are now O(1); so there's no
major access-speed difference between a list and an array.
* Inserting or deleting a list element now takes time proportional to
the distance to the end of the list, due to moving the array elements.
(However, it typically *doesn't* require palloc or pfree, so except in
long lists it's probably still faster than before.) Notably, lcons()
used to be about the same cost as lappend(), but that's no longer true
if the list is long. Code that uses lcons() and list_delete_first()
to maintain a stack might usefully be rewritten to push and pop at the
end of the list rather than the beginning.
* There are now list_insert_nth...() and list_delete_nth...() functions
that add or remove a list cell identified by index. These have the
data-movement penalty explained above, but there's no search penalty.
* list_concat() and variants now copy the second list's data into
storage belonging to the first list, so there is no longer any
sharing of cells between the input lists. The second argument is
now declared "const List *" to reflect that it isn't changed.
This patch just does the minimum needed to get the new implementation
in place and fix bugs exposed by the regression tests. As suggested
by the foregoing, there's a fair amount of followup work remaining to
do.
Also, the ENABLE_LIST_COMPAT macros are finally removed in this
commit. Code using those should have been gone a dozen years ago.
Patch by me; thanks to David Rowley, Jesper Pedersen, and others
for review.
Discussion: https://postgr.es/m/11587.1550975080@sss.pgh.pa.us
2019-07-15 19:41:58 +02:00
|
|
|
if (lnext(indirection, l) != NULL)
|
2009-07-13 04:02:20 +02:00
|
|
|
parser_yyerror("improper use of \"*\"");
|
2008-08-30 03:39:14 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return indirection;
|
|
|
|
|
}
|
|
|
|
|
|
2004-01-07 00:55:19 +01:00
|
|
|
/* extractArgTypes()
|
|
|
|
|
* Given a list of FunctionParameter nodes, extract a list of just the
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
* argument types (TypeNames) for input parameters only. This is what
|
|
|
|
|
* is needed to look up an existing function, which is what is wanted by
|
|
|
|
|
* the productions that use this call.
|
2004-01-07 00:55:19 +01:00
|
|
|
*/
|
|
|
|
|
static List *
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
extractArgTypes(List *parameters)
|
2004-01-07 00:55:19 +01:00
|
|
|
{
|
|
|
|
|
List *result = NIL;
|
2004-05-26 06:41:50 +02:00
|
|
|
ListCell *i;
|
2004-01-07 00:55:19 +01:00
|
|
|
|
|
|
|
|
foreach(i, parameters)
|
|
|
|
|
{
|
|
|
|
|
FunctionParameter *p = (FunctionParameter *) lfirst(i);
|
|
|
|
|
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
if (p->mode != FUNC_PARAM_OUT && p->mode != FUNC_PARAM_TABLE)
|
2005-03-29 19:58:51 +02:00
|
|
|
result = lappend(result, p->argType);
|
2004-01-07 00:55:19 +01:00
|
|
|
}
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
/* extractAggrArgTypes()
|
|
|
|
|
* As above, but work from the output of the aggr_args production.
|
|
|
|
|
*/
|
|
|
|
|
static List *
|
|
|
|
|
extractAggrArgTypes(List *aggrargs)
|
|
|
|
|
{
|
|
|
|
|
Assert(list_length(aggrargs) == 2);
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
return extractArgTypes((List *) linitial(aggrargs));
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* makeOrderedSetArgs()
|
|
|
|
|
* Build the result of the aggr_args production (which see the comments for).
|
|
|
|
|
* This handles only the case where both given lists are nonempty, so that
|
|
|
|
|
* we have to deal with multiple VARIADIC arguments.
|
|
|
|
|
*/
|
|
|
|
|
static List *
|
|
|
|
|
makeOrderedSetArgs(List *directargs, List *orderedargs,
|
|
|
|
|
core_yyscan_t yyscanner)
|
|
|
|
|
{
|
|
|
|
|
FunctionParameter *lastd = (FunctionParameter *) llast(directargs);
|
Remove Value node struct
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and the node
type don't match most of the time, and so it has to be treated
specially a lot. There doesn't seem to be any value in the special
construct. There is very little code that wants to accept all Value
variants but nothing else (and even if it did, this doesn't provide
any convenient way to check it), and most code wants either just one
particular node type (usually String), or it accepts a broader set of
node types besides just Value.
This change removes the Value struct and node type and replaces them
by separate Integer, Float, String, and BitString node types that are
proper node types and structs of their own and behave mostly like
normal node types.
Also, this removes the T_Null node tag, which was previously also a
possible variant of Value but wasn't actually used outside of the
Value contained in A_Const. Replace that by an isnull field in
A_Const.
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/5ba6bc5b-3f95-04f2-2419-f8ddb4c046fb@enterprisedb.com
2021-09-09 07:58:12 +02:00
|
|
|
Integer *ndirectargs;
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
|
|
|
|
|
/* No restriction unless last direct arg is VARIADIC */
|
|
|
|
|
if (lastd->mode == FUNC_PARAM_VARIADIC)
|
|
|
|
|
{
|
|
|
|
|
FunctionParameter *firsto = (FunctionParameter *) linitial(orderedargs);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We ignore the names, though the aggr_arg production allows them;
|
|
|
|
|
* it doesn't allow default values, so those need not be checked.
|
|
|
|
|
*/
|
|
|
|
|
if (list_length(orderedargs) != 1 ||
|
|
|
|
|
firsto->mode != FUNC_PARAM_VARIADIC ||
|
|
|
|
|
!equal(lastd->argType, firsto->argType))
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
|
errmsg("an ordered-set aggregate with a VARIADIC direct argument must have one VARIADIC aggregated argument of the same data type"),
|
|
|
|
|
parser_errposition(exprLocation((Node *) firsto))));
|
|
|
|
|
|
|
|
|
|
/* OK, drop the duplicate VARIADIC argument from the internal form */
|
|
|
|
|
orderedargs = NIL;
|
|
|
|
|
}
|
|
|
|
|
|
2013-12-24 02:24:07 +01:00
|
|
|
/* don't merge into the next line, as list_concat changes directargs */
|
2020-10-08 00:41:39 +02:00
|
|
|
ndirectargs = makeInteger(list_length(directargs));
|
2013-12-24 02:24:07 +01:00
|
|
|
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
return list_make2(list_concat(directargs, orderedargs),
|
2020-10-08 00:41:39 +02:00
|
|
|
ndirectargs);
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
|
|
|
}
|
|
|
|
|
|
2000-11-05 01:15:54 +01:00
|
|
|
/* insertSelectOptions()
|
2002-07-04 17:24:11 +02:00
|
|
|
* Insert ORDER BY, etc into an already-constructed SelectStmt.
|
2000-11-05 01:15:54 +01:00
|
|
|
*
|
|
|
|
|
* This routine is just to avoid duplicating code in SelectStmt productions.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
insertSelectOptions(SelectStmt *stmt,
|
2006-04-30 20:30:40 +02:00
|
|
|
List *sortClause, List *lockingClause,
|
2020-04-07 22:22:13 +02:00
|
|
|
SelectLimit *limitClause,
|
2009-07-13 04:02:20 +02:00
|
|
|
WithClause *withClause,
|
2009-11-09 19:38:48 +01:00
|
|
|
core_yyscan_t yyscanner)
|
2000-11-05 01:15:54 +01:00
|
|
|
{
|
2008-10-04 23:56:55 +02:00
|
|
|
Assert(IsA(stmt, SelectStmt));
|
|
|
|
|
|
2000-11-05 01:15:54 +01:00
|
|
|
/*
|
|
|
|
|
* Tests here are to reject constructs like
|
|
|
|
|
* (SELECT foo ORDER BY bar) ORDER BY baz
|
|
|
|
|
*/
|
|
|
|
|
if (sortClause)
|
|
|
|
|
{
|
|
|
|
|
if (stmt->sortClause)
|
2003-07-19 22:20:53 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
2008-09-01 22:42:46 +02:00
|
|
|
errmsg("multiple ORDER BY clauses not allowed"),
|
2009-07-13 04:02:20 +02:00
|
|
|
parser_errposition(exprLocation((Node *) sortClause))));
|
2000-11-05 01:15:54 +01:00
|
|
|
stmt->sortClause = sortClause;
|
|
|
|
|
}
|
2006-04-30 20:30:40 +02:00
|
|
|
/* We can handle multiple locking clauses, though */
|
|
|
|
|
stmt->lockingClause = list_concat(stmt->lockingClause, lockingClause);
|
2020-04-07 22:22:13 +02:00
|
|
|
if (limitClause && limitClause->limitOffset)
|
2000-11-05 01:15:54 +01:00
|
|
|
{
|
|
|
|
|
if (stmt->limitOffset)
|
2003-07-19 22:20:53 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
2008-09-01 22:42:46 +02:00
|
|
|
errmsg("multiple OFFSET clauses not allowed"),
|
2020-04-07 22:22:13 +02:00
|
|
|
parser_errposition(exprLocation(limitClause->limitOffset))));
|
|
|
|
|
stmt->limitOffset = limitClause->limitOffset;
|
2000-11-05 01:15:54 +01:00
|
|
|
}
|
2020-04-07 22:22:13 +02:00
|
|
|
if (limitClause && limitClause->limitCount)
|
2000-11-05 01:15:54 +01:00
|
|
|
{
|
|
|
|
|
if (stmt->limitCount)
|
2003-07-19 22:20:53 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
2008-09-01 22:42:46 +02:00
|
|
|
errmsg("multiple LIMIT clauses not allowed"),
|
2020-04-07 22:22:13 +02:00
|
|
|
parser_errposition(exprLocation(limitClause->limitCount))));
|
|
|
|
|
stmt->limitCount = limitClause->limitCount;
|
|
|
|
|
}
|
|
|
|
|
if (limitClause && limitClause->limitOption != LIMIT_OPTION_DEFAULT)
|
|
|
|
|
{
|
|
|
|
|
if (stmt->limitOption)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("multiple limit options not allowed")));
|
|
|
|
|
if (!stmt->sortClause && limitClause->limitOption == LIMIT_OPTION_WITH_TIES)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
2020-09-14 06:42:07 +02:00
|
|
|
errmsg("WITH TIES cannot be specified without ORDER BY clause")));
|
2021-10-01 23:29:18 +02:00
|
|
|
if (limitClause->limitOption == LIMIT_OPTION_WITH_TIES && stmt->lockingClause)
|
|
|
|
|
{
|
|
|
|
|
ListCell *lc;
|
|
|
|
|
|
|
|
|
|
foreach(lc, stmt->lockingClause)
|
|
|
|
|
{
|
|
|
|
|
LockingClause *lock = lfirst_node(LockingClause, lc);
|
|
|
|
|
|
|
|
|
|
if (lock->waitPolicy == LockWaitSkip)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("%s and %s options cannot be used together",
|
|
|
|
|
"SKIP LOCKED", "WITH TIES")));
|
|
|
|
|
}
|
|
|
|
|
}
|
2020-04-07 22:22:13 +02:00
|
|
|
stmt->limitOption = limitClause->limitOption;
|
2000-11-05 01:15:54 +01:00
|
|
|
}
|
2008-10-04 23:56:55 +02:00
|
|
|
if (withClause)
|
|
|
|
|
{
|
|
|
|
|
if (stmt->withClause)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("multiple WITH clauses not allowed"),
|
2009-07-13 04:02:20 +02:00
|
|
|
parser_errposition(exprLocation((Node *) withClause))));
|
2008-10-04 23:56:55 +02:00
|
|
|
stmt->withClause = withClause;
|
|
|
|
|
}
|
2000-11-05 01:15:54 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static Node *
|
|
|
|
|
makeSetOp(SetOperation op, bool all, Node *larg, Node *rarg)
|
|
|
|
|
{
|
|
|
|
|
SelectStmt *n = makeNode(SelectStmt);
|
|
|
|
|
|
|
|
|
|
n->op = op;
|
|
|
|
|
n->all = all;
|
|
|
|
|
n->larg = (SelectStmt *) larg;
|
|
|
|
|
n->rarg = (SelectStmt *) rarg;
|
|
|
|
|
return (Node *) n;
|
2000-10-05 21:11:39 +02:00
|
|
|
}
|
|
|
|
|
|
2002-04-09 22:35:55 +02:00
|
|
|
/* SystemFuncName()
|
2002-07-04 17:24:11 +02:00
|
|
|
* Build a properly-qualified reference to a built-in function.
|
2002-04-09 22:35:55 +02:00
|
|
|
*/
|
|
|
|
|
List *
|
|
|
|
|
SystemFuncName(char *name)
|
|
|
|
|
{
|
2004-05-31 01:40:41 +02:00
|
|
|
return list_make2(makeString("pg_catalog"), makeString(name));
|
2002-04-09 22:35:55 +02:00
|
|
|
}
|
1997-11-10 16:22:36 +01:00
|
|
|
|
2002-05-03 02:32:19 +02:00
|
|
|
/* SystemTypeName()
|
2002-07-04 17:24:11 +02:00
|
|
|
* Build a properly-qualified reference to a built-in type.
|
2002-05-03 02:32:19 +02:00
|
|
|
*
|
|
|
|
|
* typmod is defaulted, but may be changed afterwards by caller.
|
2008-08-29 01:09:48 +02:00
|
|
|
* Likewise for the location.
|
2002-05-03 02:32:19 +02:00
|
|
|
*/
|
|
|
|
|
TypeName *
|
|
|
|
|
SystemTypeName(char *name)
|
|
|
|
|
{
|
2006-12-30 22:21:56 +01:00
|
|
|
return makeTypeNameFromNameList(list_make2(makeString("pg_catalog"),
|
|
|
|
|
makeString(name)));
|
2002-05-03 02:32:19 +02:00
|
|
|
}
|
|
|
|
|
|
2002-07-04 17:24:11 +02:00
|
|
|
/* doNegate()
|
|
|
|
|
* Handle negation of a numeric constant.
|
2000-02-24 02:59:17 +01:00
|
|
|
*
|
|
|
|
|
* Formerly, we did this here because the optimizer couldn't cope with
|
|
|
|
|
* indexquals that looked like "var = -4" --- it wants "var = const"
|
|
|
|
|
* and a unary minus operator applied to a constant didn't qualify.
|
|
|
|
|
* As of Postgres 7.0, that problem doesn't exist anymore because there
|
|
|
|
|
* is a constant-subexpression simplifier in the optimizer. However,
|
|
|
|
|
* there's still a good reason for doing this here, which is that we can
|
|
|
|
|
* postpone committing to a particular internal representation for simple
|
2002-06-17 22:27:43 +02:00
|
|
|
* negative constants. It's better to leave "-123.456" in string form
|
2000-02-24 02:59:17 +01:00
|
|
|
* until we know what the desired type is.
|
1999-03-18 22:39:56 +01:00
|
|
|
*/
|
2000-02-21 19:47:12 +01:00
|
|
|
static Node *
|
2006-03-14 23:48:25 +01:00
|
|
|
doNegate(Node *n, int location)
|
1999-03-18 22:39:56 +01:00
|
|
|
{
|
|
|
|
|
if (IsA(n, A_Const))
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
A_Const *con = (A_Const *) n;
|
1999-03-18 22:39:56 +01:00
|
|
|
|
2008-08-29 01:09:48 +02:00
|
|
|
/* report the constant's location as that of the '-' sign */
|
|
|
|
|
con->location = location;
|
|
|
|
|
|
Remove Value node struct
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and the node
type don't match most of the time, and so it has to be treated
specially a lot. There doesn't seem to be any value in the special
construct. There is very little code that wants to accept all Value
variants but nothing else (and even if it did, this doesn't provide
any convenient way to check it), and most code wants either just one
particular node type (usually String), or it accepts a broader set of
node types besides just Value.
This change removes the Value struct and node type and replaces them
by separate Integer, Float, String, and BitString node types that are
proper node types and structs of their own and behave mostly like
normal node types.
Also, this removes the T_Null node tag, which was previously also a
possible variant of Value but wasn't actually used outside of the
Value contained in A_Const. Replace that by an isnull field in
A_Const.
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/5ba6bc5b-3f95-04f2-2419-f8ddb4c046fb@enterprisedb.com
2021-09-09 07:58:12 +02:00
|
|
|
if (IsA(&con->val, Integer))
|
1999-03-18 22:39:56 +01:00
|
|
|
{
|
2022-01-14 10:46:49 +01:00
|
|
|
con->val.ival.ival = -con->val.ival.ival;
|
1999-03-18 22:39:56 +01:00
|
|
|
return n;
|
|
|
|
|
}
|
Remove Value node struct
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and the node
type don't match most of the time, and so it has to be treated
specially a lot. There doesn't seem to be any value in the special
construct. There is very little code that wants to accept all Value
variants but nothing else (and even if it did, this doesn't provide
any convenient way to check it), and most code wants either just one
particular node type (usually String), or it accepts a broader set of
node types besides just Value.
This change removes the Value struct and node type and replaces them
by separate Integer, Float, String, and BitString node types that are
proper node types and structs of their own and behave mostly like
normal node types.
Also, this removes the T_Null node tag, which was previously also a
possible variant of Value but wasn't actually used outside of the
Value contained in A_Const. Replace that by an isnull field in
A_Const.
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/5ba6bc5b-3f95-04f2-2419-f8ddb4c046fb@enterprisedb.com
2021-09-09 07:58:12 +02:00
|
|
|
if (IsA(&con->val, Float))
|
1999-03-18 22:39:56 +01:00
|
|
|
{
|
Remove Value node struct
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and the node
type don't match most of the time, and so it has to be treated
specially a lot. There doesn't seem to be any value in the special
construct. There is very little code that wants to accept all Value
variants but nothing else (and even if it did, this doesn't provide
any convenient way to check it), and most code wants either just one
particular node type (usually String), or it accepts a broader set of
node types besides just Value.
This change removes the Value struct and node type and replaces them
by separate Integer, Float, String, and BitString node types that are
proper node types and structs of their own and behave mostly like
normal node types.
Also, this removes the T_Null node tag, which was previously also a
possible variant of Value but wasn't actually used outside of the
Value contained in A_Const. Replace that by an isnull field in
A_Const.
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/5ba6bc5b-3f95-04f2-2419-f8ddb4c046fb@enterprisedb.com
2021-09-09 07:58:12 +02:00
|
|
|
doNegateFloat(&con->val.fval);
|
1999-03-18 22:39:56 +01:00
|
|
|
return n;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2006-03-14 23:48:25 +01:00
|
|
|
return (Node *) makeSimpleA_Expr(AEXPR_OP, "-", NULL, n, location);
|
1999-03-18 22:39:56 +01:00
|
|
|
}
|
2000-02-21 19:47:12 +01:00
|
|
|
|
|
|
|
|
static void
|
Remove Value node struct
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and the node
type don't match most of the time, and so it has to be treated
specially a lot. There doesn't seem to be any value in the special
construct. There is very little code that wants to accept all Value
variants but nothing else (and even if it did, this doesn't provide
any convenient way to check it), and most code wants either just one
particular node type (usually String), or it accepts a broader set of
node types besides just Value.
This change removes the Value struct and node type and replaces them
by separate Integer, Float, String, and BitString node types that are
proper node types and structs of their own and behave mostly like
normal node types.
Also, this removes the T_Null node tag, which was previously also a
possible variant of Value but wasn't actually used outside of the
Value contained in A_Const. Replace that by an isnull field in
A_Const.
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/5ba6bc5b-3f95-04f2-2419-f8ddb4c046fb@enterprisedb.com
2021-09-09 07:58:12 +02:00
|
|
|
doNegateFloat(Float *v)
|
2000-02-21 19:47:12 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
char *oldval = v->fval;
|
2000-02-21 19:47:12 +01:00
|
|
|
|
|
|
|
|
if (*oldval == '+')
|
|
|
|
|
oldval++;
|
|
|
|
|
if (*oldval == '-')
|
2022-01-14 10:46:49 +01:00
|
|
|
v->fval = oldval+1; /* just strip the '-' */
|
2000-02-21 19:47:12 +01:00
|
|
|
else
|
2022-01-14 10:46:49 +01:00
|
|
|
v->fval = psprintf("-%s", oldval);
|
2000-02-21 19:47:12 +01:00
|
|
|
}
|
2002-11-01 23:52:34 +01:00
|
|
|
|
2014-06-16 21:55:05 +02:00
|
|
|
static Node *
|
|
|
|
|
makeAndExpr(Node *lexpr, Node *rexpr, int location)
|
|
|
|
|
{
|
|
|
|
|
/* Flatten "a AND b AND c ..." to a single BoolExpr on sight */
|
2020-12-08 22:29:52 +01:00
|
|
|
if (IsA(lexpr, BoolExpr))
|
2014-06-16 21:55:05 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
BoolExpr *blexpr = (BoolExpr *) lexpr;
|
2014-06-16 21:55:05 +02:00
|
|
|
|
|
|
|
|
if (blexpr->boolop == AND_EXPR)
|
|
|
|
|
{
|
|
|
|
|
blexpr->args = lappend(blexpr->args, rexpr);
|
|
|
|
|
return (Node *) blexpr;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return (Node *) makeBoolExpr(AND_EXPR, list_make2(lexpr, rexpr), location);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static Node *
|
|
|
|
|
makeOrExpr(Node *lexpr, Node *rexpr, int location)
|
|
|
|
|
{
|
|
|
|
|
/* Flatten "a OR b OR c ..." to a single BoolExpr on sight */
|
2020-12-08 22:29:52 +01:00
|
|
|
if (IsA(lexpr, BoolExpr))
|
2014-06-16 21:55:05 +02:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
BoolExpr *blexpr = (BoolExpr *) lexpr;
|
2014-06-16 21:55:05 +02:00
|
|
|
|
|
|
|
|
if (blexpr->boolop == OR_EXPR)
|
|
|
|
|
{
|
|
|
|
|
blexpr->args = lappend(blexpr->args, rexpr);
|
|
|
|
|
return (Node *) blexpr;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return (Node *) makeBoolExpr(OR_EXPR, list_make2(lexpr, rexpr), location);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static Node *
|
|
|
|
|
makeNotExpr(Node *expr, int location)
|
|
|
|
|
{
|
|
|
|
|
return (Node *) makeBoolExpr(NOT_EXPR, list_make1(expr), location);
|
|
|
|
|
}
|
|
|
|
|
|
2008-03-20 22:42:48 +01:00
|
|
|
static Node *
|
2008-08-29 01:09:48 +02:00
|
|
|
makeAArrayExpr(List *elements, int location)
|
2008-03-20 22:42:48 +01:00
|
|
|
{
|
|
|
|
|
A_ArrayExpr *n = makeNode(A_ArrayExpr);
|
|
|
|
|
|
|
|
|
|
n->elements = elements;
|
2008-08-29 01:09:48 +02:00
|
|
|
n->location = location;
|
2008-03-20 22:42:48 +01:00
|
|
|
return (Node *) n;
|
|
|
|
|
}
|
|
|
|
|
|
2006-12-21 17:05:16 +01:00
|
|
|
static Node *
|
2008-08-29 01:09:48 +02:00
|
|
|
makeXmlExpr(XmlExprOp op, char *name, List *named_args, List *args,
|
|
|
|
|
int location)
|
2006-12-21 17:05:16 +01:00
|
|
|
{
|
2011-11-01 20:50:00 +01:00
|
|
|
XmlExpr *x = makeNode(XmlExpr);
|
2006-12-24 01:29:20 +01:00
|
|
|
|
2006-12-21 17:05:16 +01:00
|
|
|
x->op = op;
|
|
|
|
|
x->name = name;
|
2006-12-24 01:29:20 +01:00
|
|
|
/*
|
|
|
|
|
* named_args is a list of ResTarget; it'll be split apart into separate
|
|
|
|
|
* expression and name lists in transformXmlExpr().
|
|
|
|
|
*/
|
2006-12-21 17:05:16 +01:00
|
|
|
x->named_args = named_args;
|
2006-12-24 01:29:20 +01:00
|
|
|
x->arg_names = NIL;
|
2006-12-21 17:05:16 +01:00
|
|
|
x->args = args;
|
2008-08-29 01:09:48 +02:00
|
|
|
/* xmloption, if relevant, must be filled in by caller */
|
|
|
|
|
/* type and typmod will be filled in during parse analysis */
|
2012-12-23 20:07:24 +01:00
|
|
|
x->type = InvalidOid; /* marks the node as not analyzed */
|
2008-08-29 01:09:48 +02:00
|
|
|
x->location = location;
|
2006-12-21 17:05:16 +01:00
|
|
|
return (Node *) x;
|
|
|
|
|
}
|
|
|
|
|
|
2008-07-18 05:32:53 +02:00
|
|
|
/*
|
|
|
|
|
* Merge the input and output parameters of a table function.
|
|
|
|
|
*/
|
|
|
|
|
static List *
|
|
|
|
|
mergeTableFuncParameters(List *func_args, List *columns)
|
|
|
|
|
{
|
|
|
|
|
ListCell *lc;
|
|
|
|
|
|
|
|
|
|
/* Explicit OUT and INOUT parameters shouldn't be used in this syntax */
|
|
|
|
|
foreach(lc, func_args)
|
|
|
|
|
{
|
|
|
|
|
FunctionParameter *p = (FunctionParameter *) lfirst(lc);
|
|
|
|
|
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
if (p->mode != FUNC_PARAM_DEFAULT &&
|
|
|
|
|
p->mode != FUNC_PARAM_IN &&
|
|
|
|
|
p->mode != FUNC_PARAM_VARIADIC)
|
2008-07-18 05:32:53 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("OUT and INOUT arguments aren't allowed in TABLE functions")));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return list_concat(func_args, columns);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Determine return type of a TABLE function. A single result column
|
|
|
|
|
* returns setof that column's type; otherwise return setof record.
|
|
|
|
|
*/
|
|
|
|
|
static TypeName *
|
|
|
|
|
TableFuncTypeName(List *columns)
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
TypeName *result;
|
2008-07-18 05:32:53 +02:00
|
|
|
|
|
|
|
|
if (list_length(columns) == 1)
|
|
|
|
|
{
|
|
|
|
|
FunctionParameter *p = (FunctionParameter *) linitial(columns);
|
|
|
|
|
|
2017-03-09 21:18:59 +01:00
|
|
|
result = copyObject(p->argType);
|
2008-07-18 05:32:53 +02:00
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
result = SystemTypeName("record");
|
|
|
|
|
|
|
|
|
|
result->setof = true;
|
|
|
|
|
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
2010-09-26 13:41:03 +02:00
|
|
|
/*
|
|
|
|
|
* Convert a list of (dotted) names to a RangeVar (like
|
|
|
|
|
* makeRangeVarFromNameList, but with position support). The
|
|
|
|
|
* "AnyName" refers to the any_name production in the grammar.
|
|
|
|
|
*/
|
|
|
|
|
static RangeVar *
|
|
|
|
|
makeRangeVarFromAnyName(List *names, int position, core_yyscan_t yyscanner)
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
RangeVar *r = makeNode(RangeVar);
|
2010-09-26 13:41:03 +02:00
|
|
|
|
|
|
|
|
switch (list_length(names))
|
|
|
|
|
{
|
|
|
|
|
case 1:
|
|
|
|
|
r->catalogname = NULL;
|
|
|
|
|
r->schemaname = NULL;
|
|
|
|
|
r->relname = strVal(linitial(names));
|
|
|
|
|
break;
|
|
|
|
|
case 2:
|
|
|
|
|
r->catalogname = NULL;
|
|
|
|
|
r->schemaname = strVal(linitial(names));
|
|
|
|
|
r->relname = strVal(lsecond(names));
|
|
|
|
|
break;
|
|
|
|
|
case 3:
|
2015-03-31 14:12:27 +02:00
|
|
|
r->catalogname = strVal(linitial(names));
|
2010-09-26 13:41:03 +02:00
|
|
|
r->schemaname = strVal(lsecond(names));
|
|
|
|
|
r->relname = strVal(lthird(names));
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("improper qualified name (too many dotted names): %s",
|
|
|
|
|
NameListToString(names)),
|
|
|
|
|
parser_errposition(position)));
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2010-12-13 18:34:26 +01:00
|
|
|
r->relpersistence = RELPERSISTENCE_PERMANENT;
|
2010-09-26 13:41:03 +02:00
|
|
|
r->location = position;
|
|
|
|
|
|
|
|
|
|
return r;
|
|
|
|
|
}
|
|
|
|
|
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
/*
|
|
|
|
|
* Convert a relation_name with name and namelist to a RangeVar using
|
|
|
|
|
* makeRangeVar.
|
|
|
|
|
*/
|
|
|
|
|
static RangeVar *
|
|
|
|
|
makeRangeVarFromQualifiedName(char *name, List *namelist, int location,
|
|
|
|
|
core_yyscan_t yyscanner)
|
|
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
RangeVar *r;
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
|
|
|
|
|
check_qualified_name(namelist, yyscanner);
|
|
|
|
|
r = makeRangeVar(NULL, NULL, location);
|
|
|
|
|
|
|
|
|
|
switch (list_length(namelist))
|
|
|
|
|
{
|
|
|
|
|
case 1:
|
|
|
|
|
r->catalogname = NULL;
|
|
|
|
|
r->schemaname = name;
|
|
|
|
|
r->relname = strVal(linitial(namelist));
|
|
|
|
|
break;
|
|
|
|
|
case 2:
|
|
|
|
|
r->catalogname = name;
|
|
|
|
|
r->schemaname = strVal(linitial(namelist));
|
|
|
|
|
r->relname = strVal(lsecond(namelist));
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("improper qualified name (too many dotted names): %s",
|
|
|
|
|
NameListToString(lcons(makeString(name), namelist))),
|
|
|
|
|
parser_errposition(location));
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return r;
|
|
|
|
|
}
|
|
|
|
|
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
/* Separate Constraint nodes from COLLATE clauses in a ColQualList */
|
|
|
|
|
static void
|
|
|
|
|
SplitColQualList(List *qualList,
|
|
|
|
|
List **constraintList, CollateClause **collClause,
|
|
|
|
|
core_yyscan_t yyscanner)
|
|
|
|
|
{
|
|
|
|
|
ListCell *cell;
|
|
|
|
|
|
|
|
|
|
*collClause = NULL;
|
Represent Lists as expansible arrays, not chains of cons-cells.
Originally, Postgres Lists were a more or less exact reimplementation of
Lisp lists, which consist of chains of separately-allocated cons cells,
each having a value and a next-cell link. We'd hacked that once before
(commit d0b4399d8) to add a separate List header, but the data was still
in cons cells. That makes some operations -- notably list_nth() -- O(N),
and it's bulky because of the next-cell pointers and per-cell palloc
overhead, and it's very cache-unfriendly if the cons cells end up
scattered around rather than being adjacent.
In this rewrite, we still have List headers, but the data is in a
resizable array of values, with no next-cell links. Now we need at
most two palloc's per List, and often only one, since we can allocate
some values in the same palloc call as the List header. (Of course,
extending an existing List may require repalloc's to enlarge the array.
But this involves just O(log N) allocations not O(N).)
Of course this is not without downsides. The key difficulty is that
addition or deletion of a list entry may now cause other entries to
move, which it did not before.
For example, that breaks foreach() and sister macros, which historically
used a pointer to the current cons-cell as loop state. We can repair
those macros transparently by making their actual loop state be an
integer list index; the exposed "ListCell *" pointer is no longer state
carried across loop iterations, but is just a derived value. (In
practice, modern compilers can optimize things back to having just one
loop state value, at least for simple cases with inline loop bodies.)
In principle, this is a semantics change for cases where the loop body
inserts or deletes list entries ahead of the current loop index; but
I found no such cases in the Postgres code.
The change is not at all transparent for code that doesn't use foreach()
but chases lists "by hand" using lnext(). The largest share of such
code in the backend is in loops that were maintaining "prev" and "next"
variables in addition to the current-cell pointer, in order to delete
list cells efficiently using list_delete_cell(). However, we no longer
need a previous-cell pointer to delete a list cell efficiently. Keeping
a next-cell pointer doesn't work, as explained above, but we can improve
matters by changing such code to use a regular foreach() loop and then
using the new macro foreach_delete_current() to delete the current cell.
(This macro knows how to update the associated foreach loop's state so
that no cells will be missed in the traversal.)
There remains a nontrivial risk of code assuming that a ListCell *
pointer will remain good over an operation that could now move the list
contents. To help catch such errors, list.c can be compiled with a new
define symbol DEBUG_LIST_MEMORY_USAGE that forcibly moves list contents
whenever that could possibly happen. This makes list operations
significantly more expensive so it's not normally turned on (though it
is on by default if USE_VALGRIND is on).
There are two notable API differences from the previous code:
* lnext() now requires the List's header pointer in addition to the
current cell's address.
* list_delete_cell() no longer requires a previous-cell argument.
These changes are somewhat unfortunate, but on the other hand code using
either function needs inspection to see if it is assuming anything
it shouldn't, so it's not all bad.
Programmers should be aware of these significant performance changes:
* list_nth() and related functions are now O(1); so there's no
major access-speed difference between a list and an array.
* Inserting or deleting a list element now takes time proportional to
the distance to the end of the list, due to moving the array elements.
(However, it typically *doesn't* require palloc or pfree, so except in
long lists it's probably still faster than before.) Notably, lcons()
used to be about the same cost as lappend(), but that's no longer true
if the list is long. Code that uses lcons() and list_delete_first()
to maintain a stack might usefully be rewritten to push and pop at the
end of the list rather than the beginning.
* There are now list_insert_nth...() and list_delete_nth...() functions
that add or remove a list cell identified by index. These have the
data-movement penalty explained above, but there's no search penalty.
* list_concat() and variants now copy the second list's data into
storage belonging to the first list, so there is no longer any
sharing of cells between the input lists. The second argument is
now declared "const List *" to reflect that it isn't changed.
This patch just does the minimum needed to get the new implementation
in place and fix bugs exposed by the regression tests. As suggested
by the foregoing, there's a fair amount of followup work remaining to
do.
Also, the ENABLE_LIST_COMPAT macros are finally removed in this
commit. Code using those should have been gone a dozen years ago.
Patch by me; thanks to David Rowley, Jesper Pedersen, and others
for review.
Discussion: https://postgr.es/m/11587.1550975080@sss.pgh.pa.us
2019-07-15 19:41:58 +02:00
|
|
|
foreach(cell, qualList)
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
{
|
2022-05-13 07:17:29 +02:00
|
|
|
Node *n = (Node *) lfirst(cell);
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
|
|
|
|
|
if (IsA(n, Constraint))
|
|
|
|
|
{
|
|
|
|
|
/* keep it in list */
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
if (IsA(n, CollateClause))
|
|
|
|
|
{
|
|
|
|
|
CollateClause *c = (CollateClause *) n;
|
|
|
|
|
|
|
|
|
|
if (*collClause)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("multiple COLLATE clauses not allowed"),
|
|
|
|
|
parser_errposition(c->location)));
|
|
|
|
|
*collClause = c;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
elog(ERROR, "unexpected node type %d", (int) n->type);
|
|
|
|
|
/* remove non-Constraint nodes from qualList */
|
Represent Lists as expansible arrays, not chains of cons-cells.
Originally, Postgres Lists were a more or less exact reimplementation of
Lisp lists, which consist of chains of separately-allocated cons cells,
each having a value and a next-cell link. We'd hacked that once before
(commit d0b4399d8) to add a separate List header, but the data was still
in cons cells. That makes some operations -- notably list_nth() -- O(N),
and it's bulky because of the next-cell pointers and per-cell palloc
overhead, and it's very cache-unfriendly if the cons cells end up
scattered around rather than being adjacent.
In this rewrite, we still have List headers, but the data is in a
resizable array of values, with no next-cell links. Now we need at
most two palloc's per List, and often only one, since we can allocate
some values in the same palloc call as the List header. (Of course,
extending an existing List may require repalloc's to enlarge the array.
But this involves just O(log N) allocations not O(N).)
Of course this is not without downsides. The key difficulty is that
addition or deletion of a list entry may now cause other entries to
move, which it did not before.
For example, that breaks foreach() and sister macros, which historically
used a pointer to the current cons-cell as loop state. We can repair
those macros transparently by making their actual loop state be an
integer list index; the exposed "ListCell *" pointer is no longer state
carried across loop iterations, but is just a derived value. (In
practice, modern compilers can optimize things back to having just one
loop state value, at least for simple cases with inline loop bodies.)
In principle, this is a semantics change for cases where the loop body
inserts or deletes list entries ahead of the current loop index; but
I found no such cases in the Postgres code.
The change is not at all transparent for code that doesn't use foreach()
but chases lists "by hand" using lnext(). The largest share of such
code in the backend is in loops that were maintaining "prev" and "next"
variables in addition to the current-cell pointer, in order to delete
list cells efficiently using list_delete_cell(). However, we no longer
need a previous-cell pointer to delete a list cell efficiently. Keeping
a next-cell pointer doesn't work, as explained above, but we can improve
matters by changing such code to use a regular foreach() loop and then
using the new macro foreach_delete_current() to delete the current cell.
(This macro knows how to update the associated foreach loop's state so
that no cells will be missed in the traversal.)
There remains a nontrivial risk of code assuming that a ListCell *
pointer will remain good over an operation that could now move the list
contents. To help catch such errors, list.c can be compiled with a new
define symbol DEBUG_LIST_MEMORY_USAGE that forcibly moves list contents
whenever that could possibly happen. This makes list operations
significantly more expensive so it's not normally turned on (though it
is on by default if USE_VALGRIND is on).
There are two notable API differences from the previous code:
* lnext() now requires the List's header pointer in addition to the
current cell's address.
* list_delete_cell() no longer requires a previous-cell argument.
These changes are somewhat unfortunate, but on the other hand code using
either function needs inspection to see if it is assuming anything
it shouldn't, so it's not all bad.
Programmers should be aware of these significant performance changes:
* list_nth() and related functions are now O(1); so there's no
major access-speed difference between a list and an array.
* Inserting or deleting a list element now takes time proportional to
the distance to the end of the list, due to moving the array elements.
(However, it typically *doesn't* require palloc or pfree, so except in
long lists it's probably still faster than before.) Notably, lcons()
used to be about the same cost as lappend(), but that's no longer true
if the list is long. Code that uses lcons() and list_delete_first()
to maintain a stack might usefully be rewritten to push and pop at the
end of the list rather than the beginning.
* There are now list_insert_nth...() and list_delete_nth...() functions
that add or remove a list cell identified by index. These have the
data-movement penalty explained above, but there's no search penalty.
* list_concat() and variants now copy the second list's data into
storage belonging to the first list, so there is no longer any
sharing of cells between the input lists. The second argument is
now declared "const List *" to reflect that it isn't changed.
This patch just does the minimum needed to get the new implementation
in place and fix bugs exposed by the regression tests. As suggested
by the foregoing, there's a fair amount of followup work remaining to
do.
Also, the ENABLE_LIST_COMPAT macros are finally removed in this
commit. Code using those should have been gone a dozen years ago.
Patch by me; thanks to David Rowley, Jesper Pedersen, and others
for review.
Discussion: https://postgr.es/m/11587.1550975080@sss.pgh.pa.us
2019-07-15 19:41:58 +02:00
|
|
|
qualList = foreach_delete_current(qualList, cell);
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
}
|
|
|
|
|
*constraintList = qualList;
|
|
|
|
|
}
|
|
|
|
|
|
2011-06-16 01:05:11 +02:00
|
|
|
/*
|
|
|
|
|
* Process result of ConstraintAttributeSpec, and set appropriate bool flags
|
|
|
|
|
* in the output command node. Pass NULL for any flags the particular
|
|
|
|
|
* command doesn't support.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
processCASbits(int cas_bits, int location, const char *constrType,
|
|
|
|
|
bool *deferrable, bool *initdeferred, bool *not_valid,
|
2012-07-24 21:49:54 +02:00
|
|
|
bool *no_inherit, core_yyscan_t yyscanner)
|
2011-06-16 01:05:11 +02:00
|
|
|
{
|
|
|
|
|
/* defaults */
|
|
|
|
|
if (deferrable)
|
|
|
|
|
*deferrable = false;
|
|
|
|
|
if (initdeferred)
|
|
|
|
|
*initdeferred = false;
|
|
|
|
|
if (not_valid)
|
|
|
|
|
*not_valid = false;
|
|
|
|
|
|
|
|
|
|
if (cas_bits & (CAS_DEFERRABLE | CAS_INITIALLY_DEFERRED))
|
|
|
|
|
{
|
|
|
|
|
if (deferrable)
|
|
|
|
|
*deferrable = true;
|
|
|
|
|
else
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
|
/* translator: %s is CHECK, UNIQUE, or similar */
|
|
|
|
|
errmsg("%s constraints cannot be marked DEFERRABLE",
|
|
|
|
|
constrType),
|
|
|
|
|
parser_errposition(location)));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (cas_bits & CAS_INITIALLY_DEFERRED)
|
|
|
|
|
{
|
|
|
|
|
if (initdeferred)
|
|
|
|
|
*initdeferred = true;
|
|
|
|
|
else
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
|
/* translator: %s is CHECK, UNIQUE, or similar */
|
|
|
|
|
errmsg("%s constraints cannot be marked DEFERRABLE",
|
|
|
|
|
constrType),
|
|
|
|
|
parser_errposition(location)));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (cas_bits & CAS_NOT_VALID)
|
|
|
|
|
{
|
|
|
|
|
if (not_valid)
|
|
|
|
|
*not_valid = true;
|
|
|
|
|
else
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
|
/* translator: %s is CHECK, UNIQUE, or similar */
|
|
|
|
|
errmsg("%s constraints cannot be marked NOT VALID",
|
|
|
|
|
constrType),
|
|
|
|
|
parser_errposition(location)));
|
|
|
|
|
}
|
2012-07-24 21:49:54 +02:00
|
|
|
|
|
|
|
|
if (cas_bits & CAS_NO_INHERIT)
|
|
|
|
|
{
|
|
|
|
|
if (no_inherit)
|
|
|
|
|
*no_inherit = true;
|
|
|
|
|
else
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
|
/* translator: %s is CHECK, UNIQUE, or similar */
|
|
|
|
|
errmsg("%s constraints cannot be marked NO INHERIT",
|
|
|
|
|
constrType),
|
|
|
|
|
parser_errposition(location)));
|
|
|
|
|
}
|
2011-06-16 01:05:11 +02:00
|
|
|
}
|
|
|
|
|
|
2022-11-03 16:25:54 +01:00
|
|
|
/*
|
|
|
|
|
* Parse a user-supplied partition strategy string into parse node
|
|
|
|
|
* PartitionStrategy representation, or die trying.
|
|
|
|
|
*/
|
|
|
|
|
static PartitionStrategy
|
|
|
|
|
parsePartitionStrategy(char *strategy)
|
|
|
|
|
{
|
|
|
|
|
if (pg_strcasecmp(strategy, "list") == 0)
|
|
|
|
|
return PARTITION_STRATEGY_LIST;
|
|
|
|
|
else if (pg_strcasecmp(strategy, "range") == 0)
|
|
|
|
|
return PARTITION_STRATEGY_RANGE;
|
|
|
|
|
else if (pg_strcasecmp(strategy, "hash") == 0)
|
|
|
|
|
return PARTITION_STRATEGY_HASH;
|
2022-11-07 22:54:04 +01:00
|
|
|
|
2022-11-03 16:25:54 +01:00
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
|
|
|
|
errmsg("unrecognized partitioning strategy \"%s\"",
|
|
|
|
|
strategy)));
|
2022-11-07 22:54:04 +01:00
|
|
|
return PARTITION_STRATEGY_LIST; /* keep compiler quiet */
|
|
|
|
|
|
2022-11-03 16:25:54 +01:00
|
|
|
}
|
|
|
|
|
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
/*
|
|
|
|
|
* Process pubobjspec_list to check for errors in any of the objects and
|
|
|
|
|
* convert PUBLICATIONOBJ_CONTINUATION into appropriate PublicationObjSpecType.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
preprocess_pubobj_list(List *pubobjspec_list, core_yyscan_t yyscanner)
|
|
|
|
|
{
|
|
|
|
|
ListCell *cell;
|
|
|
|
|
PublicationObjSpec *pubobj;
|
|
|
|
|
PublicationObjSpecType prevobjtype = PUBLICATIONOBJ_CONTINUATION;
|
|
|
|
|
|
|
|
|
|
if (!pubobjspec_list)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
pubobj = (PublicationObjSpec *) linitial(pubobjspec_list);
|
|
|
|
|
if (pubobj->pubobjtype == PUBLICATIONOBJ_CONTINUATION)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
errcode(ERRCODE_SYNTAX_ERROR),
|
2021-12-30 23:24:26 +01:00
|
|
|
errmsg("invalid publication object list"),
|
2022-09-22 19:02:25 +02:00
|
|
|
errdetail("One of TABLE or TABLES IN SCHEMA must be specified before a standalone table or schema name."),
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
parser_errposition(pubobj->location));
|
|
|
|
|
|
|
|
|
|
foreach(cell, pubobjspec_list)
|
|
|
|
|
{
|
|
|
|
|
pubobj = (PublicationObjSpec *) lfirst(cell);
|
|
|
|
|
|
|
|
|
|
if (pubobj->pubobjtype == PUBLICATIONOBJ_CONTINUATION)
|
|
|
|
|
pubobj->pubobjtype = prevobjtype;
|
|
|
|
|
|
2022-04-07 18:13:13 +02:00
|
|
|
if (pubobj->pubobjtype == PUBLICATIONOBJ_TABLE)
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
{
|
|
|
|
|
/* relation name or pubtable must be set for this type of object */
|
|
|
|
|
if (!pubobj->name && !pubobj->pubtable)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("invalid table name at or near"),
|
|
|
|
|
parser_errposition(pubobj->location));
|
Allow specifying row filters for logical replication of tables.
This feature adds row filtering for publication tables. When a publication
is defined or modified, an optional WHERE clause can be specified. Rows
that don't satisfy this WHERE clause will be filtered out. This allows a
set of tables to be partially replicated. The row filter is per table. A
new row filter can be added simply by specifying a WHERE clause after the
table name. The WHERE clause must be enclosed by parentheses.
The row filter WHERE clause for a table added to a publication that
publishes UPDATE and/or DELETE operations must contain only columns that
are covered by REPLICA IDENTITY. The row filter WHERE clause for a table
added to a publication that publishes INSERT can use any column. If the
row filter evaluates to NULL, it is regarded as "false". The WHERE clause
only allows simple expressions that don't have user-defined functions,
user-defined operators, user-defined types, user-defined collations,
non-immutable built-in functions, or references to system columns. These
restrictions could be addressed in the future.
If you choose to do the initial table synchronization, only data that
satisfies the row filters is copied to the subscriber. If the subscription
has several publications in which a table has been published with
different WHERE clauses, rows that satisfy ANY of the expressions will be
copied. If a subscriber is a pre-15 version, the initial table
synchronization won't use row filters even if they are defined in the
publisher.
The row filters are applied before publishing the changes. If the
subscription has several publications in which the same table has been
published with different filters (for the same publish operation), those
expressions get OR'ed together so that rows satisfying any of the
expressions will be replicated.
This means all the other filters become redundant if (a) one of the
publications have no filter at all, (b) one of the publications was
created using FOR ALL TABLES, (c) one of the publications was created
using FOR ALL TABLES IN SCHEMA and the table belongs to that same schema.
If your publication contains a partitioned table, the publication
parameter publish_via_partition_root determines if it uses the partition's
row filter (if the parameter is false, the default) or the root
partitioned table's row filter.
Psql commands \dRp+ and \d <table-name> will display any row filters.
Author: Hou Zhijie, Euler Taveira, Peter Smith, Ajin Cherian
Reviewed-by: Greg Nancarrow, Haiying Tang, Amit Kapila, Tomas Vondra, Dilip Kumar, Vignesh C, Alvaro Herrera, Andres Freund, Wei Wang
Discussion: https://www.postgresql.org/message-id/flat/CAHE3wggb715X%2BmK_DitLXF25B%3DjE6xyNCH4YOwM860JR7HarGQ%40mail.gmail.com
2022-02-22 03:24:12 +01:00
|
|
|
|
|
|
|
|
if (pubobj->name)
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
{
|
|
|
|
|
/* convert it to PublicationTable */
|
|
|
|
|
PublicationTable *pubtable = makeNode(PublicationTable);
|
2021-12-30 23:24:26 +01:00
|
|
|
|
|
|
|
|
pubtable->relation =
|
|
|
|
|
makeRangeVar(NULL, pubobj->name, pubobj->location);
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
pubobj->pubtable = pubtable;
|
|
|
|
|
pubobj->name = NULL;
|
|
|
|
|
}
|
|
|
|
|
}
|
2021-12-30 23:24:26 +01:00
|
|
|
else if (pubobj->pubobjtype == PUBLICATIONOBJ_TABLES_IN_SCHEMA ||
|
|
|
|
|
pubobj->pubobjtype == PUBLICATIONOBJ_TABLES_IN_CUR_SCHEMA)
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
{
|
Allow specifying row filters for logical replication of tables.
This feature adds row filtering for publication tables. When a publication
is defined or modified, an optional WHERE clause can be specified. Rows
that don't satisfy this WHERE clause will be filtered out. This allows a
set of tables to be partially replicated. The row filter is per table. A
new row filter can be added simply by specifying a WHERE clause after the
table name. The WHERE clause must be enclosed by parentheses.
The row filter WHERE clause for a table added to a publication that
publishes UPDATE and/or DELETE operations must contain only columns that
are covered by REPLICA IDENTITY. The row filter WHERE clause for a table
added to a publication that publishes INSERT can use any column. If the
row filter evaluates to NULL, it is regarded as "false". The WHERE clause
only allows simple expressions that don't have user-defined functions,
user-defined operators, user-defined types, user-defined collations,
non-immutable built-in functions, or references to system columns. These
restrictions could be addressed in the future.
If you choose to do the initial table synchronization, only data that
satisfies the row filters is copied to the subscriber. If the subscription
has several publications in which a table has been published with
different WHERE clauses, rows that satisfy ANY of the expressions will be
copied. If a subscriber is a pre-15 version, the initial table
synchronization won't use row filters even if they are defined in the
publisher.
The row filters are applied before publishing the changes. If the
subscription has several publications in which the same table has been
published with different filters (for the same publish operation), those
expressions get OR'ed together so that rows satisfying any of the
expressions will be replicated.
This means all the other filters become redundant if (a) one of the
publications have no filter at all, (b) one of the publications was
created using FOR ALL TABLES, (c) one of the publications was created
using FOR ALL TABLES IN SCHEMA and the table belongs to that same schema.
If your publication contains a partitioned table, the publication
parameter publish_via_partition_root determines if it uses the partition's
row filter (if the parameter is false, the default) or the root
partitioned table's row filter.
Psql commands \dRp+ and \d <table-name> will display any row filters.
Author: Hou Zhijie, Euler Taveira, Peter Smith, Ajin Cherian
Reviewed-by: Greg Nancarrow, Haiying Tang, Amit Kapila, Tomas Vondra, Dilip Kumar, Vignesh C, Alvaro Herrera, Andres Freund, Wei Wang
Discussion: https://www.postgresql.org/message-id/flat/CAHE3wggb715X%2BmK_DitLXF25B%3DjE6xyNCH4YOwM860JR7HarGQ%40mail.gmail.com
2022-02-22 03:24:12 +01:00
|
|
|
/* WHERE clause is not allowed on a schema object */
|
|
|
|
|
if (pubobj->pubtable && pubobj->pubtable->whereClause)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("WHERE clause not allowed for schema"),
|
|
|
|
|
parser_errposition(pubobj->location));
|
|
|
|
|
|
Allow specifying column lists for logical replication
This allows specifying an optional column list when adding a table to
logical replication. The column list may be specified after the table
name, enclosed in parentheses. Columns not included in this list are not
sent to the subscriber, allowing the schema on the subscriber to be a
subset of the publisher schema.
For UPDATE/DELETE publications, the column list needs to cover all
REPLICA IDENTITY columns. For INSERT publications, the column list is
arbitrary and may omit some REPLICA IDENTITY columns. Furthermore, if
the table uses REPLICA IDENTITY FULL, column list is not allowed.
The column list can contain only simple column references. Complex
expressions, function calls etc. are not allowed. This restriction could
be relaxed in the future.
During the initial table synchronization, only columns included in the
column list are copied to the subscriber. If the subscription has
several publications, containing the same table with different column
lists, columns specified in any of the lists will be copied.
This means all columns are replicated if the table has no column list
at all (which is treated as column list with all columns), or when of
the publications is defined as FOR ALL TABLES (possibly IN SCHEMA that
matches the schema of the table).
For partitioned tables, publish_via_partition_root determines whether
the column list for the root or the leaf relation will be used. If the
parameter is 'false' (the default), the list defined for the leaf
relation is used. Otherwise, the column list for the root partition
will be used.
Psql commands \dRp+ and \d <table-name> now display any column lists.
Author: Tomas Vondra, Alvaro Herrera, Rahila Syed
Reviewed-by: Peter Eisentraut, Alvaro Herrera, Vignesh C, Ibrar Ahmed,
Amit Kapila, Hou zj, Peter Smith, Wang wei, Tang, Shi yu
Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektNRH8NJ1jf95g@mail.gmail.com
2022-03-26 00:45:21 +01:00
|
|
|
/* Column list is not allowed on a schema object */
|
|
|
|
|
if (pubobj->pubtable && pubobj->pubtable->columns)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("column specification not allowed for schema"),
|
|
|
|
|
parser_errposition(pubobj->location));
|
|
|
|
|
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
/*
|
|
|
|
|
* We can distinguish between the different type of schema
|
|
|
|
|
* objects based on whether name and pubtable is set.
|
|
|
|
|
*/
|
|
|
|
|
if (pubobj->name)
|
2021-12-30 23:24:26 +01:00
|
|
|
pubobj->pubobjtype = PUBLICATIONOBJ_TABLES_IN_SCHEMA;
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
else if (!pubobj->name && !pubobj->pubtable)
|
2021-12-30 23:24:26 +01:00
|
|
|
pubobj->pubobjtype = PUBLICATIONOBJ_TABLES_IN_CUR_SCHEMA;
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
else
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
|
errmsg("invalid schema name at or near"),
|
|
|
|
|
parser_errposition(pubobj->location));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
prevobjtype = pubobj->pubobjtype;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-02-01 04:31:58 +01:00
|
|
|
/*----------
|
|
|
|
|
* Recursive view transformation
|
|
|
|
|
*
|
|
|
|
|
* Convert
|
|
|
|
|
*
|
|
|
|
|
* CREATE RECURSIVE VIEW relname (aliases) AS query
|
|
|
|
|
*
|
|
|
|
|
* to
|
|
|
|
|
*
|
|
|
|
|
* CREATE VIEW relname (aliases) AS
|
|
|
|
|
* WITH RECURSIVE relname (aliases) AS (query)
|
|
|
|
|
* SELECT aliases FROM relname
|
|
|
|
|
*
|
|
|
|
|
* Actually, just the WITH ... part, which is then inserted into the original
|
|
|
|
|
* view definition as the query.
|
|
|
|
|
* ----------
|
|
|
|
|
*/
|
|
|
|
|
static Node *
|
|
|
|
|
makeRecursiveViewSelect(char *relname, List *aliases, Node *query)
|
|
|
|
|
{
|
|
|
|
|
SelectStmt *s = makeNode(SelectStmt);
|
|
|
|
|
WithClause *w = makeNode(WithClause);
|
|
|
|
|
CommonTableExpr *cte = makeNode(CommonTableExpr);
|
|
|
|
|
List *tl = NIL;
|
|
|
|
|
ListCell *lc;
|
|
|
|
|
|
|
|
|
|
/* create common table expression */
|
|
|
|
|
cte->ctename = relname;
|
|
|
|
|
cte->aliascolnames = aliases;
|
Allow user control of CTE materialization, and change the default behavior.
Historically we've always materialized the full output of a CTE query,
treating WITH as an optimization fence (so that, for example, restrictions
from the outer query cannot be pushed into it). This is appropriate when
the CTE query is INSERT/UPDATE/DELETE, or is recursive; but when the CTE
query is non-recursive and side-effect-free, there's no hazard of changing
the query results by pushing restrictions down.
Another argument for materialization is that it can avoid duplicate
computation of an expensive WITH query --- but that only applies if
the WITH query is called more than once in the outer query. Even then
it could still be a net loss, if each call has restrictions that
would allow just a small part of the WITH query to be computed.
Hence, let's change the behavior for WITH queries that are non-recursive
and side-effect-free. By default, we will inline them into the outer
query (removing the optimization fence) if they are called just once.
If they are called more than once, we will keep the old behavior by
default, but the user can override this and force inlining by specifying
NOT MATERIALIZED. Lastly, the user can force the old behavior by
specifying MATERIALIZED; this would mainly be useful when the query had
deliberately been employing WITH as an optimization fence to prevent a
poor choice of plan.
Andreas Karlsson, Andrew Gierth, David Fetter
Discussion: https://postgr.es/m/87sh48ffhb.fsf@news-spur.riddles.org.uk
2019-02-16 22:11:12 +01:00
|
|
|
cte->ctematerialized = CTEMaterializeDefault;
|
2013-02-01 04:31:58 +01:00
|
|
|
cte->ctequery = query;
|
|
|
|
|
cte->location = -1;
|
|
|
|
|
|
|
|
|
|
/* create WITH clause and attach CTE */
|
|
|
|
|
w->recursive = true;
|
|
|
|
|
w->ctes = list_make1(cte);
|
|
|
|
|
w->location = -1;
|
|
|
|
|
|
|
|
|
|
/* create target list for the new SELECT from the alias list of the
|
|
|
|
|
* recursive view specification */
|
|
|
|
|
foreach (lc, aliases)
|
|
|
|
|
{
|
|
|
|
|
ResTarget *rt = makeNode(ResTarget);
|
|
|
|
|
|
|
|
|
|
rt->name = NULL;
|
|
|
|
|
rt->indirection = NIL;
|
|
|
|
|
rt->val = makeColumnRef(strVal(lfirst(lc)), NIL, -1, 0);
|
|
|
|
|
rt->location = -1;
|
|
|
|
|
|
|
|
|
|
tl = lappend(tl, rt);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* create new SELECT combining WITH clause, target list, and fake FROM
|
|
|
|
|
* clause */
|
|
|
|
|
s->withClause = w;
|
|
|
|
|
s->targetList = tl;
|
|
|
|
|
s->fromClause = list_make1(makeRangeVar(NULL, relname, -1));
|
|
|
|
|
|
|
|
|
|
return (Node *) s;
|
|
|
|
|
}
|
|
|
|
|
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
/* parser_init()
|
|
|
|
|
* Initialize to parse one query string
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
parser_init(base_yy_extra_type *yyext)
|
|
|
|
|
{
|
|
|
|
|
yyext->parsetree = NIL; /* in case grammar forgets to set it */
|
|
|
|
|
}
|
