Re: plpgsql: check domain constraints

Поиск
Список
Период
Сортировка
От Neil Conway
Тема Re: plpgsql: check domain constraints
Дата
Msg-id 1136794618.8851.10.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: plpgsql: check domain constraints  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: plpgsql: check domain constraints
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: plpgsql: check domain constraints
Следующее
От: Yoshiyuki Asaba
Дата:
Сообщение: CREATEUSER == SUPERUSER?