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
