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: 199810011901.PAA28371@cssun.mathcs.emory.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Well,

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.

Thanks,

Matt
> 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

Responses

Browse pgsql-hackers by date

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