Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch - Mailing list pgsql-patches

From Tom Lane
Subject Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch
Date
Msg-id 23808.1175710617@sss.pgh.pa.us
Whole thread Raw
In response to Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch  (Zoltan Boszormenyi <zb@cybertec.at>)
Responses Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch
List pgsql-patches
Zoltan Boszormenyi <zb@cybertec.at> writes:
>> Before you get too excited about making generated columns disappear
>> automatically in all these cases, consider that dropping a column
>> is not something to be done lightly --- it might contain irreplaceable
>> data.

> The standard says that the GENERATED column should be
> dropped silently if either of the referenced columns is dropped.

[ itch... ]  I think a pretty good case could be made for ignoring that
provision, on the grounds that it's a foot-gun, and that it's not very
important to follow the standard slavishly on this point because it's
hard to conceive of any application actually relying on that behavior.

You could probably implement the auto-drop behavior with some combination
of (a) AUTO rather than NORMAL dependencies from the default expression
to the stuff it depends on and (b) INTERNAL rather than AUTO dependency
from the default expression to its column.  But I really question
whether this is a good idea.

> The standard says somewhere that GENERATED columns
> can only be added to and dropped from a table.

This argument carries no weight at all --- there is plenty of stuff in
PG that is an extension of the capabilities listed in the spec.

            regards, tom lane

pgsql-patches by date:

Previous
From: Zoltan Boszormenyi
Date:
Subject: Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch
Next
From: Zoltan Boszormenyi
Date:
Subject: Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch