On Mon, Apr 18, 2016 at 11:04 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> I think that we could have an alternate set of functions which have >> the same interface as the syscache functions but using the transaction >> snapshot and don't actually cache anything, and it would be fine for >> what the pg_dump support functions need. > > The problem with that approach is that then you are talking about building > duplicate copies of entire layers of the system. For example, namespace.c > would have to be duplicated into one copy that uses syscache and one that > uses this not-quite-cache. If it were *only* syscache.c that had to be > duplicated, probably this would work, but ruleutils.c depends on an awful > lot of code above that level. Indeed, if it did not, the idea of > reimplementing it on the client side wouldn't be so unattractive.
Urgh. Does ruleutils.c really depend on everything in namespace.c? When I last looked at this I had the idea that at least a good chunk of ruleutils.c had only limited outside dependencies that might not be too tough to manage. However, if that's not true, then I agree that's a problem for this approach. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
