From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Some more function-default issues |
Date: | 2009-01-06 14:24:55 |
Message-ID: | 496369B7.5010608@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> The minimum-code-change solution would be to run around and try to make
> sure every such expression gets passed through eval_const_expressions()
> before we try to execute it. This is probably doable (looking for calls
> to fix_opfuncids would be a good guide) but it seems like the potential
> for errors of omission is large, particularly in third-party add-ons.
That seems ok to me. Calling eval_const_expressions() in ALTER COLUMN
and elsewhere is a good idea for performance reasons as well.
I can only find one more call to fix_opfuncids, where we're not already
calling eval_const_expressions(): GetDomainConstraints(). Adding a
eval_const_expressions() call to ExecPrepareExpr() would take care of
the ALTER COLUMN and many other cases where we have a problem now.
I can't imagine a third-party add-on so tightly integrated with the
backend that it needs to mess with Expr nodes, and call fix_opfuncids().
ExecPrepareExpr, maybe, but if we fix that as I presume we would, the
add-ons wouldn't be affected.
Overall, I don't see much potential for bugs-of-omission. You could put
a comment at the top of fix_opfuncids() as a reminder that outside the
executor you need to call eval_const_expressions() too.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2009-01-06 14:31:09 | Re: Status of issue 4593 |
Previous Message | Simon Riggs | 2009-01-06 14:18:35 | Re: lazy_truncate_heap() |