> -----Original Message-----
> From: Magnus Hagander [mailto:mha@sollentuna.net]
> Sent: 26 January 2006 11:37
> To: Dave Page; Andreas Pflug
> Cc: pgadmin-hackers@postgresql.org
> Subject: RE: [pgadmin-hackers] Query tool: Autocompletion
>
> > > Don't know enough about the classes to really comment. They
> > can't be
> > > built on-demand somehow?
> >
> > Yeah, but my point is that typing in the query tool might
> > trigger a DB connect followed by a deep build of the tree
> > which might be very expensive. That might outweigh the
> > benefits of using the cache.
>
> Right. But couldn't you have it not do a deep build, but a
> shallow one?
> So when I hit <tab> (or whatever) where it wants a table
> name, you build
> the list of tables *only*. Or use the cache when you have it.
> Then wheni
> t wants attributes for "table a", you build the cache of that.
Yeah, that is as far as it needs to go, but down to table level is deep
enough. For example, the standard connect and restore goes to that
level, and in a quick test here that took about 13 seconds for
borg.postgresql.org. Using the pre-existing connection is definitely
going to be far faster than that kind of unnacceptable delay.
> If you really need the cache. I'm not sure the cost is so big, I've
> never had problems with psql and I use tab completion all the time
> there... Though most of my dbs don't have a huge amount of tables, it
> might be a problem then I guess.
>
> BTW, I also have this notion of being able to run *just* the query
> editor (not just start pgadmin and open the query editor, but never
> actually build the tree and stuff when I know I'm not going
> to need it).
> Not sure if others want that as well, or what effect it would have on
> something like this, just wanted to point it out :)
I could very often do with that capability.
I'm more or less convinced that the current patch is the optimal
approach overall.
Regards, Dave
