Re: pg_sequence catalog
От | Andres Freund |
---|---|
Тема | Re: pg_sequence catalog |
Дата | |
Msg-id | 5E90524D-1583-4972-A759-9BFC15EDA8DD@anarazel.de обсуждение исходный текст |
Ответ на | Re: pg_sequence catalog (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_sequence catalog
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: