Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> 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.
Advertising
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/
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
