Обсуждение: Re: review patch: Distinguish between unique indexes and unique constraints

Поиск
Список
Период
Сортировка

Re: review patch: Distinguish between unique indexes and unique constraints

От
"Kevin Grittner"
Дата:
Robert Haas  wrote:
> I have committed this patch with a few changes.
Thanks.
> First, I felt that there was little point in showing this detail
> only in verbose mode; indeed, it seems like that could be confusing
> in some circumstances.  (I thought I checked this was an index not
> a constraint? Oh, crap, I forgot to say \d+). So I removed that
> check.
Well, *I* agree that it makes more sense to show it whether or not
the + is specified, but I figured I was probably outnumbered, so I
let that go:
http://archives.postgresql.org/pgsql-general/2010-04/msg00414.php
http://archives.postgresql.org/pgsql-general/2010-04/msg00417.php
Since you and I now make two votes in the other direction, and Josh
didn't seem to particularly care, we're now two votes to one in favor
of always showing it.  Note that this means that the possible
breakage of people's parsing of psql output now extends to the \d
command, not just \d+ (which was what I was assuming was driving the
preference for the more limited change).
> Second, I felt that UNIQUE, CONSTRAINT, btree (a) was one too many
> commas, so I made it just say UNIQUE CONSTRAINT, btree (a) instead.
My bad.  Josh had it your way; I accidentally introduced the extra
comma when I rearranged it for code readability.  :-(  Thanks for
catching that.
-Kevin




Re: review patch: Distinguish between unique indexes and unique constraints

От
Robert Haas
Дата:
On Sun, Aug 1, 2010 at 6:54 AM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Robert Haas  wrote:
>> I have committed this patch with a few changes.
>
> Thanks.
>
>> First, I felt that there was little point in showing this detail
>> only in verbose mode; indeed, it seems like that could be confusing
>> in some circumstances.  (I thought I checked this was an index not
>> a constraint? Oh, crap, I forgot to say \d+). So I removed that
>> check.
>
> Well, *I* agree that it makes more sense to show it whether or not
> the + is specified, but I figured I was probably outnumbered, so I
> let that go:
>
> http://archives.postgresql.org/pgsql-general/2010-04/msg00414.php
> http://archives.postgresql.org/pgsql-general/2010-04/msg00417.php
>
> Since you and I now make two votes in the other direction, and Josh
> didn't seem to particularly care, we're now two votes to one in favor
> of always showing it.  Note that this means that the possible
> breakage of people's parsing of psql output now extends to the \d
> command, not just \d+ (which was what I was assuming was driving the
> preference for the more limited change).

Also, I don't interpret either of those emails as a strong preference
in favor of showing it only in \d+ so much as an opinion that it would
be acceptable for it to work that way.  On the flip side, I have a
STRONG preference for showing the same output in both formats.  It
would make some sense to do this only in \d+ mode if it saved vertical
space, but saving horizontal space here doesn't buy you much; it's
probably not going line-wrap anyway.  As for parsing the psql output,
anyone who thinks that's the easiest way to get this information
programatically should probably reconsider, but if they choose not to
reconsider, it won't be hard to adjust to the change, and the
additional information might be useful just as it is for human
readers.

>> Second, I felt that UNIQUE, CONSTRAINT, btree (a) was one too many
>> commas, so I made it just say UNIQUE CONSTRAINT, btree (a) instead.
>
> My bad.  Josh had it your way; I accidentally introduced the extra
> comma when I rearranged it for code readability.  :-(  Thanks for
> catching that.

Heh, OK.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company