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
