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
