From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Conrad Vermeulen" <conrad(at)fastforward(dot)za(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: FW: indirect dereferencing a field in a record using plpgsql |
Date: | 2003-09-08 14:31:53 |
Message-ID: | 11716.1063031513@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Conrad Vermeulen" <conrad(at)fastforward(dot)za(dot)net> writes:
> Possibly my quick hack may not work if the parser
> predetermines the type as the functionality required would only really be
> able to determine the type at time of execution.
The problem is that the first time through, the execution plan for the
command or expression is generated and cached. So you can't change the
type of the field dereference later.
plpgsql is really not designed for this sort of thing; it's designed to
be fast with predictable data types. Use pltcl or plperl instead.
There's a reason why we support multiple PLs ;-)
I agree that it would be good to fix EXECUTE so that one could refer to
NEW or OLD in the constructed query (and other plpgsql variables too).
I believe this would take a rather serious overhaul of plpgsql's parser
though ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gaetano Mendola | 2003-09-08 15:09:36 | Re: mcxt.c |
Previous Message | Andreas Pflug | 2003-09-08 14:14:48 | plpgsql debugging |