Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch
От | Zoltan Boszormenyi |
---|---|
Тема | Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch |
Дата | |
Msg-id | 4613F4FE.4070906@cybertec.at обсуждение исходный текст |
Ответ на | Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch
|
Список | pgsql-patches |
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/
В списке pgsql-patches по дате отправления: