From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Handle unqualified SEQUENCE NAME options properly in parse_utilc |
Date: | 2017-06-11 23:00:09 |
Message-ID: | E1dKBq5-00058c-Cb@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Handle unqualified SEQUENCE NAME options properly in parse_utilcmd.c.
generateSerialExtraStmts() was sloppy about handling the case where
SEQUENCE NAME is given with a not-schema-qualified name. It was generating
a CreateSeqStmt with an unqualified sequence name, and an AlterSeqStmt
whose "owned_by" DefElem contained a T_String Value with a null string
pointer in the schema-name position. The generated nextval() argument was
also underqualified. This accidentally failed to fail at runtime, but only
so long as the current default creation namespace at runtime is the right
namespace. That's bogus; the parse-time transformation is supposed to be
inserting the right schema name in all cases, so as to avoid any possible
skew in that selection. I'm not sure this could fail in pg_dump's usage,
but it's still wrong; we have had real bugs in this area before adopting
the policy that parse_utilcmd.c should generate only fully-qualified
auxiliary commands. A slightly lesser problem, which is what led me to
notice this in the first place, is that pprint() dumped core on the
AlterSeqStmt because of the bogus T_String.
Noted while poking into the open problem with ALTER SEQUENCE breaking
pg_upgrade.
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/51893985d3bcf27304283f7fa67f17e017d2dafd
Modified Files
--------------
src/backend/parser/parse_utilcmd.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-06-12 00:35:27 | Re: pgsql: Apply RLS policies to partitioned tables. |
Previous Message | Piotr Stefaniak | 2017-06-11 21:14:36 | Re: pgindent (was Re: [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.) |