Re: Some more function-default issues

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

In response to

Responses

Browse pgsql-hackers by date

  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()