Re: plpgsql versus domains
От | Andres Freund |
---|---|
Тема | Re: plpgsql versus domains |
Дата | |
Msg-id | 20150226190213.GH24199@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: plpgsql versus domains (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: plpgsql versus domains
Re: plpgsql versus domains |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: