Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] pg_dump

From: "Matthew C(dot) Aycock" <matt(at)mathcs(dot)emory(dot)edu>
To: lockhart(at)alumni(dot)caltech(dot)edu
Cc: hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] pg_dump
Date: 1998-10-01 19:01:24
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

After looking at the code for pg_dump, it appears that all identifiers
go through fmtId which does as you thougt, it looks to see if a character
is non-lower case, a digit, or an '_' then it double quotes it.
I am going to change this behavior to always double quote it and see 
if it breaks anything.

I also noted a possible memory leak that I introduced when I added
the code to dump the ACLs for tables and such. I will take care of
this as well.

My concern is that I do not have a database with enough stuff to
really test this. I tried to dump the regression and template1 
databases, but template1 had nothing in it and regression failed
not being able to find a trigger.

Does anyone have a good test database that they could send me the
pg_dump of? If it is really big, I can either ftp it from you, or
you could ftp it to me.


> We need to think about whether to surround all identifiers with double
> quotes all the time in pg_dump output. 
> The reason is that Postgres allows reserved keywords to be specified as
> table and column names if they are surrounded by the double quotes, but
> pg_dump doesn't know whether an identifier also happens to be a reserved
> keyword. afaik it's now only using DQs if there is upper case or funny
> characters in the identifier. Instead it should probably surround the
> fields with DQs all the time. It could perhaps have a command-line
> switch to turn off that feature if necessary.
> The alternative to always using the DQs is to have pg_dump use the
> keywords.c routine available in the backend. But I don't think that is
> as reliable since it isn't guaranteed to be in sync with the backend
> version and since there are non-reserved keywords in that file which
> test the same as the reserved ones.
> This should probably be a "must do" for v6.4...
> Comments?
>                       - Tom

Matthew C. Aycock
Operating Systems Analyst/Admin, Senior
Dept Math/CS
Emory University, Atlanta, GA 
Internet:  matt(at)mathcs(dot)emory(dot)edu 		


pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-10-01 21:29:42
Subject: Re: [HACKERS] It sorta works, but I'm confused about locking
Previous:From: Jackson, DeJuanDate: 1998-10-01 16:56:42
Subject: RE: [ADMIN] Having problems compiling postgres on IRIX

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group