FAQ
As part of my testing, I noticed this bug. My database has a
search_path set in the database vars. It dumps lik ethis:

DROP DATABASE usa;
CREATE DATABASE usa WITH TEMPLATE = template0 OWNER = usadmin ENCODING =
'LATIN1';
ALTER DATABASE usa SET search_path TO 'public, contrib';

Notice the single quotes around the TO bit? That's completely broken.
Those '' must not be there.

Is a fix for this required for only search_path, or is it a more general
problem?

Chris

Search Discussions

  • Tom Lane at Jun 29, 2004 at 6:11 am

    Christopher Kings-Lynne writes:
    Is a fix for this required for only search_path, or is it a more general
    problem?
    I think this has to be driven off the GUC_LIST_INPUT and/or
    GUC_LIST_QUOTE flag bits (too late at night to remember just what those
    two flags do, but one or both determines this). One small problem is
    that pg_dump can't see the GUC flag bits AFAIK ...

    regards, tom lane
  • Christopher Kings-Lynne at Jul 13, 2004 at 7:23 am

    As part of my testing, I noticed this bug. My database has a
    search_path set in the database vars. It dumps lik ethis:

    DROP DATABASE usa;
    CREATE DATABASE usa WITH TEMPLATE = template0 OWNER = usadmin ENCODING =
    'LATIN1';
    ALTER DATABASE usa SET search_path TO 'public, contrib';

    Notice the single quotes around the TO bit? That's completely broken.
    Those '' must not be there.

    Is a fix for this required for only search_path, or is it a more general
    problem?
    So what are we going to do about this problem?

    The pg_settings view does not have enough information to determine it
    generically. (It only says 'string', not 'list'...)

    I propose that we modify pg_dumpall to hard-code the set of list-type
    GUC variables for each backend version.

    The current (CVS) list of such GUCs is:

    * DateStyle
    * preload_libraries
    * search_path
    * log_destination
    * custom_variable_classes (probably doesn't need to be worried about)

    Shall I go ahead and do this?

    Chris
  • Christopher Kings-Lynne at Jul 13, 2004 at 7:35 am

    So what are we going to do about this problem?

    The pg_settings view does not have enough information to determine it
    generically. (It only says 'string', not 'list'...)

    I propose that we modify pg_dumpall to hard-code the set of list-type
    GUC variables for each backend version.

    The current (CVS) list of such GUCs is:

    * DateStyle
    * preload_libraries
    * search_path
    * log_destination
    * custom_variable_classes (probably doesn't need to be worried about)

    Shall I go ahead and do this?
    Oh, and we'll need to fix the pg_settings view for the future, because
    otherwise it will make life difficult for GUI writies (like me)...

    Chris

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJun 29, '04 at 3:50a
activeJul 13, '04 at 7:35a
posts4
users2
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase