Robert Haas writes:
> On Mon, Nov 2, 2009 at 11:31 AM, Tom Lane wrote:
>> Another interesting property
>> of this approach is that it'd fix the longstanding user complaint
>> that constructions like
>>if (TG_OP = 'INSERT' and NEW.foo = 'bar') ...
>> fail prematurely. The executor would
2009/11/2 Tom Lane :
> Pavel Stehule writes:
>> 2009/11/2 Tom Lane :
>>> This kinda calls into question whether the Oracle way is actually
>>> a good idea or not; but my purpose here is not to debate that,
>>> just to look at what it takes to implement it.
>
>> This is reason, why I would to see t
Pavel Stehule writes:
> 2009/11/2 Tom Lane :
>> This kinda calls into question whether the Oracle way is actually
>> a good idea or not; but my purpose here is not to debate that,
>> just to look at what it takes to implement it.
> This is reason, why I would to see third mode (incompatible with
2009/11/2 Tom Lane :
> One of the interesting properties of Oracle-compatible variable
> references in plpgsql is that the set of variables referenced by a
> given query could change during a forced replan. For example,
> consider
>
> declare x int;
> r record;
> ...
>
On Mon, Nov 2, 2009 at 11:31 AM, Tom Lane wrote:
> Another interesting property
> of this approach is that it'd fix the longstanding user complaint
> that constructions like
> if (TG_OP = 'INSERT' and NEW.foo = 'bar') ...
> fail prematurely. The executor would never demand the value
> of
2009/11/2 Tom Lane :
> One of the interesting properties of Oracle-compatible variable
> references in plpgsql is that the set of variables referenced by a
> given query could change during a forced replan. For example,
> consider
>
> declare x int;
> r record;
> ...
>
One of the interesting properties of Oracle-compatible variable
references in plpgsql is that the set of variables referenced by a
given query could change during a forced replan. For example,
consider
declare x int;
r record;
...
for r in select x,y from t
