Tom Lane wrote:
Andrew Dunstan <and...@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
smime.p7s
Description: S/MIME Cryptographic Signature
