Re: [HACKERS] Re: [PATCHES] pg_dump primary keys

Поиск
Список
Период
Сортировка
От wieck@debis.com (Jan Wieck)
Тема Re: [HACKERS] Re: [PATCHES] pg_dump primary keys
Дата
Msg-id m11wmZP-0003kGC@orion.SAPserv.Hamburg.dsh.de
обсуждение исходный текст
Ответ на Re: [PATCHES] pg_dump primary keys  (Peter Eisentraut <e99re41@DoCS.UU.SE>)
Ответы Re: [HACKERS] Re: [PATCHES] pg_dump primary keys  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Peter Eisentraut wrote:

> What though if a function accesses a table? Which one goes first? Do we
> have to maintain a network of dependencies in pg_dump? Eventually we'll
> probably have to, with all the foreign key stuff coming up. Gloomy
> prospects.

    No  need  to  worry  about  FOREIGN  KEY  stuff  here.  These
    functions are generic builtins not dumped at all.

    But need to worry about all other functions of all languages.
    They  can be used in a table schema and OTOH their definition
    might need a relation to exist  (could  have  tuple  type  as
    argument).   Plus,  for SQL language functions (only SQL, not
    PL/pgSQL or any other language)  their  body  is  checked  at
    CREATE time for syntax, so relations they use are required.

    This can only be solved by your mentioned dependency network.

    BTW: All this was one reason to dump views  as  CREATE  TABLE
    and   later   CREATE   RULE.  Because  views  likely  contain
    functions.


Jan

--

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

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

Предыдущее
От: wieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [HACKERS] LONG
Следующее
От: wieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [HACKERS] 6.6 release