Skip site navigation (1) Skip section navigation (2)

Re: [PATCH] add CLUSTER table USING index (take 2)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Holger Schurig <holgerschurig(at)gmx(dot)de>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: [PATCH] add CLUSTER table USING index (take 2)
Date: 2007-03-29 23:30:05
Message-ID: 5600.1175211005@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Holger Schurig <holgerschurig(at)gmx(dot)de> writes:
> I agree that the example should be re-written. But I'm not sure if I need
> to have a paragraph about the old syntax. There are two reasons:
> - I haven't seen any other SQL command where an old syntax was
>   documented

If we were deprecating the old syntax with intention to remove it, that
might be a defensible position, but I didn't think we were doing that.

IMHO both forms seriously do need to be documented so that people will
understand that the index/table order is different.  Otherwise there'll
be enormous confusion.

> - I thought I could come away without writing doc. After all, I'm
>   not a native english speaker. That's a point where I could need
>   some help ...  (maybe my english is good enought, but it's not
>   worth to make a "take 4" to "take 17" patch just for english
>   grammar, typos, subtle meanings, whatever.

Your English seems fine to me, certainly more than good enough to
produce first-draft documentation.  Whoever reviews/commits it will
help out as needed.

>> Is the placement of opt_cluster_using completely arbitrary? I'm not very 
>> familiar with the parser, it really looks like those type-definitions 
>> are in random order.

> I thought so.

Yeah, it's just a mess :=(.  Somebody might go through and sort them
into alphabetical order or something someday, but not today.

			regards, tom lane

In response to

pgsql-patches by date

Next:From: Bruce MomjianDate: 2007-03-29 23:45:38
Subject: Re: Current enums patch
Previous:From: Bruce MomjianDate: 2007-03-29 22:50:30
Subject: Re: Patch for circular buffer in tuplestore to optimize merge joins (v1)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group