Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Yes, it is very silly that PQoidStatus() returns a char*. I believe it
> was only done that way because it was pulling the oid out of the
> cmdStatus field. We really should return an int. Perhaps we don't
> because we would be hardcoding the oid type on the client side.
Type Oid is already visible to libpq clients: it's returned by PQftype()
as the type code for attributes. I think encouraging clients to store
oids as type Oid rather than some-int-type-chosen-at-random would be a
good thing, not a bad thing.
However, improving the cleanliness of the API might not be worth the
cost of breaking application code, even though this routine is probably
not very widely used. Does anyone else have an opinion pro or con?
> Perhaps we could double-use the cmdStatus field, perhaps when they ask
> for the oid, we put a null after the oid value, and return a pointer to
> the inside of the cmdStatus field. If the call for PQcmdStatus(), we
> remove the null and return the string. Strange, I admit.
I had a variant of that idea: what's stored in cmdStatus looks like
INSERT oidvalue count
but there's a fair amount of room left over (cmdStatus is 40 bytes ...
and we could make it bigger if we wanted). We can make PQoidStatus
copy the oidvalue into the free space:
cmdStatus = "INSERT oidvalue count\0oidvalue\0"
and return a pointer to here ...............^
That way PQcmdStatus and PQoidStatus don't interfere with each other.
The result of PQoidStatus will still get zapped by the next interaction
with the backend, but at least it's not as transient as it would be in
the errorMessage field.
But, still, converting to an integer return value would be a *lot*
cleaner.
If we were going to do that, I'd be strongly inclined to change
PQcmdTuples to return an int (or more likely a long) as well.
I can't envision any situation where people aren't writing
atoi(PQcmdTuples(conn)) so why not save them the trouble...
regards, tom lane