Re: pg_sequence catalog - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_sequence catalog
Date
Msg-id 8910.1473085602@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_sequence catalog  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: pg_sequence catalog  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> On 4 September 2016 at 23:17, Greg Stark <stark@mit.edu> wrote:
>> So? Clients expect changes like this between major releases surely.
>> Subtle changes that cause silent breakage for end-users seems scarier
>> than unsubtle breakage that tool authors can fix.

> Agreed; some change in the behaviour if SELECT * FROM sequence is
> effectively part of this proposal. I was going to make the same
> comment myself.

Well, if we're going to blow off compatibility on that score, I suggest
that we blow it off all the way.  Make sequences not be relations anymore,
and what you do instead of "SELECT * FROM sequence" is "SELECT * FROM
pg_sequences WHERE seqname = 'sequence'".  Or more likely, since sequences
should still belong to schemas, we need a "regsequence" OID-alias type
like "regclass" and you do "SELECT * FROM pg_sequences WHERE oid =
'foo.bar'::regsequence".

The main problem I can see with this is that serial columns will
have default expressions that are written out as
"nextval('foo_f1_seq'::regclass)".  I do not think we can afford to break
dumps containing that, but I'm not sure how to get the regclass cast
replaced with a regsequence cast.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Ildar Musin
Date:
Subject: Re: Index Onlys Scan for expressions
Next
From: Simon Riggs
Date:
Subject: Re: new autovacuum criterion for visible pages