Bug: psql misquotes constraints

As a result of the constraint output functions being shared between
pg_dump and psql, some of the output is mis-quoted in the display area
for columns including quotes. Notice it's correct in the table Column
list, but the constraint has the escaped versions.

It's misquoted because psql DOES NOT share the fmtId function with
pg_dump. It simply puts double quotes around it. If you can fix psql
so that it is able to link to the fmtId function, then you can easily
fix the problem.

Chris

I can do that for 7.6. Is it worth it? Is it a TODO?

---------------------------------------------------------------------------

Christopher Kings-Lynne wrote:

As a result of the constraint output functions being shared between
pg_dump and psql, some of the output is mis-quoted in the display area
for columns including quotes. Notice it's correct in the table Column
list, but the constraint has the escaped versions.

It's misquoted because psql DOES NOT share the fmtId function with
pg_dump. It simply puts double quotes around it. If you can fix psql
so that it is able to link to the fmtId function, then you can easily
fix the problem.

Chris

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Sun, 2004-07-11 at 20:57, Bruce Momjian wrote:

I can do that for 7.6. Is it worth it? Is it a TODO?

I'm not sure what Christopher mentioned is the correct fix. The
information is displayed correctly in all places except where a
pg_get_.* function is used (indexes, constraints, etc.).

Those functions are tailored to what pg_dump requires (escaped
identifier: """vers""ion""") rather than what psql requires (unescaped
identifier: "vers"ion").

Right now psql shows a mix of both.

It should be done, otherwise you cannot copy and paste foreign key
creation code from the psql output :)

Chris

Bruce Momjian wrote:

I'm not sure what Christopher mentioned is the correct fix. The
information is displayed correctly in all places except where a
pg_get_.* function is used (indexes, constraints, etc.).

The name of the constraint (ie. the "$1" bit) is done by psql, the rest
comes from the pg_get_function.

Chris

I remember a thread about pretty-print functions. Are those used? This
is probably the best place to put the fix, since they already munge
things for display purposes.

On Sun, 2004-07-11 at 21:34, Christopher Kings-Lynne wrote:

I'm not sure what Christopher mentioned is the correct fix. The
information is displayed correctly in all places except where a
pg_get_.* function is used (indexes, constraints, etc.).

The name of the constraint (ie. the "$1" bit) is done by psql, the rest
comes from the pg_get_function.

I didn't even notice the "$1" bit.

btree ("""vers""ion""")

I was hoping the above would be:

btree ("vers"ion")

I remember a thread about pretty-print functions. Are those used? This
is probably the best place to put the fix, since they already munge
things for display purposes.

Seriously man - the pg_get_def stuff ONLY does the string from the words
FOREIGN KEY onwards. The constraint name is done by psql. Pretty
printing won't help you.

Chris

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:

It should be done, otherwise you cannot copy and paste foreign key
creation code from the psql output :)

Since when was that a design goal for psql's \d output? We had better
revert the entire pretty-printing patch if you expect this sort of thing
to work reliably. I thought the point of \d formatting was to be
readable, not to be technically the exact same SQL you'd need to enter.

regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:

Since when was that a design goal for psql's \d output? We had better
revert the entire pretty-printing patch if you expect this sort of thing
to work reliably. I thought the point of \d formatting was to be
readable, not to be technically the exact same SQL you'd need to enter.

Hm, I always assumed it would work. It always did modulo quoting issues around
$n.

It's certainly inconvenient if it doesn't given that there's no supported way
to disable a particular constraint and then reenable it later without having
the source available.

--
greg

Since when was that a design goal for psql's \d output? We had better
revert the entire pretty-printing patch if you expect this sort of thing
to work reliably. I thought the point of \d formatting was to be
readable, not to be technically the exact same SQL you'd need to enter.

Hm, I always assumed it would work. It always did modulo quoting issues around
$n.

It's certainly inconvenient if it doesn't given that there's no supported way
to disable a particular constraint and then reenable it later without having
the source available.

One thing that would be nice about using fmtId in psql is that names
that DON'T need to be quoted would not be quoted.

Chris