Re: Semi-Pseudo Data Types & Procedure Arguments

Joshua Burns <jdburnz(at)gmail(dot)com> writes:
> Has anyone played around with what I would call "Semi-Pseudo Data Types,"
> in which a stored procedure may accept a sub-set of a Pseudo Data Types but
> not just any pseudo data-type, such as any type of string (text, character
> varying, character), any type of integer (smallint, integer, bigint), or a
> single element or an array of elements?

Well, you can already handle such scenarios, no? Just accept text, or
bigint, and let the existing implicit conversions handle the other
cases.

> -- A stored procedure which can accept two argument, which can be a single
> integer field, or an array of integers.

Those two cases seem unlikely to be supportable by the same
implementation, so it seems more likely that what you'd be doing is just
overloading the function name with two instances, my_fn(int) and
my_fn(int[]).

Another trick that's often used is to use an implementation that isn't
quite as general as the signature might suggest. For example consider

create function my_add(anyelement, anyelement) returns anyelement as
'select $1 + $2' language sql;

This will work for any data type that has a "+" operator, which is a
smaller scope than the "anyelement" signature implies. Of course this
particular function is pretty useless compared to just writing "+", but
perhaps the idea will help you.

Anyway, I can't see much value in inventing "anystring" or "anyint".
The former is not distinguishable from "text" at all. The latter might
have some micro-efficiency gain compared to using "bigint", but probably
not enough to be worth the trouble.

regards, tom lane