Kate F <[EMAIL PROTECTED]> 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
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.
> 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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
