On Fri, Feb/ 2/07 09:52:08AM -0500, Tom Lane wrote:
> Kate F <kate@cats.meow.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.
That's precisely what I suggested a moment ago! This is what I'm
proposing is added.
(And whatever the decision regarding ANYELEMENT of, I believe this
should behave the same as IS OF)
> Even if the raw function did return the OID you'd need a wrapper to
> convert to a string name.
This is what David did in his article.
> 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) || ...
That's interesting - I didn't realise that not everything could be cast
to text.
> 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.
I'm sticking to things I could possibly implement :)
Thank you,
--
Kate