From: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: new psql \d command |
Date: | 2003-08-07 16:38:43 |
Message-ID: | 3F328093.4050901@pse-consulting.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
>Tom Lane wrote:
>
>
>>Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>>
>>
>>>It just seemed complex to figure out which operators needed parens and
>>>which didn't.
>>>
>>>
>>The fact that the first attempt was wrong doesn't improve my faith in
>>that code one bit ;-).
>>
It was posted expressively with request for comment/review to locate
bogus/non-fail-safe assumptions. That operator thing was introduced
last-minute before feature freeze, coded late at night.
>>I don't want pg_dump invoking it, even as an option. Someone will get burnt.
>>
>>
>
>Yes, even if we get it right now, it might break in the future by a
>change somewhere else, and we may not discover the breakage until it is
>too late.
>
Doesn't this apply to any change?
pg_dump can be used as a kind of reverse-engineer tool, that's why
user-readability can make sense. I wonder when somebody wishes pgAdmin3
to do that for a complete db (effectively duplicating pg_dump's feature)...
Regards,
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-08-07 16:39:30 | When did we get to be so fast? |
Previous Message | Andreas Pflug | 2003-08-07 16:31:19 | Re: new psql \d command |