X-Original-To: pgsql-docs-postgresql.org@postgresql.org
Received: from localhost (wm.hub.org [200.46.204.128])
	by postgresql.org (Postfix) with ESMTP id 1A41E9FB2F6
	for <pgsql-docs-postgresql.org@postgresql.org>;
	Thu,  3 Aug 2006 23:36:40 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024)
	with ESMTP id 43431-09 for <pgsql-docs-postgresql.org@postgresql.org>;
	Fri,  4 Aug 2006 02:36:32 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id 148309FA2D3
	for <pgsql-docs@postgresql.org>; Thu,  3 Aug 2006 23:36:31 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k742aNL7000861;
	Thu, 3 Aug 2006 22:36:23 -0400 (EDT)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Gavin Sherry <swm@linuxworld.com.au>, pgsql-docs@postgresql.org,
	Joe Conway <mail@joeconway.com>
Subject: Re: Values list-of-targetlists patch for comments (was Re: [PATCHES] 
In-reply-to: <200608040321.48560.peter_e@gmx.net> 
References: <44B69778.5050104@dunslane.net>
	<200608031911.48010.peter_e@gmx.net>
	<Pine.LNX.4.58.0608041042551.16622@linuxworld.com.au>
	<200608040321.48560.peter_e@gmx.net>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
	message dated "Fri, 04 Aug 2006 03:21:47 +0200"
Date: Thu, 03 Aug 2006 22:36:23 -0400
Message-ID: <860.1154658983@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200608/9
X-Sequence-Number: 3627

Peter Eisentraut <peter_e@gmx.net> writes:
> Gavin Sherry wrote:
>> What do we want to do about documenting:
>> regression=# values(1);

> Out of curiosity, according to what theory should that be allowed?

Wrong question.  SELECT (for the general case of multi-row results)
and VALUES are exactly parallel in the SQL grammar; the right question
is "according to what theory are you allowed to issue a general SELECT?"

AFAICT the SQL spec only envisions "SELECT ... INTO some-variables",
restricted to a single-row result (cf <select statement: single row>
production) as being something a client can issue directly.  Every more-
complex case is apparently supposed to be handled by one-row-at-a-time
fetches from a cursor.

If you can persuade the community that they don't want SELECT in its
current form, you might be able to persuade me that VALUES shouldn't
be allowed either.

			regards, tom lane