Обсуждение: Re: [HACKERS] [COMMITTERS] pgsql: Add pg_sequence system catalog
Peter, * Peter Eisentraut (peter_e@gmx.net) wrote: > Add pg_sequence system catalog The query this added to dumpSequence() seems to think that sequence names are unique across databases: appendPQExpBuffer(query, "SELECT seqstart, seqincrement, " "CASE WHEN seqincrement > 0 ANDseqmax = %s THEN NULL " " WHEN seqincrement < 0 AND seqmax = -1 THEN NULL " " ELSE seqmax " "END AS seqmax, " "CASE WHEN seqincrement > 0 AND seqmin = 1 THEN NULL " " WHEN seqincrement < 0 AND seqmin = %s THEN NULL " " ELSE seqmin " "END AS seqmin, " "seqcache, seqcycle " "FROM pg_class c " "JOIN pg_sequences ON (s.seqrelid = c.oid) " "WHERE relname = ", bufx, bufm); appendStringLiteralAH(query, tbinfo->dobj.name, fout); Note that tbinfo->dobj.name contains just the name, and trying to match based on just 'relname' isn't going to work since sequences with the same name can exist in difference schemas. I'd suggest using our usual approach in pg_dump, which is matching based on the OID, like so: WHERE c.oid = '%u'::oid The OID is in: tbinfo->dobj.catId.oid Also, you should move the selectSourceSchema() into the per-version branches and set it to 'pg_catalog' for PG10 and up, which would allow you to avoid having to qualify the table names, et al. As is, this query will also fail if a user has created a 'pg_class' or 'pg_sequence' table in their schema. Thanks! Stephen
Peter, all, * Stephen Frost (sfrost@snowman.net) wrote: > * Peter Eisentraut (peter_e@gmx.net) wrote: > > Add pg_sequence system catalog > > The query this added to dumpSequence() seems to think that sequence > names are unique across databases: Just FYI, I've added this to the PG10 open items list so it doesn't get forgotten (and so I can swap it out of my head and into a wiki): https://wiki.postgresql.org/wiki/PostgreSQL_10_Open_Items Thanks! Stephen
On 1/19/17 11:03 AM, Stephen Frost wrote: > I'd suggest using our usual approach in pg_dump, which is matching based > on the OID, like so: > > WHERE c.oid = '%u'::oid > > The OID is in: tbinfo->dobj.catId.oid > > Also, you should move the selectSourceSchema() into the per-version > branches and set it to 'pg_catalog' for PG10 and up, which would allow > you to avoid having to qualify the table names, et al. Does the attached patch look correct to you? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
Peter, * Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote: > On 1/19/17 11:03 AM, Stephen Frost wrote: > > I'd suggest using our usual approach in pg_dump, which is matching based > > on the OID, like so: > > > > WHERE c.oid = '%u'::oid > > > > The OID is in: tbinfo->dobj.catId.oid > > > > Also, you should move the selectSourceSchema() into the per-version > > branches and set it to 'pg_catalog' for PG10 and up, which would allow > > you to avoid having to qualify the table names, et al. > > Does the attached patch look correct to you? On a one-over, yes, that looks correct and avoids the issue of running in a user's schema. It wouldn't hurt to add a comment as to why things are so different in PG10 than other versions, ie: /** In PG10, sequence meta-data was moved into pg_sequence, so switch to* the pg_catalog schema instead of operating in auser schema and pull* the necessary meta-data from there.*/ Thanks! Stephen
On 1/24/17 10:23 AM, Stephen Frost wrote: > It wouldn't hurt to add a comment as to why things are so different in > PG10 than other versions, ie: > > /* > * In PG10, sequence meta-data was moved into pg_sequence, so switch to > * the pg_catalog schema instead of operating in a user schema and pull > * the necessary meta-data from there. > */ I've committed this, but I've put the comment in the old sections and explained how they are different from the new style, instead of vice versa. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services