Content-Type: text/plain;
  charset="iso-8859-1"
From: Robert Treat <xzilla@users.sourceforge.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>, Peter Eisentraut <peter_e@gmx.net>
Subject: Re: [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
Date: Wed, 28 Aug 2002 19:27:46 -0400
User-Agent: KMail/1.4.2
Cc: Rod Taylor <rbt@zort.ca>, Tom Lane <tgl@sss.pgh.pa.us>,
	Larry Rosenman <ler@lerctr.org>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
References: <200208282106.g7SL6wR03197@candle.pha.pa.us>
In-Reply-To: <200208282106.g7SL6wR03197@candle.pha.pa.us>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200208281927.46634.xzilla@users.sourceforge.net>

On Wednesday 28 August 2002 05:06 pm, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Bruce Momjian writes:
> > > That SELECT syntax is already too confusing.  I don't want to add an
> > > additional documentation specification that provides no value to user=
s.
> >
> > The value of the documentation, especially the reference manual, is that
> > it provides an authorative source of what works and what doesn't.  It is
> > not the place to hide transitional phases.  Moreover, the least possible
> > value you could provide to users is to gratuitously[*] change the syntax
> > and not tell anyone about it.
> >
> > In fact, the recent trend in the SQL commands has been to accept most
> > options in any order, so it would only be logical to accept the LIMIT a=
nd
> > FOR UDPATE options in any order and document that fact.  There is a
> > separate section in each reference page for information about which
> > format is compatible with what.
> >
> > But please remember that our foremost goal is to be compatible, both in
> > actuality and in mindset, with PostgreSQL, not with any other product
> > that happened to use a slightly different syntax at their whim.
> >
> > Therefore I request that both forms be accepted and documented as equal=
ly
> > valid.
>
> You made the same argument for the COPY syntax, that we publish both the
> old and new syntaxes, and I resisted because I felt most people would
> rather just see the best syntax.  I don't see the documentation as
> showing every possible syntax because that really doesn't benefit users,
> or should I say confused more than it helps.
>
> If you would like a vote, we can do that, but as I remember we had the
> same issue with COPY and we got most votes to just show the best syntax.

There are two cases where I see potential problems; first would be someone=
=20
trying to migrate from pre 7.3 who sees the "new" documentation and thinks=
=20
that part of his upgrade path is going to require rewriting X number of=20
queries/scripts/whatever... Second will be someone that comes in and needs =
to=20
work on some legacy code and what he looks at is directly in contrast to wh=
at=20
is in the documentation, but it appears to run fine. Both of these cases ar=
e=20
going to cause people confusion and when they post to the mailing list we'l=
l=20
be denied an opportunity to just blurt out in all caps RTFM!  :-)=20=20

I can assure you that both of these issues will be entered into the=20
interactive documents at some point, I'd just feel better if it we're in=20
there by default.=20

Robert Treat