Re: [HACKERS] How do we find serial types

From: jwieck(at)debis(dot)com (Jan Wieck)
To: darcy(at)druid(dot)net (D'Arcy J(dot)M(dot) Cain)
Cc: lockhart(at)alumni(dot)caltech(dot)edu, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] How do we find serial types
Date: 1998-10-26 17:50:18
Message-ID: m0zXqmY-000EBPC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

D'Arcy J.M. Cain wrote:

> Actually, there is another way to do this. If the system were to always
> generate a sequential number on insert and ignore any value specified, that
> would work to. Unfortunately that wouldn't work on a dump and restore.

The way I described it, using a kind of pre-rewriting, would
work for dump/restore. Data moved in by COPY doesn't invoke
any rule since there is no query to rewrite (except you dump
it as INSERT statements). COPY is a utility statement and
they aren't rewritten at all. On the other hand we could
change pg_dump to omit SERIAL and CONSTRAINT information at
CREATE TABLE and later turn all this on like triggers/rules
(using ALTER TABLE?) when the data is put back by
COPY/INSERT.

I think for 6.5 it would also be good to restrict the use of
COPY to tables the user has RULE permissions for. I think
such a check doesn't exist already and if I'm right, COPY is
a way to get around rules ON INSERT.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 1998-10-26 18:44:02 Re: [HACKERS] Last call?
Previous Message Thomas G. Lockhart 1998-10-26 17:42:35 Re: [HACKERS] datetime regression test fails at daylight savings transitions