I wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Presumably we should also fix libpq to not be so dumb. I mean, it
>> doesn't help with the immediate problem, since as you say there could
>> be non-upgraded copies of libpq out there for the indefinite future,
>> but it still seems like something we oughta fix.
> It's been in the back of my mind for awhile that doing a dynamic query at
> all here is pretty pointless. It's not like the OIDs of those functions
> ever have or ever will move. It would probably be more robust if we
> just let libpq be a consumer of fmgroids.h and refer directly to the
> constants F_LO_CREATE etc.
I thought a bit more about this. Ignore for the moment the larger
question of whether we want to consider fmgroids.h as something we'd
export to clients outside the immediate core infrastructure; that
will definitely take more thought than we can expend if we want to
slip this into 9.4. It still seems reasonable for libpq to use it.
The actual code changes in fe-lobj.c are trivial enough (and would
consist mostly of code removal). We would need to deal with the fact
that some of the support functions are not present in older backends,
but I think testing PQserverVersion is adequate for that purpose.
The hard part seems to be making sure that fmgroids.h is available to
reference, since it's a generated file and not guaranteed to be there
a-priori. In a gmake-driven build I have the skillz to deal with that,
but I am not sure what to do in the various Windows build systems,
especially for the client-code-only build methods. The path of least
resistance would be to just assume fmgroids.h is available, which would
work fine when building from a tarball, or probably when doing a full
build including backend (MSVC builds aren't parallel are they?). But
what about a client-only build?
regards, tom lane
