From: | Clark Evans <clark(dot)evans(at)manhattanproject(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>, PostgreSQL-development <hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Upgrades for 6.4.1 |
Date: | 1998-12-19 20:31:19 |
Message-ID: | 367C0D17.2C129291@manhattanproject.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-12-19 23:37:59 | Re: [HACKERS] Upgrades for 6.4.1 |
Previous Message | Terry Mackintosh | 1998-12-19 18:30:10 | Is this a bug? or am I doing some thing wrong? |