Re: COPY TO looses on view - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: COPY TO looses on view
Date
Msg-id 200107120008.f6C080U07647@candle.pha.pa.us
Whole thread Raw
In response to Re: COPY TO looses on view  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
> Bruce Momjian <pgman@candle.pha.pa.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@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: COPY TO looses on view
Next
From: pgsql-bugs@postgresql.org
Date:
Subject: JDBC: The raise of an SQLException force the user to call either commit() or rollback() on the connection