Re: plpgsql versus domains

Andres Freund <andres(at)2ndquadrant(dot)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 ;-)

> 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