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

From: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Karl O(dot) Pinc" <kop(at)meme(dot)com>, 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-21 16:23:57
Message-ID: 20070521162357.GD62346@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, May 19, 2007 at 01:41:47PM -0400, Tom Lane wrote:
> > 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.

What about adding COPY support to rules? ISTM if you want to copy into a
view you probably want to insert into it as well, so why not use the
same mechanism? Presumably a COPY rule would also be faster than a
trigger.
--
Jim Nasby decibel(at)decibel(dot)org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2007-05-21 16:59:33 Re: UTF8MatchText
Previous Message Andrew Dunstan 2007-05-21 16:20:55 Re: pg_get_tabledef