Re: [HACKERS] Upgrades for 6.4.1

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.

In response to

Browse pgsql-hackers by date

  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?