Обсуждение: Bug: PgAdmin not displaying typmod column types correctly in create or display

I assume this is a PgAdmin III bug, but I could be wrong.
I'm using PgAdmin 1.10.1 on Windows, but seems to be an issue with even 1.8 since I tried on that too.

The upcoming PostGIS 1.5 has a new type called geography that uses the Typmod functionality introduced in 8.3.

I'm guessing this is a display bug in how PgAdmin is displaying typmod types.

Details here

http://trac.osgeo.org/postgis/ticket/368

What is interesting is if I do a select of the table in question, the geography header shows correctly as

geography(Point,4326) or geography(Linestring,4326)

so it seems its just in the 

CREATE TABLE ... that displays on the side panel of PgAdmin or when you select generate create script.


I could of sworn I saw it right at some point before (but installing a previous experimental build of PostGIS behaved
thesame). Perhaps I was always focusing on the display of the SELECT... of its display in phppgadmin which correctly
displaysthe type.
 

In case you need to test, have windows experimental builds here
http://www.postgis.org/download/windows/experimental.php

Thanks,
Regina

-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.

Le 04/01/2010 13:29, Obe, Regina a écrit :
> I assume this is a PgAdmin III bug, but I could be wrong.
> I'm using PgAdmin 1.10.1 on Windows, but seems to be an issue with even 1.8 since I tried on that too.
> 
> The upcoming PostGIS 1.5 has a new type called geography that uses the Typmod functionality introduced in 8.3.
> 
> I'm guessing this is a display bug in how PgAdmin is displaying typmod types.
> 
> Details here
> 
> http://trac.osgeo.org/postgis/ticket/368
> 
> What is interesting is if I do a select of the table in question, the geography header shows correctly as
> 
> geography(Point,4326) or geography(Linestring,4326)
> 
> so it seems its just in the 
> 
> CREATE TABLE ... that displays on the side panel of PgAdmin or when you select generate create script.
> 
> 

Seems you're right. It should be easy to fix, but I want to find if
there are any corner cases. Anyways, I created a ticket for your bug:
http://code.pgadmin.org/trac/ticket/125

> I could of sworn I saw it right at some point before (but installing a previous experimental build of PostGIS behaved
thesame). Perhaps I was always focusing on the display of the SELECT... of its display in phppgadmin which correctly
displaysthe type.
 
> 

I don't think so. I can be wrong, but I don't think we did something
like that before. typmod is available since 1.10, and I don't remember
we fix something for typmod in 1.10.1.

> In case you need to test, have windows experimental builds here
> http://www.postgis.org/download/windows/experimental.php
> 

I tried it, but failed to make it work. Finally, I compiled PostGIS SVN
on Linux, which was more easy.


-- 
Guillaume.http://www.postgresqlfr.orghttp://dalibo.com

Le 05/01/2010 23:16, Guillaume Lelarge a écrit :
> Le 04/01/2010 13:29, Obe, Regina a écrit :
>> I assume this is a PgAdmin III bug, but I could be wrong.
>> I'm using PgAdmin 1.10.1 on Windows, but seems to be an issue with even 1.8 since I tried on that too.
>>
>> The upcoming PostGIS 1.5 has a new type called geography that uses the Typmod functionality introduced in 8.3.
>>
>> I'm guessing this is a display bug in how PgAdmin is displaying typmod types.
>>
>> Details here
>>
>> http://trac.osgeo.org/postgis/ticket/368
>>
>> What is interesting is if I do a select of the table in question, the geography header shows correctly as
>>
>> geography(Point,4326) or geography(Linestring,4326)
>>
>> so it seems its just in the 
>>
>> CREATE TABLE ... that displays on the side panel of PgAdmin or when you select generate create script.
>>
>>
> 
> Seems you're right. It should be easy to fix, but I want to find if
> there are any corner cases. Anyways, I created a ticket for your bug:
> http://code.pgadmin.org/trac/ticket/125
> 

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.


-- 
Guillaume.http://www.postgresqlfr.orghttp://dalibo.com

On Wed, Jan 6, 2010 at 6:45 PM, Guillaume Lelarge
<guillaume@lelarge.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.


-- 
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Le 06/01/2010 19:50, Dave Page a écrit :
> On Wed, Jan 6, 2010 at 6:45 PM, Guillaume Lelarge
> <guillaume@lelarge.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