Re: [HACKERS] Bug: psql misquotes constraints
Tom Lane [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] 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: version) rather than what psql requires (unescaped identifier: version). 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] 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 (version) I was hoping the above would be: btree (version) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Bug: psql misquotes constraints
Christopher Kings-Lynne [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
