Re: COPY is not working
От | Jan Wieck |
---|---|
Тема | Re: COPY is not working |
Дата | |
Msg-id | 4BDF9AAD.8040004@Yahoo.com обсуждение исходный текст |
Ответ на | Re: COPY is not working (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: