Re: [BUGS] BUG #3829: Wrong index reporting from pgAdmin III (v1.8.0 rev 6766-6767)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dave Page <dpage(at)postgresql(dot)org>
Cc: NikhilS <nikkhils(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Boonchai <boonchai(at)xsidekick(dot)com>, pgsql-bugs(at)postgresql(dot)org, pgadmin-support(at)postgresql(dot)org
Subject: Re: [BUGS] BUG #3829: Wrong index reporting from pgAdmin III (v1.8.0 rev 6766-6767)
Date: 2007-12-19 21:50:23
Message-ID: 28589.1198101023@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-support pgsql-bugs

Dave Page <dpage(at)postgresql(dot)org> writes:
> Tom Lane wrote:
>> Hm, there is a definitional issue here. Should pg_get_indexdef print
>> this stuff at all when colno is nonzero?
>> ...
>> Dave, I think we put in this variant of the function for pgAdmin ---
>> what does pgAdmin need?

> More is better for us - it saves an ugly query that will get uglier if
> we need to figure out ASC/DESC here too :-)
> I agree that we should have all or nothing though, so I'd like to see
> ASC/DESC and opclass please.

I dug through the archives and found that we've had this discussion
before ;-). The basic argument for having the per-column form of
pg_get_indexdef do what it does was that it's unreasonable for
client-side code to try to disassemble an expression tree string,
whereas extracting opclass info is a relatively straightforward
exercise in joining. There are several past threads about this:

http://archives.postgresql.org/pgsql-hackers/2003-07/msg00083.php
http://archives.postgresql.org/pgsql-general/2005-11/msg01106.php
http://archives.postgresql.org/pgsql-hackers/2006-06/msg00576.php

As of 8.3 that expands into also having to know the meaning of the
bits in indoption[], which is kind of annoying, but not even close
to being in the same league as reverse-compiling expressions.

I think the current API expectation for pg_get_indexdef is that
it produces only the index column/expression, and that we are
very likely to break client-side code if we change that.

I don't have any objection to providing an additional new API that
includes the opclass and ASC/DESC decoration in the output ... other
than that I think it's a bit too late for 8.3; adding a function
would mean forcing initdb, and I don't see any reasonable way to
shoehorn two behaviors into the existing function signature.

Just out of curiosity, why is pgAdmin doing it this way at all?
Seems it would be a lot easier to use the all-columns form of
pg_get_indexdef than to cons up the display from fetches of each
column individually.

regards, tom lane

In response to

Responses

Browse pgadmin-support by date

  From Date Subject
Next Message Dave Page 2007-12-19 22:17:46 Re: [BUGS] BUG #3829: Wrong index reporting from pgAdmin III (v1.8.0 rev 6766-6767)
Previous Message Dave Page 2007-12-19 19:49:19 Re: [BUGS] BUG #3829: Wrong index reporting from pgAdmin III (v1.8.0 rev 6766-6767)

Browse pgsql-bugs by date

  From Date Subject
Next Message Dave Page 2007-12-19 22:17:46 Re: [BUGS] BUG #3829: Wrong index reporting from pgAdmin III (v1.8.0 rev 6766-6767)
Previous Message Iuri Sampaio 2007-12-19 21:04:41 ltree installation error