Re: Simple Column reordering

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Simple Column reordering
Дата
Msg-id 1172518109.3760.371.camel@silverbirch.site
обсуждение исходный текст
Ответ на Re: Simple Column reordering  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Simple Column reordering  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Simple Column reordering  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Deadlock with pg_dump?
Следующее
От: "Simon Riggs"
Дата:
Сообщение: Re: Deadlock with pg_dump?