On 2015-02-26 13:53:18 -0500, Tom Lane wrote:
> Andres Freund <andres@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
