Re: plpgsql: check domain constraints

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: plpgsql: check domain constraints
Date: 2006-01-09 08:16:58
Message-ID: 1136794618.8851.10.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2006-01-09 10:28:32 Re: Improving N-Distinct estimation by ANALYZE
Previous Message Stefan Kaltenbrunner 2006-01-09 07:55:06 Re: Fw: Is anyone interested in getting PostgreSQL working

Browse pgsql-patches by date

  From Date Subject
Next Message Hannu Krosing 2006-01-09 15:48:21 Re: Stats collector performance improvement
Previous Message Tom Lane 2006-01-09 04:56:52 Re: plpgsql: check domain constraints