Thread: Column value derived from generated column in INSERT?
Hello! I'd like to be able to do something sort of analogous to this: create table t ( x integer not null generated always as identity, y integer not null ); insert into t (y) values (t.x * 2); In the real project, the "t.x * 2" expression is obviously something a lot more complex, but I think it illustrates the point: I'd like to be able to refer to the generated value of a column within the INSERT statement that's going to cause it to be generated. Is there a way to do this with a single statement right now? I can think of various ways to do it with multiple statements, but a single statement would be preferable. -- Mark Raynsford | https://www.io7m.com
On Wed, Oct 19, 2022 at 10:36 AM Mark Raynsford <co+org.postgresql@io7m.com> 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."
David J.
On 2022-10-19T11:58:07 -0700 "David G. Johnston" <david.g.johnston@gmail.com> wrote: > On Wed, Oct 19, 2022 at 10:36 AM Mark Raynsford <co+org.postgresql@io7m.com> > 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." > Hello! Just want to confirm that I wasn't misunderstood. The documentation in CREATE TABLE has the sentence you quoted above, and unless I'm misunderstanding that's saying that the expression used to generate values in GENERATED (ALWAYS AS) columns can't refer to 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. If that's not doable, that's fine, I just want to be sure. :) -- Mark Raynsford | https://www.io7m.com
On 10/19/22 12:30, Mark Raynsford wrote: > On 2022-10-19T11:58:07 -0700 > "David G. Johnston" <david.g.johnston@gmail.com> wrote: > >> On Wed, Oct 19, 2022 at 10:36 AM Mark Raynsford <co+org.postgresql@io7m.com> >> 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." >> > > Hello! > > Just want to confirm that I wasn't misunderstood. The documentation in > CREATE TABLE has the sentence you quoted above, and unless I'm > misunderstanding that's saying that the expression used to generate > values in GENERATED (ALWAYS AS) columns can't refer to 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. > > If that's not doable, that's fine, I just want to be sure. :) create table t ( x integer not null generated always as identity, y integer not null ); insert into t (y) values (t.x * 2); ERROR: invalid reference to FROM-clause entry for table "t" LINE 1: insert into t (y) values (t.x * 2); ^ HINT: There is an entry for table "t", but it cannot be referenced from this part of the query. insert into t (y) values (x * 2); ERROR: column "x" does not exist LINE 1: insert into t (y) values (x * 2); ^ HINT: There is a column named "x" in table "t", but it cannot be referenced from this part of the query. -- Adrian Klaver adrian.klaver@aklaver.com
On 2022-10-19T12:43:31 -0700 Adrian Klaver <adrian.klaver@aklaver.com> wrote: > > HINT: There is an entry for table "t", but it cannot be referenced from > this part of the query. > > HINT: There is a column named "x" in table "t", but it cannot be > referenced from this part of the query. Yes, I saw those, hence asking on the list if there was a way to do it. I'll handle it with multiple statements. -- Mark Raynsford | https://www.io7m.com
On 10/19/22 12:48, Mark Raynsford wrote: > On 2022-10-19T12:43:31 -0700 > Adrian Klaver <adrian.klaver@aklaver.com> wrote: >> >> HINT: There is an entry for table "t", but it cannot be referenced from >> this part of the query. >> >> HINT: There is a column named "x" in table "t", but it cannot be >> referenced from this part of the query. > > Yes, I saw those, hence asking on the list if there was a way to do it. Using a trigger. > > I'll handle it with multiple statements. > -- Adrian Klaver adrian.klaver@aklaver.com
On 10/19/22 12:58 PM, Adrian Klaver wrote: > On 10/19/22 12:48, Mark Raynsford wrote: >> On 2022-10-19T12:43:31 -0700 >> Adrian Klaver <adrian.klaver@aklaver.com> wrote: >>> >>> HINT: There is an entry for table "t", but it cannot be referenced from >>> this part of the query. >>> >>> HINT: There is a column named "x" in table "t", but it cannot be >>> referenced from this part of the query. >> >> Yes, I saw those, hence asking on the list if there was a way to do it. > > Using a trigger. To expand: create table t ( x integer not null generated always as identity, y integer not null ); insert into t(y) values (1); select * from t; x | y ---+--- 1 | 1 (1 row) CREATE FUNCTION identity_test( ) RETURNS trigger LANGUAGE plpgsql AS $function$ BEGIN NEW.y = NEW.x * 2; RETURN NEW; END; $function$ ; create trigger identity_trg before insert on t for each row execute function identity_test(); insert into t(y) values (0); select * from t; x | y ---+--- 1 | 1 2 | 4 (2 rows) > >> >> I'll handle it with multiple statements. >> > -- Adrian Klaver adrian.klaver@aklaver.com
> On 19/10/2022 23:51 CEST Adrian Klaver <adrian.klaver@aklaver.com> wrote: > > On 10/19/22 12:58 PM, Adrian Klaver wrote: > > On 10/19/22 12:48, Mark Raynsford wrote: > >> On 2022-10-19T12:43:31 -0700 > >> Adrian Klaver <adrian.klaver@aklaver.com> wrote: > >>> > >>> HINT: There is an entry for table "t", but it cannot be referenced from > >>> this part of the query. > >>> > >>> HINT: There is a column named "x" in table "t", but it cannot be > >>> referenced from this part of the query. > >> > >> Yes, I saw those, hence asking on the list if there was a way to do it. > > > > Using a trigger. > > To expand: > > create table t ( > x integer not null generated always as identity, > y integer not null > ); > insert into t(y) values (1); > > select * from t; > > x | y > ---+--- > 1 | 1 > (1 row) > > > > CREATE FUNCTION identity_test( ) > RETURNS trigger > LANGUAGE plpgsql > AS $function$ > BEGIN > NEW.y = NEW.x * 2; > RETURN NEW; > END; > > $function$ > ; > > create trigger identity_trg before insert on t for each row execute > function identity_test(); > > insert into t(y) values (0); > > select * from t; > > x | y > ---+--- > 1 | 1 > 2 | 4 > (2 rows) Make t.y a generated column and avoid the trigger: create table t ( x int not null generated always as identity, y int not null generated always as (x * 2) stored; ); insert into t (x) values (default), (default); select * from t; x | y ---+--- 1 | 2 2 | 4 (2 rows) But I think Mark wants to specify the expression in the INSERT and not define it as part of the database schema, if I understand it correctly. -- Erik
On Wed, Oct 19, 2022 at 12:34 PM Mark Raynsford <co+org.postgresql@io7m.com> wrote:
On 2022-10-19T11:58:07 -0700
"David G. Johnston" <david.g.johnston@gmail.com> wrote:
> On Wed, Oct 19, 2022 at 10:36 AM Mark Raynsford <co+org.postgresql@io7m.com>
> 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.