X-Original-To: pgsql-docs-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 48CDA9FA621 for ; Fri, 15 Sep 2006 18:14:58 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 42400-04 for ; Fri, 15 Sep 2006 18:14:54 -0300 (ADT) 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 6B2549FA2C7 for ; Fri, 15 Sep 2006 18:14:54 -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 k8FLEpXY006016; Fri, 15 Sep 2006 17:14:51 -0400 (EDT) To: pgsql-docs@postgreSQL.org cc: Joe Conway Subject: Proposal for documenting 8.2 VALUES syntax Date: Fri, 15 Sep 2006 17:14:51 -0400 Message-ID: <6015.1158354891@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.105 tagged_above=0 required=5 tests=AWL, SPF_HELO_PASS, SPF_PASS X-Spam-Level: X-Archive-Number: 200609/12 X-Sequence-Number: 3699 I spent a bit of time thinking about the best way to document 8.2's more powerful VALUES clause. Here's the plan I came up with: * There needs to be some introductory material in Part II, and the only place it seems to fit at all is under Chapter 7, Queries. I think there should be a new page covering VALUES. We could add it at the end of the chapter (ie, a new section 7.7) or we could insert it between sections 7.3 Select Lists and 7.4 Combining Queries. The argument for the latter position is that VALUES is now syntactically parallel to SELECT, and so you can use it as if it were SELECT in UNION/INTERSECT/ EXCEPT structures as described in 7.4, as well as attach the ORDER BY, LIMIT, OFFSET clauses described in 7.5 and 7.6. However that might be putting too much emphasis on syntactic form as opposed to pedagogical clarity. I'm a bit inclined to put it at the end of the chapter and then explain "by the way, you can also attach that other stuff to it". Thoughts? * The SELECT reference page is huge already, so I would rather add only the minimum possible amount to it. This leads to the conclusion that we'd better create a new ref/ entry just for VALUES. I think that's appropriate anyway, since there is some material that doesn't seem like it would fit anywhere else --- in particular, that we want to warn off people from expecting umpteen-billion-row VALUES constructs to work well. * Joe's original draft docs patch added examples to the INSERT, UPDATE, DELETE, etc reference pages. While we obviously have got to update the INSERT page, I'm inclined to use the rest of that material in the new VALUES reference page. Comments? regards, tom lane