On Fri, Feb/ 2/07 09:52:08AM -0500, Tom Lane wrote: > Kate F <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly