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

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 (view raw or flat)
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

pgsql-hackers by date

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

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