Tom Lane írta:
> 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.
>
So, all dependency should be NORMAL to require
manual CASCADE to avoid accidental data loss.
I have two questions about the dependency system.
1. Is there a built-in defense to avoid circular dependencies?
2. If I register dependencies between column, is there a way
to retrieve all table/column type dependencies for a depender column?
What I would like to achieve is to lift the limit that
a GENERATED column cannot reference another one.
Only self-referencing should be disallowed.
>> 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.
>
Point taken. So, just like with SET / DROP IDENTITY,
I should implement SET GENERATED ALWAYS
and DROP GENERATED.
> regards, tom lane
>
>
--
----------------------------------
Zoltán Böszörményi
Cybertec Geschwinde & Schönig GmbH
http://www.postgresql.at/
