Re: lo_create(oid, bytea) breaks every extant release of libpq

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: lo_create(oid, bytea) breaks every extant release of libpq
Date: 2014-06-12 15:19:33
Message-ID: 24954.1402586373@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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 think there was some previous discussion about this, possibly tied
to also having a better-defined way to let clients depend on hard-wired
type OIDs, but I'm too lazy to search the archives right now.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Johnston 2014-06-12 15:32:49 Re: [9.3] Should we mention "set_config(...)" in 18.1.3 in Server Configuration?
Previous Message Pavel Stehule 2014-06-12 15:19:06 Re: lo_create(oid, bytea) breaks every extant release of libpq