Re: [HACKERS] Re: [PATCHES] pg_dump primary keys - Mailing list pgsql-hackers

From wieck@debis.com (Jan Wieck)
Subject Re: [HACKERS] Re: [PATCHES] pg_dump primary keys
Date
Msg-id m11wmZP-0003kGC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
In response to Re: [PATCHES] pg_dump primary keys  (Peter Eisentraut <e99re41@DoCS.UU.SE>)
Responses Re: [HACKERS] Re: [PATCHES] pg_dump primary keys
List 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 by date:

Previous
From: wieck@debis.com (Jan Wieck)
Date:
Subject: Re: [HACKERS] LONG
Next
From: wieck@debis.com (Jan Wieck)
Date:
Subject: Re: [HACKERS] 6.6 release