From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Kevin Grittner <kgrittn(at)mail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Assigning NULL to a record variable |
Date: | 2012-09-20 21:39:15 |
Message-ID: | CAFj8pRDuecDJNkRgyMmrtN0yFhqSg1OqnK1QwdDbEFN2fY1aVQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2012/9/20 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> "Kevin Grittner" <kgrittn(at)mail(dot)com> writes:
>> ... This did not work for cases where the AFTER DELETE trigger performed
>> an action which was not idempotent because, while return_value was
>> NULL enough to enter that last IF clause, it was not NULL enough to
>> prevent the DELETE attempt and fire subsequent triggers. The
>> assignment of NULL to a variable with a record type doesn't assign a
>> "simple" NULL, but a record with NULL in each element.
>
> I believe that this is forced by plpgsql's implementation. IIRC, a
> declared variable of a named composite type (not RECORD) is implemented
> as a "row" structure, meaning it actually consists of a separate plpgsql
> variable for each column. So there's no physical way for it to represent
> a "simple NULL" composite value.
>
> I've suggested in the past that we might want to go over to treating
> such variables more like RECORD, ie the representation is always a
> HeapTuple.
I had same idea when I worked on SQL/PSM - but there is significant
difference in performance (probably less in real tasks)
I'm not sure what the performance tradeoffs would be ---
> some things would get faster and others slower, probably, since field
> access would be more work but conversion to/from HeapTuple would get far
> cheaper.
when fields are fix length, then field's update is significantly
faster then when RECORD is used
>
>> - If we keep this behavior, should the triggering operation be
>> suppressed when (NOT return_value IS NOT NULL) instead of when
>> (return_value IS NOT DISTINCT FROM NULL)?
>
> Can't do that, because it would break the perfectly-legitimate case
> where the trigger is trying to process a row of all nulls.
>
> regards, tom lane
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-09-20 21:55:05 | Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries. |
Previous Message | Tom Lane | 2012-09-20 21:31:08 | Re: Assigning NULL to a record variable |