Thread: 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.
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")
> 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, Pennsylvania19073
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
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 >> > >
> 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: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 > >> > > > >
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