Обсуждение: Bug: PgAdmin not displaying typmod column types correctly in create or display
Bug: PgAdmin not displaying typmod column types correctly in create or display
От
"Obe, Regina"
Дата:
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.
Re: Bug: PgAdmin not displaying typmod column types correctly in create or display
От
Guillaume Lelarge
Дата:
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
Re: Bug: PgAdmin not displaying typmod column types correctly in create or display
От
Guillaume Lelarge
Дата:
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
Re: Bug: PgAdmin not displaying typmod column types correctly in create or display
От
Guillaume Lelarge
Дата:
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