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 | 4613F922.1000005@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: > >> I have two questions about the dependency system. >> > > >> 1. Is there a built-in defense to avoid circular dependencies? >> > > It doesn't have a problem with them, if that's what you mean. > > >> 2. If I register dependencies between column, is there a way >> to retrieve all table/column type dependencies for a depender column? >> > > You can scan pg_depend. > > >> What I would like to achieve is to lift the limit that >> a GENERATED column cannot reference another one. >> > > I would counsel not doing that, mainly because then you will have to > solve an evaluation-order problem at runtime. > OK. >> Point taken. So, just like with SET / DROP IDENTITY, >> I should implement SET GENERATED ALWAYS >> and DROP GENERATED. >> > > If you think of it as a property of the default expression, then DROP > DEFAULT covers both cases, you don't need DROP GENERATED... > So, I should allow DROP DEFAULT, implement SET DEFAULT GENERATED ALWAYS AS and modify the catalog so the GENERATED property is part of pg_attrdef. What about IDENTITY? Should it also be part of pg_attrdef? There are two ways to implement it: have or don't have a notion of it. The latter would treat GENERATED BY DEFAULT AS IDENTITY the same as SERIAL. > regards, tom lane > -- ---------------------------------- Zoltán Böszörményi Cybertec Geschwinde & Schönig GmbH http://www.postgresql.at/
В списке pgsql-patches по дате отправления: