Re: Simple Column reordering - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Simple Column reordering
Date
Msg-id 1172518109.3760.371.camel@silverbirch.site
Whole thread Raw
In response to Re: Simple Column reordering  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Simple Column reordering  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Simple Column reordering  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Mon, 2007-02-26 at 13:02 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Mon, 2007-02-26 at 11:20 -0500, Bruce Momjian wrote:
> > 
> > > I realized this proposal has been withdrawn, but the fact the proposal
> > > even illicited comments exploring it requires me to comment.
> > > 
> > > Folks, how can we entertain ideas that would break SELECT * and
> > > no-column-list INSERTs for a small performance boost?  If there was no
> > > other way to get the performance boost, and the features was rarely
> > > used, we might consider such a change, but neither is true in this case.
> > > 
> > > My point is that this proposal is so far away from our acceptable
> > > criteria that I am worried about how people are analyzing proposals.
> > 
> > When suggested, it wasn't clear to me that it did break anything,
> > otherwise I wouldn't have written it up. I read Alvaro's post and
> 
> You mentioned in your own original posting that it broke SELECT * and
> COPY.

I saw that there was an effect, not breakage; I didn't use that word. I
specifically highlighted that there would be a difference because it was
an area of possible contention.

The order of the columns is *arbitrary* in relational theory; the
ordering needs to match to allow DDL to match other SQL that presumes an
ordering. Changing the order at CREATE TABLE time seemed acceptable and
would be so in many cases, since most applications follow sensible
guidelines about not using SELECT * etc. But SQL Standard breakage is
not acceptable. My mistake was mis-reading the Standard, which
regrettably is not the easiest manual to read, but no excuse. 

The functionality could still be usefully implemented in a client tool,
which was where the discussion left.

> > wondered why that proposal had been overlooked, so I started a separate
> > thread to ensure that the idea was discussed. That seems very similar to
> > many of your own posts.
> 
> True, but usually I don't see the breakage.

Sorry, I just meant you summarise ideas that others have made, not that
your proposals are broken.

>   What concerned me is you
> saw some of the breakage, but still went ahead with the proposal.

I have never and will never propose something I know to be broken. That
shouldn't need to be said, but I've had to say that more than once
recently for some reason. Why would you even think that the author of
PITR would harbour some hidden disrespect for server integrity, or
somebody who overhauled the standards compliance documentation, with
Troels, has no respect for standards?

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Deadlock with pg_dump?
Next
From: "Simon Riggs"
Date:
Subject: Re: Deadlock with pg_dump?