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.

Thoughts?

rt=# create table c ("""vers""ion""" integer unique references a);
NOTICE:  CREATE TABLE / UNIQUE will create implicit index
"c_"vers"ion"_key" for table "c"
CREATE TABLE

rt=# \d c
         Table "public.c"
   Column   |  Type   | Modifiers
------------+---------+-----------
 "vers"ion" | integer |
Indexes:
    "c_"vers"ion"_key" unique, btree ("""vers""ion""")
Foreign-key constraints:
    "$1" FOREIGN KEY ("""vers""ion""") REFERENCES a("version")



Thu, 08 Jul 2004 12:24:21 -0400
Rod Taylor <pg@rbt.ca>
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


Fri, 09 Jul 2004 10:30:11 +0800
Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: Bug: psql misquotes constraints

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

Sun, 11 Jul 2004 20:57:08 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Bug: psql misquotes constraints
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.

> 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


Sun, 11 Jul 2004 21:21:58 -0400
Rod Taylor <pg@rbt.ca>
Re: Bug: psql misquotes constraints
It should be done, otherwise you cannot copy and paste foreign key 
creation code from the psql output :)

Chris

Bruce Momjian wrote:

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

Mon, 12 Jul 2004 09:33:49 +0800
Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: Bug: psql misquotes constraints
> 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


Mon, 12 Jul 2004 09:34:52 +0800
Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: Bug: psql misquotes constraints
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:33, Christopher Kings-Lynne wrote:
> It should be done, otherwise you cannot copy and paste foreign key 
> creation code from the psql output :)
> 
> Chris
> 
> Bruce Momjian wrote:
> 
> > 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
> >>
> > 
> > 


Sun, 11 Jul 2004 21:36:42 -0400
Rod Taylor <pg@rbt.ca>
Re: Bug: psql misquotes constraints
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")



Sun, 11 Jul 2004 21:40:22 -0400
Rod Taylor <pg@rbt.ca>
Re: Bug: psql misquotes constraints
> 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


Mon, 12 Jul 2004 09:48:51 +0800
Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: Bug: psql misquotes constraints
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

Sun, 11 Jul 2004 21:59:48 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Bug: psql misquotes constraints 

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


12 Jul 2004 02:31:09 -0400
Greg Stark <gsstark@mit.edu>
Re: Bug: psql misquotes constraints
>>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


Mon, 12 Jul 2004 14:55:54 +0800
Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: Bug: psql misquotes constraints