Re: Problem editing tables (geom columns)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(First of all sorry for cross-posting but I feel this is a matter that
interests all recipients)
Thread on pgadmin support:
http://www.pgadmin.org/archives/pgadmin-support/2007-06/msg00046.php

Hello Dave,

This behavior (trying to show the entire geometry field) in Fedora
Core 6, pgAdmin3 1.6.2, doesn't happen...
In that scenario the geom field is simply shown blank.

Nevertheless, if I recall it correctly, proj4, geos, postgis versions,
in the above scenario, were older than the ones I'm using...
So I wonder... could it be that pgadmin's code changed for showing
large fields?
Could one of proj4, geos, postgis code changed that really interferes
with pgadmin3?

IMHO, regardless of the scenario involved, the output for large geom
fields should be suppressed in table edition... (as seen in the past)
The current behavior hogs way too much processor time.

<Dave>
I've tested with a micro-subset of my data (only one record with a
small parish geometry) and it shows although the slowness is
immediately apparent...
</Dave>

Kind regards,
Pedro Doria Meunier

Dave Page wrote:
> Dave Page wrote:
>> Pedro Doria Meunier wrote:
>>> I've seen in the known issues for ver 1.6.3 that there's a
>>> problem with editing tables with long fields...
>> Where do you see that?
>>
>>> Strangely enough I've used this version before with Fedora Core
>>> 6 and there wasn't a problem with postgis tables.... :$ A long
>>> work has already been done setting up Fedora 7 to my taste so
>>> I'm really not too keen on downgrading to FC6... :-(
>>>
>>> So, I'm a bit lost here... Is this a GTK issue? What can I do
>>> to fix this?
>> Can you supply me a sample table and data to test with please?
>
> I've been playing with the data that Pedro supplied me offlist, and
> the problem is basically that he has a geometry value (basically a
> string) in a column of around 4MB. I think it's fairly safe to say
> that we'd be lucky to find that any of the grid controls on any of
> the platforms we support were happy with this amount of data in a
> single cell - in testing on Windows for example, whilst it works,
> it does slow to a crawl.
>
> I think the only sensible option would be to add an additional tab
> to the sort/filter dialog to allow the data to be vertically
> partitioned to exclude such columns. This isn't going to happen for
> the next release though I'm afraid.
>
> Thoughts?
>
> Regards, Dave.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Remi - http://enigmail.mozdev.org

iD8DBQFGeWFf2FH5GXCfxAsRArySAKCeVIK5uzDEs+Q6ZS0A2Jye6c5h0ACeKlkf
MqNA+rBORwi5Ko2x/rRV+Cc=
=rOET
-----END PGP SIGNATURE-----