Re: plpgsql versus domains
От | Tom Lane |
---|---|
Тема | Re: plpgsql versus domains |
Дата | |
Msg-id | 17048.1424978125@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: plpgsql versus domains (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-hackers |
Andres Freund <andres@2ndquadrant.com> writes: > On 2015-02-26 13:53:18 -0500, Tom Lane wrote: >> 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. The trick there would be that if we don't want to copy then we'd need a reference counting mechanism, and FmgrInfos aren't used in a way that would allow that to work easily. (Whatever the typcache is holding onto clearly must be long-lived, but you do want an obsoleted one to go away once there are no more FmgrInfos referencing it.) I was just thinking though that we could possibly solve that if we went ahead and invented the memory context reset callback mechanism that I suggested in another thread a week or two back. Then you could imagine that when a domain-checking function caches a reference to a "domain constraints info" object in its FmgrInfo, it could increment a refcount on the info object, and register a callback on the context containing the FmgrInfo to release that refcount. A different approach would be to try to use the ResourceOwner mechanism to track these info objects. But I think that does not work nicely for plpgsql; at least not unless it creates a ResourceOwner for every function, which seems kinda messy. regards, tom lane
В списке pgsql-hackers по дате отправления: