Re: [HACKERS] Upgrades for 6.4.1 - Mailing list pgsql-hackers

From Clark Evans
Subject Re: [HACKERS] Upgrades for 6.4.1
Date
Msg-id 367C0D17.2C129291@manhattanproject.com
Whole thread Raw
In response to Re: [HACKERS] Upgrades for 6.4.1  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hope you don't mind my feedback on this one.  If so, 
I'll stick to the general list.

> play=> SELECT DISTINCT i FROM dtest ORDER BY j;

> I don't know whether the SQL standard defines how this combination of
> features ought to work ... but our current behavior seems fairly
> surprising...

It suprised me.  Perhaps the query should be re-written using 
a from "select clause" (which is an instant view) on it's way 
down the pipe, like:

SELECT DISTINCT i FROM (SELECT i FROM dest ORDER BY j);


> More to the point, what possible use would a column constrained to NULL
> be?  Might as well just not have it in the table...

Backward compatibility with a client appliation (which has the 
column hard coded in a select statement), only you want to make 
sure that it isn't used...  I've actually done this in real life.  
The client was deployed to thousands of users, and was being phased
out, yet we had to support some reporting it did.  
*shudder*  Don't remind me.


pgsql-hackers by date:

Previous
From: "Stupor Genius"
Date:
Subject: RE: [HACKERS] Upgrades for 6.4.1
Next
From: Clark Evans
Date:
Subject: SELECT DISTINCT i FROM dtest ORDER BY j