bug in pg_dump ALTER DATABASE

Christopher Kings-Lynne <chriskl@familyhealth.com.au> 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

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

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