On Tue, Jan 17, 2017 at 8:54 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > I think that we could get a committer look at that at the least.
This is sort of awkward, because it would be nice to reuse the code for the existing SHOW command rather than reinventing the wheel, but it's not very easy to do that, primarily because there are a number of places which rely on being able to do catalog access, which is not possible with a replication connection in hand. I got it working after hacking various things, so I have a complete list of the problems involved: 1. ShowGUCConfigOption() calls TupleDescInitEntry(), which does a catcache lookup to get the types pg_type entry. This isn't any big problem; I hacked around it by adding a TupleDescInitBuiltinEntry() which knows about the types that guc.c (and likely other builtins) care about. 2. SendRowDescriptionMessage calls getBaseTypeAndTypmod(), which does a catcache lookup to figure out whether the type is a domain. I short-circuited it by having it assume anything with an OID less than 10000 is not a domain. 3. printtup_prepare_info calls getTypeOutputInfo(), which does a catcache lookup to figure out the type output function's OID and whether it's a varlena. I bypassed that with an unspeakable hack. 4. printtup.c's code in general assumes that a DR_printtup always has a portal. It doesn't seem to mind if the portal doesn't contain anything very meaningful, but it has to have one. This problem has nothing to do with catalog access, but it's a problem. I solved it by (surprise) creating a portal, but I am not sure that's a very good idea. Problems 2-4 actually have to do with a DestReceiver of type DestRemote really, really wanting to have an associated Portal and database connection, so one approach is to create a stripped-down DestReceiver that doesn't care about those things and then passing that to GetPGVariable. That's not any less code than the way Beena coded it, of course; it's probably more. On the other hand, the stripped-down DestReciever implementation is more likely to be usable the next time somebody wants to add a new replication command, whereas this ad-hoc code to directly construct protocol messages will not be reusable. Opinions? (Hacked-up patch attached for educational purposes.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
grotty-replication-show-hack.patch
Description: invalid/octet-stream
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
