"Florian G. Pflug" <f...@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*?
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
