Hi Dave,
On 24/11/12 23:21, Dave Page wrote:
This is a nice idea, but can't we use/extend the pgDatatype class?
That's already intended to handle type caching, albeit not between
connections, if memory serves (I'm not sure that's a good idea anyway,
as one session may see a different set of types to another at any
given point in time).
Good idea; I was being overly conservative, replacing only like for like.
I'm converting to use this class so the cache is more generally
applicable. It's more efficient, too: no need to load every typmod
variant from the server.
I only had a few hours to work on it so far, so no patch release yet,
but the WIP is on github aiht/pgadmin if you're interested.
* I have copied the i prefix on some methods, but I don't really understand
what it's for; I was thinking perhaps 'internal'?
Yes - it's used for setters that are supposed to be private. I
wouldn't be surprised if some of them are public now though (they
could be fixed if you're feeling bored).
Thanks. I'm not quite that bored right now, sorry. Maybe later :)
It should probably pre-cache them all. That'll be a lot cheaper.
Agreed. I have also added support for single-record loading in the
DatatypeReader so that new types (created after the cache was filled)
can still be loaded later.
* When a pgConn is Duplicate()d, its cache is copied for the new connection
to use, but as far as I can see this is only called when doing File->New
Window in the query tool. If more pgConns are constructed by Duplicate()
then caching may be more efficient.
Not so sure about that, as mentioned above.
Yeah, now that I've looked closer it doesn't seem so easy to Duplicate()
other connections. It seems safe in the query tool because the new
window uses the same host/db/etc. But perhaps I am missing some points
about e.g. schema search paths?
* Quite a few other parts of the code do their own type-info loading; at
least a few of them could share in this cache. However, the other code does
not load types one by one so they do not have the same latency issues as the
query tool.
Yeah, but it would give us a common interface, and overall would
improve efficiency.
Agreed; still worthwhile.
Thanks,
Harun
--
Sent via pgadmin-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers
