"Rod Taylor" <rbt@zort.ca> writes:
> Step 2 is to teach oper_select_candidate() about functions which
> accept unknown and _unknown that can be used as a last resort. We
> will allow coercions to type unknown and _unknown from any type to
> accomplish this but only in this specific case. Why unknown and not
> text?
Rather than unknown, how about some new special pseudo-type?
We've already shot ourselves in the feet enough times by overloading
type OID 0 to mean so many slightly-different things. I have ranted
on this topic before, see the archives; but even past midnight I can
name several distinct meanings of "type 0" without stopping for breath:
plain old invalid placeholder, as in pg_proc.proargtypes entries beyond
the pronargs'th one; C string for I/O functions; takes/returns an
internal type, as in the various cost estimation functions for the
optimizer and the various index access method functions (note there are
several *different* internal types involved there), not to mention
trigger functions which really really ought to have a distinguishable
signature; "returns void"; "takes any type at all" (COUNT(*)); "takes
any array type" (array_dims); ... okay, I'm out of breath.
Meanwhile in the type resolver's domain we have "unknown" literals,
and we've speculated many times about inventing "unknown numeric"
literals to clean up the problems with assignment of types to numeric
constants. Let's *not* make the mistake of overloading "unknown" to
have some array-specific meaning.
I believe that the best ultimate resolution of these problems will
involve creating a spectrum of "pseudo-types" with different, sharply
defined meanings. Breaking up "opaque/type 0" is going to cause a
lot of backward-compatibility pain, so I have not been in a big hurry
to do it --- but let's get it right the first time when dealing with
shades of "unknown".
regards, tom lane
