X-Original-To: pgsql-hackers-postgresql.org@postgresql.org
Received: from localhost (mx1.hub.org [200.46.208.251])
	by postgresql.org (Postfix) with ESMTP id B9A8B9FB2F8
	for <pgsql-hackers-postgresql.org@postgresql.org>;
	Sat, 29 Jul 2006 22:45:54 -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 18623-04 for
	<pgsql-hackers-postgresql.org@postgresql.org>;
	Sat, 29 Jul 2006 22:45:49 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from joeconway.com (joeconway.com [68.15.9.201])
	by postgresql.org (Postfix) with ESMTP id 749649FB2F3
	for <pgsql-hackers@postgresql.org>;
	Sat, 29 Jul 2006 22:45:45 -0300 (ADT)
Received: from [192.168.4.40] (account jconway [192.168.4.40] verified)
	by joeconway.com (CommuniGate Pro SMTP 4.1.8)
	with ESMTP-TLS id 4120906; Sat, 29 Jul 2006 18:45:44 -0700
Message-ID: <44CC0F48.9020805@joeconway.com>
Date: Sat, 29 Jul 2006 18:45:44 -0700
From: Joe Conway <mail@joeconway.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Christopher Kings-Lynne <chris.kings-lynne@calorieking.com>,
	"Hackers (PostgreSQL)" <pgsql-hackers@postgresql.org>,
	Andrew Dunstan <andrew@dunslane.net>, Bernd Helmle <mailings@oopsware.de>,
	Peter Eisentraut <peter_e@gmx.net>,
	Susanne Ebrecht <susanne.ebrecht@credativ.de>
Subject: Re: Values list-of-targetlists patch for comments (was Re: [PATCHES]
References: <44B69778.5050104@dunslane.net>
	<50461.84.63.113.55.1152832991.squirrel@pezone.net>
	<ECCAAC0A3182895D3D12B0E8@[172.26.14.247]>
	<44B7ADFC.90205@dunslane.net> <44BC0432.3040509@joeconway.com>
	<44BC661F.80609@joeconway.com> <44BCD06C.3060409@calorieking.com>
	<44BCF1D4.3010807@dunslane.net> <5842.1153246741@sss.pgh.pa.us>
	<44BD8854.9060506@calorieking.com> <15212.1153279954@sss.pgh.pa.us>
	<44BDB2F5.7080003@joeconway.com> <44BEA710.6060700@joeconway.com>
	<23198.1153367887@sss.pgh.pa.us> <44BF0382.2010501@joeconway.com>
	<23454.1153370214@sss.pgh.pa.us> <44BF122F.1080200@joeconway.com>
	<23927.1153373971@sss.pgh.pa.us> <44C00E1E.1000405@joeconway.com>
	<14047.1153442773@sss.pgh.pa.us> <44C4451A.4010906@joeconway.com>
	<11495.1153757531@sss.pgh.pa.us> <44C4F625.2050304@joeconway.com>
	<12029.1153760969@sss.pgh.pa.us> <44CC0A66.6070903@joeconway.com>
	<21398.1154223324@sss.pgh.pa.us>
In-Reply-To: <21398.1154223324@sss.pgh.pa.us>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.038 tagged_above=0 required=5 tests=AWL,
	SPF_HELO_PASS, SPF_PASS
X-Spam-Level: 
X-Archive-Number: 200607/1535
X-Sequence-Number: 87390

Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
>>One of the things I'm struggling with is lack of column aliases. Would 
>>it be reasonable to require something like this?

> Requiring column aliases is counter to spec ...

>>	SELECT ... FROM (VALUES ...) AS foo(col1 type1, col2 type2, ...)

> ... and this is even further away from it.

I figured as much, but thought I'd ask anyway :-). I did find something 
in the appendix to the spec after sending this:

Annex C
(informative)
Implementation-dependent elements

18) Subclause 7.3, “<table value constructor>”:
a) The column names of a <table value constructor> or a <contextually 
typed table value constructor>
are implementation-dependent.

> As for the names, just use "?column?", same as we do now in INSERT
> ... VALUES.  Anyone who wants to refer to those columns explicitly will
> need to assign aliases, but if they don't assign aliases, we don't have
> to do anything very intelligent.

OK, I just thought "?column?" was ugly and useless.

> As for the types, I believe that the spec pretty much dictates that we
> apply the same type resolution algorithm as for a UNION.  This is fairly
> expensive and we should avoid it in the case of INSERT ... VALUES, but
> for VALUES appearing anywhere else I think we have little choice.

Where do I find that algorithm -- somewhere in nodeAppend.c?

Thanks,

Joe