Thread: bug in pg_dump ALTER DATABASE
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
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