Re: COPY is not working - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: COPY is not working
Date
Msg-id 4BDF9AAD.8040004@Yahoo.com
Whole thread Raw
In response to Re: COPY is not working  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 5/3/2010 10:51 PM, Tom Lane wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
>> On 4/30/2010 1:56 AM, Jaime Casanova wrote:
>>> ah! this is because COPY doesn't follow inherited tables... should it?
> 
>> The TRUNCATE command's behavior was changed in that regard. What 
>> TRUNCATE did in 8.3 is now TRUNCATE ONLY in 8.4. I don't see a reason 
>> why COPY should not follow suit.
> 
> How about "because it's inappropriate for dump/reload, which is the main
> use-case for COPY"?  In any case it'd be weird for COPY FROM and COPY TO
> to behave differently on this point, but I don't really see how COPY
> FROM would do anything intelligent for inheritance.

Dump would have to switch to the more consistent syntax using the
   COPY ONLY <table> ...

form. As simple as that.

You are right that COPY ONLY ... FROM makes no sense at all. But I would 
consider that the corner case, not the defining general rule. One could 
make exactly the save inconsistency argument about the fact that there 
is a SELECT ... FROM ONLY, UPDATE ONLY and DELETE FROM ONLY, but no 
INSERT INTO ONLY.

As of right now, all commands that retrieve or affect existing rows, 
except for COPY, do honor the ONLY keyword to stop inheritance. And 
while pg_dump may be one of the main users of COPY, I think there are 
quite a few other. I don't really see why COPY is so special.


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin


pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: TOAST code ignores freespace (was Tweak TOAST code)
Next
From: Pavel Stehule
Date:
Subject: Re: what is good solution for support NULL inside string_to_array function?