Re: bug in pg_dump ALTER DATABASE - Mailing list pgsql-hackers

From Christopher Kings-Lynne
Subject Re: bug in pg_dump ALTER DATABASE
Date
Msg-id 40F38FB7.3000002@familyhealth.com.au
Whole thread Raw
In response to bug in pg_dump ALTER DATABASE  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Responses Re: bug in pg_dump ALTER DATABASE
List pgsql-hackers
> 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



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: possibly updating techdocs; mysql2pgsql on gborg
Next
From: Christopher Kings-Lynne
Date:
Subject: Another pg_dump bug