From: | Marcelo Lacerda <marceloslacerda(at)gmail(dot)com> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Strange behavior with missing column in SQL function |
Date: | 2018-07-31 22:13:28 |
Message-ID: | CAPmRTtOL3mNGf-0MwwAWJjmc=WJo0Y7QDc0R2AOhSkPQ=i_KEg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> CREATE OR REPLACE FUNCTION myfunction(myrow mytable)
> RETURNS INTEGER AS $$
> SELECT myrow.c + myrow.b FROM myrow;
> $$ LANGUAGE sql;
> where "myrow" is a table with a different set of column names from
> "mytable". The existing behavior for that is to seek the column name
> in "myrow" (the table), failing that to seek it in the parameter,
> and only to throw an error if both fail.
Wow I never thought this would be possible. why didn't the designers of the
language use myrow mytable%ROWTYPE for rows of a table as a parameter,
given that it's a valid type in PL/PGSQL? I figure that way it would have
been way easier to disambiguate the definitions.
From | Date | Subject | |
---|---|---|---|
Next Message | Ertan Küçükoğlu | 2018-07-31 22:24:35 | How to prevent "no wait lock" after a connection drop |
Previous Message | Johnes Castro | 2018-07-31 21:19:17 | Re: pg_basebackup without copying the logs |