Jim Nasby writes:
> On 10/19/15 7:12 PM, Tom Lane wrote:
>> IMO, we ought to get rid of the use of that representation for
>> composite-type variables and use the RECORD code paths for them,
> That also means there would only need to be changes to RECORD to allow
> CONSTANT, default, etc.
> Do
On 10/19/15 7:12 PM, Tom Lane wrote:
Jim Nasby writes:
What did seem odd is that while processing the DECLARE section there
were plpgsql datums for tt.a and tt.b. I would have expected the
assignment to produce a row datum of type tt.
Yeah, that's the thing that's weird about plpgsql's ROW da
Jim Nasby writes:
> What did seem odd is that while processing the DECLARE section there
> were plpgsql datums for tt.a and tt.b. I would have expected the
> assignment to produce a row datum of type tt.
Yeah, that's the thing that's weird about plpgsql's ROW datums.
What the row datum mechani
On 10/19/15 5:16 PM, Jim Nasby wrote:
Yeah, was hoping someone knew offhand why this was a problem. Guess I'll
rip the checks out and see what explodes.
... and what blows up is exec_eval_datum():
case PLPGSQL_DTYPE_ROW:
{
On 10/18/15 10:16 PM, Tom Lane wrote:
Jim Nasby writes:
Is there a particular reason why row and record variables can't be
CONSTANT in plpgsql?
Well, you can't usefully do anything with such a variable unless
it can be initialized, which isn't currently supported either:
regression=# do $$ d
Jim Nasby writes:
> Is there a particular reason why row and record variables can't be
> CONSTANT in plpgsql?
Well, you can't usefully do anything with such a variable unless
it can be initialized, which isn't currently supported either:
regression=# do $$ declare x int8_tbl := row(1,2); begin
Is there a particular reason why row and record variables can't be
CONSTANT in plpgsql?
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers maili
