OIDs are a pain to deal with IMO. They will not survive a dump style restore, and are hard to keep synchronized between databases...type names don't have this problem. OIDs are an implementation artifact that ought not need any extra dependency.
AFAIK, OID's for built-in types don't change.
Clearly we need more thought on how to deal with UDT's
Yeah. Not having a solution that handles arrays and composites though would feel pretty incomplete since they would be the one of the main beneficiaries from a performance standpoint. I guess minimally you'd need to expose some mechanic to look up oids, but being able to specify "foo"."bar", in the GUC would be pretty nice (albeit a lot more work).
This seems like a protocol or even a driver issue rather than a GUC issue. Why does the server need to care what format the client might want to prefer on a query by query basis?
Actually this isn't a query by query basis. The point of this is that the client wants all the results for given OID's in binary.
Yep. Your rationale is starting to click. How would this interact with existing code bases? I get that JDBC is the main target, but how does this interact with libpq code that explicitly sets resultformat? Perhaps the answer should be as it shouldn't change documented behavior, and a hypothetical resultformat=2 could be reserved to default to text but allow for server control, and 3 as the same but default to binary.
