Re: [HACKERS] bug in pg_dump ALTER DATABASE

2004-07-13 Thread Christopher Kings-Lynne
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
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html


Re: [HACKERS] bug in pg_dump ALTER DATABASE

2004-07-13 Thread Christopher Kings-Lynne
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
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
 subscribe-nomail command to [EMAIL PROTECTED] so that your
 message can get through to the mailing list cleanly


Re: [HACKERS] bug in pg_dump ALTER DATABASE

2004-06-28 Thread Tom Lane
Christopher Kings-Lynne <[EMAIL PROTECTED]> 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

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


[HACKERS] bug in pg_dump ALTER DATABASE

2004-06-28 Thread Christopher Kings-Lynne
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
---(end of broadcast)---
TIP 6: Have you searched our list archives?
  http://archives.postgresql.org