On 2015-02-26 13:53:18 -0500, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > Hm. A bit sad to open code that in plpgsql instead of making it > > available more generally. > > The actual checking wouldn't be open-coded, it would come from > domain_check() (or possibly a modified version of that). It is true > that plpgsql would know more about domains than it does today, but
It'd still teach plpgsql more about types than it knows right now. But on a second thought that ship has sailed long ago - and the amount of knowledge seems relatively small. There's much more stuff about composites there already. > and I'm not planning to fight two compatibility battles concurrently ;-) Heh ;) > > You're probably going to kill me because of the increased complexity, > > but how about making typecache.c smarter, more in the vein of > > relcache.c, and store the relevant info in there? > > I thought that's what I was proposing in point #1. Sure, but my second point was to avoid duplicating that information into ->fcinfo and such and instead reference the typecache entry from there. So that if the typecache entry is being rebuilt (a new mechanism I'm afraid), whatever uses ->fcinfo gets the updated functions/definition. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
