Re: [HACKERS] How do we find serial types

Поиск
Список
Период
Сортировка
От jwieck@debis.com (Jan Wieck)
Тема Re: [HACKERS] How do we find serial types
Дата
Msg-id m0zXqmY-000EBPC@orion.SAPserv.Hamburg.dsh.de
обсуждение исходный текст
Ответ на Re: [HACKERS] How do we find serial types  (darcy@druid.net (D'Arcy J.M. Cain))
Список 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@debis.com (Jan Wieck) #

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Thomas G. Lockhart"
Дата:
Сообщение: Re: [HACKERS] Re: [INTERFACES] Odbc parser error
Следующее
От: "Thomas G. Lockhart"
Дата:
Сообщение: Re: [HACKERS] datetime regression test fails at daylight savings transitions