Re: Inspection of row types in pl/pgsql and pl/sql - Mailing list pgsql-hackers

From Florian G. Pflug
Subject Re: Inspection of row types in pl/pgsql and pl/sql
Date
Msg-id 4AFDB846.8040401@phlo.org
Whole thread Raw
In response to Re: Inspection of row types in pl/pgsql and pl/sql  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Inspection of row types in pl/pgsql and pl/sql
List pgsql-hackers
Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>> I'd like to replace this function-generating function by a generic 
>> trigger function that works for all tables. Due to the lack of any
>> way to inspect the *structure* of a record type, however, I'd have
>> to use a C language function for that, which induces quite some
>> maintenance headaches (especially if deployed on windows).
> 
> Trying to do this in plpgsql is doomed to failure and heartache,
> because it's fundamentally a strongly typed language.  The proposed
> functions won't fix that and hence will be unusable in practice.  I'd
> suggest either using C, or using one of the less-strongly-typed PLs.

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.

Since all the other PLs (except C) are not nearly as integrated with the postgres type system, using them for this task
doesnot really buy
 
anything IMHO. AFAIK, all these PLs will convert any SQL type which
isn't specifically mapped to one of the PLs types to a string. *That* I
can do with pl/pgsql too, by simply using record_out() and then parsing
the result...

C of course lets me work around all these problems - but at the cost of
a longer development time and (more importantly) more maintenance
headaches (especially on windows, where a C compiler is not just one
apt-get/yum/whatever call away).

Regarding usability - the proposed function would for example allow you
to implement a wide-range of row-to-text conversion functions in pure
pl/pgsql by calling record_value(record, name, anyelement) with
NULL::varchar as the last argument for each field, and then
concatinating the resulting text together any way you like.

best regards,
Florian Pflug


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: cvs head doesn't pass make check on one of the machines here
Next
From: Heikki Linnakangas
Date:
Subject: Re: Check constraint on domain over an array not executed for array literals