Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group