From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: plpgsql: check domain constraints |
Date: | 2006-01-09 04:56:52 |
Message-ID: | 25708.1136782612@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Neil Conway <neilc(at)samurai(dot)com> writes:
> (2) adjust pl/pgsql to fetch the constraints associated with the
> function's return value. Because this is expensive, the constraints are
> fetched once per session, when the function is compiled.
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.
> 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 ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2006-01-09 05:39:30 | Re: plperl vs LC_COLLATE (was Re: Possible savepoint bug) |
Previous Message | Neil Conway | 2006-01-09 04:30:40 | plpgsql: check domain constraints |
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2006-01-09 08:16:58 | Re: plpgsql: check domain constraints |
Previous Message | Neil Conway | 2006-01-09 04:30:40 | plpgsql: check domain constraints |