Sean Davis <sdavis2@mail.nih.gov> writes:
> Thanks for the reply. Just for fun, I did create the function in
> pl/perlu without difficulty. However, I can't call it, as record types
> do not seem to match any prototyping....
I don't think plperl has a validator function, so it's not going to
complain at CREATE FUNCTION time, but it definitely barfs at runtime:
/* Disallow pseudotype argument */
if (typeStruct->typtype == 'p')
{
free(prodesc->proname);
free(prodesc);
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("plperl functions cannot take type %s",
format_type_be(procStruct->proargtypes[i]))));
}
The point about what input will be considered to match type-wise is
another good one that I hadn't thought about. Looking at the source
code, it appears that 8.0 will consider an explicit ROW(...) construct
to match a RECORD argument, but not a named composite type (e.g.,
a row coming from a table) :-(. This is probably an oversight stemming
from the fact that no one's ever exercised the case.
I don't have plperl installed on this machine, but pltcl behaves about
the same:
regression=# create function f1(record) returns int as $$return 1$$ language pltcl;
CREATE FUNCTION
regression=# select f1(row(33,44));
ERROR: pltcl functions cannot take type record
regression=# select f1(i.*) from int8_tbl i;
ERROR: function f1(int8_tbl) does not exist
The first select is actually a "success", since control is getting as
far as letting pltcl decide it won't do it.
plpgsql probably isn't ever going to allow RECORD arguments, since it
likes to work with known types, but in principle I think the other PLs
could handle the case. They all are willing to take named composite
types and this doesn't seem much different for their purposes.
regards, tom lane