From: | Guillaume Lelarge <guillaume(at)lelarge(dot)info> |
---|---|
To: | Dave Page <dpage(at)pgadmin(dot)org> |
Cc: | "Obe, Regina" <robe(dot)dnd(at)cityofboston(dot)gov>, "pgadmin-support(at)postgresql(dot)org" <pgadmin-support(at)postgresql(dot)org> |
Subject: | Re: Bug: PgAdmin not displaying typmod column types correctly in create or display |
Date: | 2010-01-06 23:50:16 |
Message-ID: | 4B4521B8.1000101@lelarge.info |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-support |
Le 06/01/2010 19:50, Dave Page a écrit :
> On Wed, Jan 6, 2010 at 6:45 PM, Guillaume Lelarge
> <guillaume(at)lelarge(dot)info> wrote:
>> The easy way to fix this is calling format_type in the query and giving
>> it the atttypmod column of pg_attribute. I can't find if there are
>> corner cases if I do this. Dave, do you know why there is a pgDatatype?
>> it seems redundant with format_type. And the latter seems to work well
>> whereas pgDatatype is surely wrong.
>
> iirc, it was intended as a type formatting and caching mechanism, that
> can not only format individual types, but can be used to populate
> combo boxes and the like with sets of types/domains with minimal
> overhead. For example, some of the dialogues can have quite a few
> combos full of types on them, which are not always the same, and not
> necessarily cheap to populate.
>
OK. I checked every call to format_type and I think only one need to be
modified. Here is a patch that fixes the issue. I'm not quite sure it
doesn't create new ones.
--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com
Attachment | Content-Type | Size |
---|---|---|
ticket125_v1.patch | text/x-patch | 1.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Sebastian P. Luque | 2010-01-12 03:01:26 | Re: running pgagent |
Previous Message | Dave Page | 2010-01-06 18:50:39 | Re: Bug: PgAdmin not displaying typmod column types correctly in create or display |