Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Yes, and I have used it, but it really would be nicer to have some
>> introspection facilities built in, especially for use in triggers.
>
> Maybe, but the proposal at hand is spectacularly ugly --- in particular
> it seems designed around the assumption that a given trigger will only
> care about handling a predetermined set of datatypes, which hardly
> fits with PG's normal goals for datatype extensibility. If the argument
> is that you don't like hstore or other PLs because they'll smash
> everything to text, then I think you have to do better than this.
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. Plus, the set of datatypes an application deals with is
usually much smaller than the set of tables, and less likely to change
over time.
I'd also argue that this restriction does not conflict with PG's goal of
datatype extensibility at all. Datatype extensibility in PG's boils down
to being able to create new datatypes without modifying postgres itself
- but it still expects that you do so while designing your application.
Which also is when trigger functions that use record_value() or a
similar function would be written.
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.
best regards,
Florian Pflug
