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 assu
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
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 o
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 "
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
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
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
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
--
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
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
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 sh
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 ("""ver
12 matches
Mail list logo
