Re: Function proposal to find the type of a datum

Kate F <kate(at)cats(dot)meow(dot)at> writes:
> In my case, I am constructing a query (to be exexecuted dynamically)
> wherein I pass along some of the arguments I am given. This query calls
> a function specified by an argument passed to me. If that function is
> overloaded, I need to be able to cast its arguments to appropiate
> types so that PostgreSQL may decide which function of that name to
> call. I'm sure there must be other uses, (or is this an unneccessary
> feature?).
> For the moment, I'm only using this information to see if I need to
> quote a parameter or not, but I suspect my function will trip up when
> told to execute something that is overloaded in a more complex way.

Hmmm. Actually, I think you'd be best off not to think in terms of
"quote or not", but instead always quote and cast. You're going to be
building up strings to EXECUTE, right? ISTM what you want is something
like

... || quote_literal(aparam::text) || '::' || type_name_of(aparam) || ...

where type_name_of is something that produces the type name as a string,
not directly its OID. So one way to counter the "it's exposing internal
concepts" gripe is to not expose the OID at all just the type name.
Even if the raw function did return the OID you'd need a wrapper to
convert to a string name.

The other problem here is that I've blithely assumed that you can cast
anything to text; you can't. Now in plpgsql you can work around that
because plpgsql will cast anything to anything via textual intermediate
form, so you could hack it with

texttmp := aparam;
... || quote_literal(texttmp) || '::' || type_name_of(aparam) || ...

There's been talk off and on of allowing an explicit cast to and from
text throughout the system rather than just in plpgsql, but I dunno if
you want to fight that battle today.

regards, tom lane