Skip site navigation (1) Skip section navigation (2)

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

From: Dave Page <dpage(at)postgresql(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 22:17:46
Message-ID: 4769988A.5090504@postgresql.org (view raw or flat)
Thread:
Lists: pgadmin-supportpgsql-bugs
Tom Lane wrote:
> 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

Ah, that takes me back :-)

> 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.

Agreed.

> 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'm sure there are far more catalog/API changes that'll affect any app
likely to be using this form of pg_get_indexdef, but I can live without
adding another.

> 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.

Agreed - now is not the time to be adding new functions.

> 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.

We use the data in various UI elements as well as for reverse
engineering the SQL - it's easier to get it broken down than to parse it
back out of the complete definition.

/D

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2007-12-20 00:27:51
Subject: Re: [BUGS] BUG #3829: Wrong index reporting from pgAdmin III (v1.8.0 rev 6766-6767)
Previous:From: Tom LaneDate: 2007-12-19 21:50:23
Subject: Re: [BUGS] BUG #3829: Wrong index reporting from pgAdmin III (v1.8.0 rev 6766-6767)

pgadmin-support by date

Next:From: Tom LaneDate: 2007-12-20 00:27:51
Subject: Re: [BUGS] BUG #3829: Wrong index reporting from pgAdmin III (v1.8.0 rev 6766-6767)
Previous:From: Tom LaneDate: 2007-12-19 21:50:23
Subject: Re: [BUGS] BUG #3829: Wrong index reporting from pgAdmin III (v1.8.0 rev 6766-6767)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group