On 16.06.2011 23:56, Tom Lane wrote:
Heikki Linnakangas writes:
The complicated part is to ensure that levelsup is always set correctly.
At parse time, levelsup is always set to 0, as the syntax doesn't allow
referencing upper levels directly. When an SQL function is inlined, any
ExpressionPara
Heikki Linnakangas writes:
> The complicated part is to ensure that levelsup is always set correctly.
> At parse time, levelsup is always set to 0, as the syntax doesn't allow
> referencing upper levels directly. When an SQL function is inlined, any
> ExpressionParams in the expressions that ar
On 16.06.2011 22:46, Pavel Stehule wrote:
I have a query - should be ExpressionParam used for removing a
multiple function call when composite result is expanded?
With some similar optimization a SELECT (fce(x)).* FROM tab will be optimal
Hmm, I don't think it will work as is for that purpose,
Hello
2011/6/3 Heikki Linnakangas :
> On 31.05.2011 19:10, Heikki Linnakangas wrote:
>>
>> 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
>
On 30.05.2011 17:21, Tom Lane wrote:
Heikki Linnakangas 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 Pa
On 26.05.2011 00:31, Tom Lane wrote:
The main annoyance here is that standalone expressions may now need
Param slots to execute, which will complicate places that need to
evaluate them, but there's probably no way around that
Yeah, I can see two complications:
1. Domain constraints
Domain con
Heikki Linnakangas 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
I wrote:
> Heikki Linnakangas writes:
>> BTW, i just stumbled into this:
>> postgres=# explain verbose SELECT CASE now() WHEN (29+random()::int4)
>> THEN 'foo' ELSE 'bar' END;
>> ERROR: unexpected CASE WHEN clause: 326
>> Looks like ruleutils.c is also not prepared for the case that the
>> im
Heikki Linnakangas writes:
> On 25.05.2011 17:47, Tom Lane wrote:
>> [ scratches head ... ] Why does the save/restore in ExecEvalCase not
>> take care of this?
> The mistake happens during planning, when the SQL function is inlined
> and pre-evaluated.
OK, I see the problem now: we have a Case
On 25.05.2011 20:11, Tom Lane wrote:
Heikki Linnakangas writes:
On 25.05.2011 17:47, Tom Lane wrote:
[ scratches head ... ] Why does the save/restore in ExecEvalCase not
take care of this?
The mistake happens during planning, when the SQL function is inlined
and pre-evaluated.
Hm. I'm i
Heikki Linnakangas writes:
> On 25.05.2011 17:47, Tom Lane wrote:
>> [ scratches head ... ] Why does the save/restore in ExecEvalCase not
>> take care of this?
> The mistake happens during planning, when the SQL function is inlined
> and pre-evaluated.
Hm. I'm inclined to think this may be mo
On 25.05.2011 17:47, Tom Lane wrote:
Heikki Linnakangas writes:
While looking at fixing the multiple-evaluation issue in IN and BETWEEN
discussed a while ago, I realized that the current assumption that only
one CaseTestExpr placeholder needs to be valid at any given time is not
true.
[ scrat
Heikki Linnakangas writes:
> While looking at fixing the multiple-evaluation issue in IN and BETWEEN
> discussed a while ago, I realized that the current assumption that only
> one CaseTestExpr placeholder needs to be valid at any given time is not
> true.
[ scratches head ... ] Why does the
On 25.05.2011 14:57, Heikki Linnakangas wrote:
Here's a bit contrived example:
CREATE FUNCTION evileq (timestamptz, int4) returns boolean AS $$
SELECT case $2 WHEN length($1::text) THEN true ELSE false END;
$$ language sql;
CREATE OPERATOR = (procedure = evileq, leftarg = timestamptz, rightarg =
While looking at fixing the multiple-evaluation issue in IN and BETWEEN
discussed a while ago, I realized that the current assumption that only
one CaseTestExpr placeholder needs to be valid at any given time is not
true.
Here's a bit contrived example:
CREATE FUNCTION evileq (timestamptz, in
15 matches
Mail list logo
