Date: Thu, 26 Oct 2006 16:11:27 +0200
From: Zdenek Kotala <Zdenek.Kotala@Sun.COM>
Subject: Re: [HACKERS] COPY does not work with regproc and aclitem
In-reply-to: <20061026134406.GN9340@alvh.no-ip.org>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org,
	pgsql-patches@postgresql.org
Message-id: <4540C20F.8020900@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
References: <453D1B73.2050906@sun.com> <20061023200200.GD11409@alvh.no-ip.org>
	<27990.1161634170@sss.pgh.pa.us> <453E0A68.4070506@sun.com>
	<7995.1161697174@sss.pgh.pa.us> <4540B8B2.2070800@sun.com>
	<20061026134406.GN9340@alvh.no-ip.org>
User-Agent: Thunderbird 1.5.0.5 (X11/20060911)

Alvaro Herrera napsal(a):
> Zdenek Kotala wrote:
>> Tom Lane napsal(a):
>>> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>>>> I prepared patch which use oid output function instead regproc output. 
>>>> This change works only for COPY TO command.
>>> This is not a bug and we're not going to fix it, most especially not
>>> like that.
>> OK, The behavior of regproc type is described in the documentation, but 
>> if we don't fix it, than Some error message like "Regproc data type is 
>> not supported by COPY TO command" could be useful. Because you find that 
>> something is wrong when you want to restore data back and it should be 
>> too late.
> 
> But it works as "expected".  If the approach you suggest would be one we
> would take, then it should emit the same error on SELECT as well,
> shouldn't we?

It is right.

> I think the problem is that regproc COPY is not useful to you for your
> particular use case.  But there are workarounds, like the one I
> suggested and you promptly ignored.

Yes, I read your suggestion It is useful form me thanks for that. But I 
thought how to remove that regproc limitation or how to avoid some 
confusing. Current mention about regproc limitation/behavior in the 
documentation is really best solution.


By the way, If I read carefully your suggestion, Tom's answer and 
documentation, correct solution (theoretical) is replace regproc by 
regprocedure datatype in the catalog, but there is problem in the 
boostrap phase?

	Thanks Zdenek