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) #
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 |