Re: plpgsql: check domain constraints - Mailing list pgsql-patches

From Neil Conway
Subject Re: plpgsql: check domain constraints
Date
Msg-id 1136794618.8851.10.camel@localhost.localdomain
Whole thread Raw
In response to Re: plpgsql: check domain constraints  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: plpgsql: check domain constraints  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
On Sun, 2006-01-08 at 23:56 -0500, Tom Lane wrote:
> We have gone out of our way to make sure that domain constraint checking
> responds promptly (ie, within one query) to updates of the domain
> definition.  Caching at the session level in plpgsql would be a
> significant regression from that, and I don't think it's acceptable.
> If you had a way of invalidating the cache when needed, it'd be great
> ... but not without that.

GetDomainConstraints() looks fairly expensive, so it would be nice to do
some caching. What would the best way to implement this be? I had
thought that perhaps the typcache would work, but there seems to be no
method to flush stale typcache data. Perhaps we could add support for
typcache invalidation (via a new sinval message), and then add the
domain constraint information to the typcache. Or is there an easier
way?

> > I also made a few semi-related cleanups. In pl_exec.c, it seems to me
> > that estate.eval_econtext MUST be non-NULL during the guts of both
> > plpgsql_exec_trigger() and plpgsql_exec_function(). Therefore checking
> > that estate.eval_econtext is non-NULL when cleaning up is unnecessary
> > (line 649 and 417 in current sources, respectively), so I've removed the
> > checks. Am I missing something?
>
> The code doesn't currently assume that, and it doesn't seem to me that
> saving one simple if-test is a reason to add the assumption ...

It's not a matter of "saving an if-test", it's a matter of code clarity.
Code ought to be consistent about whether any given pointer variable
might be NULL. This makes it easier for a programmer to tell if new code
ought to check for NULL-ness before using the pointer. (In fact, when
modifying plpgsql_exec_function() for this patch, I had to spend a few
minutes checking for the situations in which estate.eval_econtext might
be NULL.)

Some languages (e.g. ML) actually distinguish in the type system between
"references that might be NULL" and those that cannot be. That's not
possible in C, but consistently treating NULL-ness makes it easier to
determine this by hand.

-Neil



pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: plpgsql: check domain constraints
Next
From: Yoshiyuki Asaba
Date:
Subject: CREATEUSER == SUPERUSER?