Pedro Doria Meunier wrote:
> (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,
Hi Pedro
> 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.
There have been no changes in pgAdmin between 1.6.2 and 1.6.3 that might
account for this behavioural change afaict. I imagine it's probably some
difference in the platform's grid control between the two Fedora versions.
> 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?
Unlikely. The data is essentially just text, and pgAdmin treats it as such.
> 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.
Well, the suppression you saw wasn't us - I would guess it was simply
that the grid control on the older Fedora just ignores the longer data.
The problem we have trying to suppress it ourselves is that we'd either
need to do it on a per row basis (because we only actually look at the
data when a row is rendered on screen), or pre-scan all the data in
every column before displaying it and make a decision on whether or not
we should suppress entire column.
The problem with the first idea is that it would be very confusing for
the user - we might have some rows that we suppress and thus aren't
editable, and others that we don't and therefore can be edited. The
second method returns us back towards the <= v1.4 behaviour where we had
query runtime + display time in the query tool. It would significantly
slow things down :-(
What I'm currently thinking is just that we add a tab to the Filter/Sort
dialog to allow non-primary key columns to be switched on or off, so you
can disable the larger columns before the query is even run. We can make
that more convenient by saving those options (as well as the sort/filter
options) on a per-table basis.
I'd like some more thoughts from some of the other pgAdmin devs before
we settle on that though.
Regards, Dave
