"Karl O. Pinc" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org