2015-02-26 19:53 GMT+01:00 Tom Lane <t...@sss.pgh.pa.us>: > Andres Freund <and...@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. > > regards, tom lane > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
