Skip site navigation (1) Skip section navigation (2)

Re: Nested CASE-WHEN scoping

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Nested CASE-WHEN scoping
Date: 2011-05-31 16:10:36
Message-ID: 4DE512FC.9070707@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 30.05.2011 17:21, Tom Lane wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com>  writes:
>> I think we can work around both of those by just saving and restoring
>> the value of each Param that we set while evaluating an expression,
>
> Huh?  That's a waste of time and effort.  Just make sure that each such
> spot has its own Param number.  That's why I'm telling you to do it in
> the planner, not the parser --- it is easy to assign globally-unique-
> across-the-plan numbers at plan time, in fact we do it already.

Yeah, I got that part. What I'm saying is that it's not that easy, 
because of the two issues, domain constraints and index expressions, 
that I mentioned. Here's a WIP patch, but those two issues have not been 
addressed yet. I'm sure those are not insurmountable problems, I'm just 
trying to figure out the best way to surmount them:

For domain constraints, ExecInitExpr could assign globally-unique param 
numbers if it knew how many params are in use. That's trivial for 
expressions in plans, as you have access to the EState via the 
PlanState, and EState can include the number of params assigned. For a 
stand-alone expression, we don't have that. There is no global 
information whatsoever for stand-alone expressions, ExecInitExpr only 
sees the current node it's dealing with. Perhaps we need to add the 
concept of a global plan

For index expressions, we could use a function similar to 
ChangeVarNodes(), that shifts all the paramids in the already-planned 
expression, preparing it for inclusion within the enclosing plan. I'm a 
bit worried that that might screw up the logic used to compare if an 
expression matches the index expression, though; the param ids in the 
two expressions won't match.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

Attachment: replace-casetestexpr-with-param-1.patch
Description: text/x-diff (34.2 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2011-05-31 16:13:35
Subject: Re: [HACKERS] DOCS: SGML identifier may not exceed 44 characters
Previous:From: Joe AbbateDate: 2011-05-31 16:09:27
Subject: Re: Getting a bug tracker for the Postgres project

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group