Re: Simple Column reordering

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Simple Column reordering
Date: 2007-02-26 19:28:29
Message-ID: 1172518109.3760.371.camel@silverbirch.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2007-02-26 19:31:49 Re: [HACKERS] Deadlock with pg_dump?
Previous Message Tom Lane 2007-02-26 19:28:26 Re: [HACKERS] Deadlock with pg_dump?