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

Re: COPY TO looses on view

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Steve Pothier <pothiers(at)aries(dot)tucson(dot)saic(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: COPY TO looses on view
Date: 2001-07-12 00:08:00
Message-ID: 200107120008.f6C080U07647@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > OK, the following patch throws an error if you try to COPY TO/FROM
> > views.
> 
> This is probably the wrong direction to approach it from: rather than
> disallowing wrong things one at a time, we should only allow COPY if the
> relkind is plain relation.  Think about toast rels, indexes, ...

Yes, I thought about that.  I tried indexes and it failed because of the
heap_open call. I wonder if heap_open() is the place for more checks,
not even COPY:  Probably not.

In fact, there is no reason you shouldn't be able to COPY out a view,
except that it doesn't work.  :-)

Here are the reltypes.  I didn't want to start disabling them from COPY
until I was sure.  SEQUENCE is invalidated in COPY FROM, but not COPY
TO.  No idea why.  Anyway, I guess I was trying to avoid the research to
do it right.  I will add it to my list.

#define       RELKIND_INDEX           'i'       /* secondary index */
#define       RELKIND_RELATION        'r'       /* ordinary cataloged heap */
#define       RELKIND_SPECIAL         's'       /* special (non-heap) */
#define       RELKIND_SEQUENCE        'S'       /* SEQUENCE relation */
#define       RELKIND_UNCATALOGED     'u'       /* temporary heap */
#define       RELKIND_TOASTVALUE      't'       /* moved off huge values */
#define       RELKIND_VIEW            'v'       /* view */

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-bugs by date

Next:From: pgsql-bugsDate: 2001-07-12 14:55:47
Subject: JDBC: The raise of an SQLException force the user to call either commit() or rollback() on the connection
Previous:From: Tom LaneDate: 2001-07-11 23:29:10
Subject: Re: COPY TO looses on view

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