| 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: | Whole Thread | Raw Message | 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)
| 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 |