Re: Function proposal to find the type of a datum

From: Kate F <kate(at)cats(dot)meow(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Function proposal to find the type of a datum
Date: 2007-02-02 16:10:38
Message-ID: 20070202161038.GE390@cats.meow.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb/ 2/07 09:52:08AM -0500, Tom Lane wrote:
> 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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-02-02 16:17:46 Re: Function proposal to find the type of a datum
Previous Message Bruce Momjian 2007-02-02 16:10:37 Re: --enable-debug does not work with gcc