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

Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>   
>> While I agree that handling arbitrary datatypes at runtime would be 
>> nice, I really don't see how that could ever be done from within a 
>> plpgsql procedure, unless plpgsql somehow morphs into a dynamically 
>> typed language.
>>     
>
> Which is not likely to happen, which is why this is fundamentally a
> dead end.  I don't think it's appropriate to put ugly, hard to use
> band-aids over the fact that plpgsql isn't designed to do this.
> One of the principal reasons why we work so hard to support multiple
> PLs is that they have different strengths.  If you need something that's
> more dynamically typed than plpgsql, you should go use something else.
>
>   
>> Plus, fully generic handling of data of arbitrary type is a somewhat 
>> strange notion anyway, because it leaves you with very few operations 
>> guaranteed to be defined for those values. In the case of PG, you'd be 
>> pretty much limited to casting those values from and to text.
>>     
>
> Well, that's the wrong way to look at it.  To me, the right design
> would involve saying that my trigger needs to do operation X on the
> data, and therefore it should support all datatypes that can do X.
> It should not need a hard-wired list of which types those are.
>
> Perhaps it would help if we looked at some specific use-cases that
> people need, rather than debating abstractly.  What do you need your
> generic trigger to *do*?
>
>             
>   

The two things I have wanted most badly in the past are

a) to be able to address a field in NEW and OLD by a string name 
(usually passed in via a trigger argument) and
b) to be able to discover the names if the fields in NEW and OLD

cheers

andrew