pgsql: Handle unqualified SEQUENCE NAME options properly in parse_utilc

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(-)

Browse pgsql-committers by date

  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.)