Обсуждение: PLs and domain constraints

I'd like to take a look at fixing the fact that procedural languages do
not check the constraints associated with domain types. I think there
are two separate issues:

(1) In PL/PgSQL, we need to check domain constraints whenever we assign
a new value to a variable of a domain type.

(2) When the return value of a PL function is of a domain type, the
domain's constraints should be checked before the return value is used.

AFAICS, #1 is merely a Small Matter of Programming: attached is a quick
and dirty patch that implements it (no docs or regression tests, and the
exec_cast_* APIs are somewhat uglified -- I'm planning to look at
whether that can be simplified).

For #2, I'm not sure where the right place to check domain constraints
is. I was thinking about adding the check to the fmgr function call
logic[1], but the domain checking code needs an ExprContext in which to
evaluate the constraint, which wouldn't easily be accessible.

Another alternative is to add the check to the implementation of each
PL. This wouldn't be _too_ bad (the number of PLs is relatively small),
but it would be easy for PL authors to forget about, and it would be
nice to do the check in a single place rather than N places.

Comments?

-Neil

[1] As a thunk that called into the PL's handler function, to avoid
overhead for the function call critical paths.

Neil Conway <neilc@samurai.com> writes:
> For #2, I'm not sure where the right place to check domain constraints 
> is. I was thinking about adding the check to the fmgr function call 
> logic[1], but the domain checking code needs an ExprContext in which to 
> evaluate the constraint, which wouldn't easily be accessible.

I'd go with making the PLs do it.  fmgr is a very low logical level and
it's inappropriate for it to even know what a domain is.  As an example
of the problems you will run into: how is fmgr going to find out whether
the target type is a domain, much less what its constraints are?  It
can't assume that it's running inside a transaction, or even that the
system catalog access machinery is alive yet.
        regards, tom lane

Tom Lane wrote:
> Neil Conway <neilc@samurai.com> writes:
>> For #2, I'm not sure where the right place to check domain constraints 
>> is. I was thinking about adding the check to the fmgr function call 
>> logic[1], but the domain checking code needs an ExprContext in which to 
>> evaluate the constraint, which wouldn't easily be accessible.
> 
> I'd go with making the PLs do it.  fmgr is a very low logical level and
> it's inappropriate for it to even know what a domain is.  As an example
> of the problems you will run into: how is fmgr going to find out whether
> the target type is a domain, much less what its constraints are?  It
> can't assume that it's running inside a transaction, or even that the
> system catalog access machinery is alive yet.
> 
Should I consider this as something to add to the PL/Java TODO list? Or is there more to be 
discussed?

Regards,
Thomas Hallgren

Thomas Hallgren <thomas@tada.se> writes:
>> Neil Conway <neilc@samurai.com> writes:
>>> For #2, I'm not sure where the right place to check domain constraints 
>>> is.

> Should I consider this as something to add to the PL/Java TODO list?

Yup, probably.
        regards, tom lane

On Mon, 2006-01-09 at 20:23 +0100, Thomas Hallgren wrote:
> Should I consider this as something to add to the PL/Java TODO list?

Probably, yes (if/when I fix the in-tree PLs I was planning to take a
look at all the externally-maintained ones, although you're welcome to
do it instead).

Before domain constraints can be efficiently checked in PLs, the backend
needs some additional infrastructure (see recent discussion of typcache
changes on pgsql-patches, subject: "plpgsql: check domain constraints").
When that's finished, checking constraints in a PL should be fairly
easy.

-Neil