> > I've spent several hours now to get the beast compiled,
> still no go.
> > It's a nightmare I don't like to spend more time on.
>
> Hmm, I got it going in 5 minutes in VC6. Works quite well.
That's about how long it took me as well to apply it to a different
machine and run there. Only done it in VS, though.
> > Dave, if you succeed hacking something workable that doesn't try to
> > call more core pgsql includes from somewhere (!), commit it. Note:
> > pgsql copied stuff should go to src/db, not utils.
>
> Well, I can certainly commit what's there fairly quickly.
>
> > Actually, I doubt that the psql way is desirable at all. Instead of
> > constantly accessing the db for completion candidates,
> using pgAdmin's
> > object tree as cache should be the way to go.
>
> That's a good point. Magnus, any thoughts on doing it that way?
> Shouldn't be too hard to swap out the queries for scans of the tree.
Well, it kind of takes out the whole idea of using psql. The queries are
one of the main things that we pull in from psql. That means we rewrite
the matching logic, and if we do that, we should just skip the whole
idea of pulling it in from psql. Which also means we need to maintain it
separatly, the avoidance of which was one of the main reasons I looked
at stealing-from-psql as a solution.
But it certainly *can* be done. Though I think it's more work than "not
too hard".
> Mind you, the downside of that is that tab complete would
> essentially have to build large chunks of the tree on
> databases that might not even be connected in response to
> random typing in the query tool. Whilst it seems a nice idea
> to use the tree objects as a cache, it could have some pretty
> nasty side effects.
Don't know enough about the classes to really comment. They can't be
built on-demand somehow?
//Magnus