Re: PG 7.2b4 bug? - Mailing list pgsql-hackers

From Don Baccus
Subject Re: PG 7.2b4 bug?
Date
Msg-id 3C1E60B8.3040909@pacifier.com
Whole thread Raw
In response to PG 7.2b4 bug?  (Don Baccus <dhogaza@pacifier.com>)
Responses Re: PG 7.2b4 bug?
List pgsql-hackers
Tom Lane wrote:

> Don Baccus <dhogaza@pacifier.com> writes:
> 
>>Apparently there's been a change in the way views are handled within 
>>PostreSQL.  The following program works fine in earlier versions.
>>
> 
> AFAICT, it was just pure, unadulterated luck that it "works" in prior
> versions.
> 
> In 7.1 I get:
> 
> regression=# select test_seq.nextval from multiple_rows;
> NOTICE:  Adding missing FROM-clause entry for table "test_seq"
>  nextval
> ---------
>        3
>        4
> (2 rows)


Normally one expects a statement's sematics to depend only upon the 
source code and to be consistent, not to vary depending on the mood du 
jour of the processor ... this also fails (it's the same statement with 
manual substitution):

test=# select (select nextval('test_seq_x') as nextval) as test_seq from 
multiple_rows; test_seq
----------        2        2
(2 rows)

test=#

In other words the function's only called once (as I expected).

I've looked at Date and Darwin's appendix on SQL3's PSMs but it's no 
help that I can see, it doesn't get into nitpicking semantic details 
regarding their use in queries, just their definition.

Maybe the behavior's implementation defined ... if not, I'd presume SQL3  states that a function in the above context
iscalled either once per 
 
row or once per query, not sometimes one or sometimes the other.

So I think it's too early to write this off as not being a bug ...


-- 
Don Baccus
Portland, OR
http://donb.photo.net, http://birdnotes.net, http://openacs.org



pgsql-hackers by date:

Previous
From: Lamar Owen
Date:
Subject: Re: Explicit config patch 7.2B4
Next
From: Stephan Szabo
Date:
Subject: Re: PG 7.2b4 bug?