Andres Freund <andres@2ndquadrant.com> writes: > On 2015-02-26 12:31:46 -0500, Tom Lane wrote: >> 2. In plpgsql, explicitly model a domain type as being its base type >> plus some constraints --- that is, stop depending on domain_in() to >> enforce the constraints, and do it ourselves. This would mean that >> the FmgrInfo in a PLpgSQL_type struct would reference the base type's >> input function rather than domain_in, so we'd not have to be afraid >> to cache that. The constraints would be represented as a separate list, >> which we'd arrange to fetch from the typcache once per transaction.
> 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 I'm not sure I see another use-case for this type of logic.
To some extent this is a workaround for the fact that plpgsql does type conversions the way it does (ie, by I/O rather than by using the parser's cast mechanisms). We've talked about changing that, but people seem to be afraid of the compatibility consequences, and I'm not planning to fight two compatibility battles concurrently ;-)
I understand, but in this case, a compatibility can be enforced simply - we can support "a only know cast" mode and "IO cast" mode.
IO cast is simple for lot of people, but there is a lot of performance issues and few errors related to this topic. But this is offtopic now.
But, what can be related - for plpgsql_check is necessary some simple check of a assigning - that should to return error or warning
This part of plpgsql_check is too complex now.
Regards
Pavel
> 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.
