On Wed, Oct 19, 2022 at 12:34 PM Mark Raynsford <co+org.postgresql@xxxxxxxx> wrote:
On 2022-10-19T11:58:07 -0700
"David G. Johnston" <david.g.johnston@xxxxxxxxx> wrote:
> On Wed, Oct 19, 2022 at 10:36 AM Mark Raynsford <co+org.postgresql@xxxxxxxx>
> wrote:
>
> > insert into t (y) values (t.x * 2);
> >
> > I can think of various ways to do it with multiple statements, but a
> > single statement would be preferable.
> >
> >
> No, by extension of the documented constraint: "The generation _expression_
> can refer to other columns in the table, but not other generated columns."
>
That's fine, but that's not what I was asking. In the table
above, `x` is generated without references to other columns, but for
the non-GENERATED `y` value, I want to refer to the value that `x` will
have when I calculate a value for the `y` column in the INSERT
statement.
Yes, I got that, but if another generated column cannot reference the resultant computation of a generated column anything you write, which is by definition computed before the generated column, is not going to be able to see the result of the generated column either. There was at least some hope for one generated depending upon another so the the expressions could maybe be evaluated in sequence.
Thus, while the docs do not explicitly state the non-functionality it can be inferred by what other non-functionality is stated.
David J.
