Re: Function proposal to find the type of a datum

On Fri, Feb/ 2/07 03:06:19AM -0500, Tom Lane wrote:
> Kate F <kate(at)cats(dot)meow(dot)at> writes:
> > The difference between OF and this function is that this function is
> > pulling the type from the datum, rather than explicitly testing it
> > against types the user suggests. If I wanted to find the type of x
> > using OF, I would have to check it for all types which interest me:
>
> > IF a IS OF (INTEGER) THEN
> > t := 'INTEGER';
> > ELSE IF a IS OF (TEXT) THEN
> > t := 'TEXT';
> > ELSE IF a IS OF (REAL) THEN
> > t := 'REAL';
> > ...
> > and so on. Versus:
>
> > t := pg_type_of(a);
>
> Well, but what are you going to do with "t" after that? AFAICS the
> next step is going to be something like
>
> IF t = 'integer'::regtype THEN
> ...
> ELSE IF t = 'text'::regtype THEN
> ...
> etc etc

I don't follow that cast at all, I'm afraid. I wasn't intending to
have a set of IF..ELSE IF statements like that, though - see below.

> So it seems to me that this is functionally about the same, except that
> it exposes two implementation-dependent concepts (pg_type OIDs and
> regtype) where the first exposes neither.
>
> Your approach would help if there were a reason to pass "t" as a
> variable to someplace not having access to "a", but I don't see a
> very compelling use-case for that.

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.

Of course, I don't want to expose anything unneccessarily.

> > Secondly, the semantics are different: OF yields the type the datum
> > currently is; pg_type_of() (perhaps it should be renamed?) returns the
> > most appropiate type to which the datum may be cast, if I understand
> > get_fn_expr_argtype() correctly.
>
> You don't, I think --- there's really no such thing as a "datum of type
> ANYELEMENT", real datums always have some more-specific type. But my
> question upthread was directed exactly to the point of how we should
> interpret IS OF applied to a polymorphic function argument. It's at
> least possible to argue that it's OK to interpret it the way you need.

I've no suggestion to make on whether IS OF should look inside
ANYELEMENT or not.

This is quite past my knowledge of PostgreSQL... If I understand you
correctly, ANYELEMENT is unrelated to my suggestion.

I see my misunderstanding: '2' IS OF (INTEGER) yields false: fine.
However I was expecting that pg_type_of('2') would return 'INTEGER': it
wouldn't, of course. So, I understand you here: there would be no
difference between this and IS OF in the way I had imagined.

That still leaves the difference in usage I mention above. Does that
sound sane?

Thank you,

--
Kate