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 24900.1175713319@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  (Zoltan Boszormenyi <zb@cybertec.at>)
List pgsql-patches
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.

> 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...

            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: Andrew Dunstan
Date:
Subject: build/install xml2 when configured with libxml