Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group