Re: plpgsql versus domains

2015-02-26 19:53 GMT+01:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> 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 ;-)
>

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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>