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

Re: COPY (query) TO file

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PFC <lists(at)peufeu(dot)com>, Tino Wildenhain <tino(at)wildenhain(dot)de>, Mark Woodward <pgsql(at)mohawksoft(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: COPY (query) TO file
Date: 2006-06-03 23:12:24
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers

Greg Stark wrote:

>It would have been awfully nice to do be able to do
>SELECT ... FROM (VALUES (a,b,c),(d,e,f),(g,h,i))
>>The trouble with supporting it for any case other than INSERT is that
>>you have to work out what the column datatypes of the construct ought
>>to be.  This is the same as the equivalent problem for UNION constructs,
>>but the UNION type resolution algorithm looks kinda ugly for thousands
>>of inputs :-(
>I always thought UNION just decided on the type based on the first branch and
>then coerced all the others to that type. I always cast all the columns on the
>first union branch just in case.

Could we get away with requiring an explicit type expression where 
there's some abiguity or uncertainty, like this

  SELECT ... FROM (VALUES (a,b,c),(d,e,f),(g,h,i)) as (a int, b text, c float) 

That's what you have to do with an SRF that returns a SETOF RECORD in the same situation, after all.



In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-06-04 00:09:09
Subject: Re: Possible TODO item: copy to/from pipe
Previous:From: Greg StarkDate: 2006-06-03 21:38:35
Subject: Re: More thoughts about planner's cost estimates

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