On September 5, 2016 7:26:42 AM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>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.
Why not just continue having a pgclass entry, but no relfilenode?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
