Re: The serial pseudotypes - Mailing list pgsql-hackers

From Vik Fearing
Subject Re: The serial pseudotypes
Date
Msg-id fd5e37cd-63be-c14f-86a2-01eb4a5e3cef@2ndquadrant.com
Whole thread Raw
In response to Re: The serial pseudotypes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 25/08/2019 19:42, Tom Lane wrote:
> Vik Fearing <vik.fearing@2ndquadrant.com> writes:
>> On 25/08/2019 18:59, Tom Lane wrote:
>>> Vik Fearing <vik.fearing@2ndquadrant.com> writes:
>>>> Is there a reason why the serial pseudotypes still behave as they did
>>>> pre-v10 and don't map to GENERATED BY DEFAULT AS IDENTITY these days?
>>> Backwards compatibility?
>> With what?
> Applications that expect declaring a serial column to result in the same
> catalog side-effects as before.  The default expressions look different,
> and the dependencies look different.  For instance, an app that expected
> atthasdef to tell it something about what happens when a column's value
> is omitted would be surprised.  An app that thought it could alter the
> default expression for a column originally declared serial would be even
> more surprised.
>
> Admittedly, many of these things look a lot like the sort of system
> catalog changes we make routinely and expect applications to cope.


Indeed.


> But I don't think this would be a cost-free change.  Serials have acted
> the way they do for a pretty long time.


I guess I'll keep telling people serials are obsolete then.

-- 

Vik Fearing




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: The serial pseudotypes
Next
From: Peter Geoghegan
Date:
Subject: "Classic" nbtree suffix truncation prototype