"Florian G. Pflug" <f...@phlo.org> writes:
> Tom Lane wrote:
>> Trying to do this in plpgsql is doomed to failure and heartache,
> Well, the proposed functions at least allow for some more flexibility in
> working with row types, given that you know in advance which types you
> will be dealing with (but not necessarily the precise ordering and
> number of the record's fields). They might feel a bit kludgy because of
> the "anyelement" dummy argument that bridges the gap between the
> statically typed nature of SQL and the rather dynamic RECORDs, but the
> kludgy-ness factor is still within reasonable limits I think.
It sounds pretty d*mn klugy to me, and I stand by my comment that it
isn't going to work anyway. When you try it you are going to run into
"parameter type doesn't match that while preparing the plan" errors.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
