"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
>> I'd like to see something done about this fairly soon, but it's not
>> happening for 7.3 ...
> Does anyone have an idea about what other functions are affected by this?
As a first approximation, every output function for a built-in
pass-by-reference datatype will show this same behavior. cash_out is
just getting picked on because it was the one mentioned in the first
complaint. For that matter, every input function for any datatype
has the same problem:regression=# select cash_in(2);server closed the connection unexpectedly
Let's see ... I count 264 standard pg_proc entries that are declared
with one or more "opaque" parameters. Many but by no means all are I/O
functions. There are another 13 standard functions declared to return
"opaque". To plug the hole in a credible fashion we'd need to do
something about every one of these; so belay that last suggestion that
just implementing a "C string" pseudo-type would be enough to be
meaningful.
Right offhand it looks like we'd need at least:"C string" for the I/O functions"internal type" for index access
functions,selectivity, etc"any array" for array_eq and array_dims"any type" for count(*) (and not much else!)"tuple"
forthe return type of trigger functions"void" for the return type of things that return voidnot sure about encoding
conversionfunctions
The functions handling internal-type stuff are probably things we don't
want the user calling at all. As long as we don't declare any of them
to *return* an internal type, there would be no way to construct a
function call that the parser would accept, so that hole would be
plugged with just one pseudo-type; we don't really need to distinguish
which internal type is meant in any one case. The "any array"
pseudo-type would probably take a special-case kluge in parse_coerce,
but that doesn't seem intolerable.
Anyone see something I missed? Tatsuo, what exactly should the function
signature really be for all those encoding conversion functions you just
added?
regards, tom lane
