On Sat, 2011-01-08 at 21:58 -0500, Robert Haas wrote:
> I mean, one semi-obvious possibility is to write one set of C
> functions that can have multiple SQL-level definitions bound to it.
> Then when the function is called, it can peek at flinfo->fn_oid to
> figure out which incarnation was called and then get the typo info
> from there. That's ugly, though.
That would work, but it is pretty ugly. It means it would be very
difficult for users to write new generic functions, because they would
need to add a new catalog entry for every existing range type.
Then again, wasting 4 bytes per row is not ideal, either. And maybe
users could still write some useful generic functions if they were a
combination of other generic functions, using the polymorphic system.
> It'd be really nice if we could just arrange for the info on which
> type anyrange actually is at the moment to be available in the right
> place. Storing it on disk to work around that is pretty horrible, but
> maybe there's no other reasonable option.
I was surprised when I saw the solution for records. Maybe we should
consider something like that as a last resort (if it's possible for
non-record types)? I'd rather give up typmod than anyrange.
It also might be worth figuring out why input functions get the type oid
and output functions do not. I see this comment above getTypeIOParam():
* As of PostgreSQL 8.1, output functions receive only the value
itself * and not any auxiliary parameters, so the
nameof this routine is
now * a bit of a misnomer ... it should be
getTypeInputParam.
So, why was it eliminated? If the type output function got the type OID,
would it be enough to use fn_expr_get_argtype() for the other generic
functions?
Regards,Jeff Davis
