Re: Inspection of row types in pl/pgsql and pl/sql

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Postgresql-Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Inspection of row types in pl/pgsql and pl/sql
Date: 2009-11-13 19:49:26
Message-ID: 4AFDB846.8040401@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> "Florian G. Pflug" <fgp(at)phlo(dot)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 does not 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-11-13 19:50:11 Re: Check constraint on domain over an array not executed for array literals
Previous Message Tom Lane 2009-11-13 19:39:20 Re: cvs head doesn't pass make check on one of the machines here