Re: Simplifying unknown-literal handling

Andrew - Supernews <andrew+nonews(at)supernews(dot)com> writes:
> What happens if you send an UNKNOWN from the frontend as binary, and then
> when the desired type is figured out, it turns out to be a bytea? It's
> obviously not acceptable then to truncate after a zero byte.

This isn't an issue, because if the desired type is something other than
UNKNOWN, we won't be using UNKNOWN's binary input converter. The actual
flow of information in the case you're thinking of is:

1. Client sends Parse message with, say, query
INSERT INTO tab(byteacol) VALUES($1);
and the type of param 1 either not specified or given as UNKNOWN.

2. Backend infers actual type of param 1 from context as BYTEA.

3. Client may or may not bother issuing a Describe to find out actual
type of parameter(s).

4. Client sends BIND with a binary value; backend applies BYTEA's input
converter (which is essentially memcpy).

Offhand I think the only way you could actually invoke UNKNOWN's binary
input converter is by executing a PREPARE with a parameter position
specifically declared as UNKNOWN, viz
PREPARE foo(unknown) AS ...
and then using foo as the target of a binary BIND message. I don't
think we are under contract to promise that such a thing will have any
particular behavior; and certainly not to promise that it will behave
more like bytea than like text. In any case there is no runtime
coercion from UNKNOWN to BYTEA, so you'd really have to work at it
to cons up a case where you got behavior you didn't like.

regards, tom lane