Re: COPY into a view; help w. design & patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Karl O(dot) Pinc" <kop(at)meme(dot)com>
Cc: Robert Haas <Robert(dot)Haas(at)dyntek(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: COPY into a view; help w. design & patch
Date: 2007-05-19 17:41:47
Message-ID: 14377.1179596507@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Karl O. Pinc" <kop(at)meme(dot)com> writes:
> I don't really want to do this. I really want my users
> to be able to use the COPY statement without worrying
> about whether they are copying into a table or a view.

But ... but ... the proposed feature entirely fails to achieve that.
Copying into an explicit INSERT statement isn't necessarily a bad idea,
but surely it's not transparent in that way.

> I _could_ make tables that "correspond"
> to the views and put BEFORE INSERT triggers on them and
> have the triggers insert into the views (or the equalivent),
> but then the users would have to use the views for most
> things and the "corresponding tables" when doing a COPY
> or using the application's data import function.

There's been previous discussion of allowing BEFORE INSERT triggers
on views, so long as the triggers always return NULL to suppress
the actual insertion attempt (ie, we'd move the "can't insert into
view" test out of the rewriter and put it downstream of trigger firing
in the executor). So far no one's figured out how to make that idea
work for UPDATE/DELETE, but maybe you could argue that even if it
only worked for INSERT it'd be a useful feature. It'd certainly solve
the problem for COPY.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-05-19 17:48:22 Re: Signing off of patches (was Re: Not ready for 8.3)
Previous Message Shachar Shemesh 2007-05-19 17:05:43 Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server