In a followup to an earlier question from today from another person, is
it possible to create and use a function that takes as input a generic
"record"? Specifically, how would I use a function like:

create or replace function perl_columns(record) returns text as $a$
my ($rec)=@_;
my $xml_ex = '';
foreach my $tag (keys %$rec) {
$xml_ex = "<$tag>" . $rec->{$tag} . "</$tag>\n";
}
return $xml_ex;
$a$ language plperlu;

Thanks,
Sean


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Sean Davis <sdavis2@mail.nih.gov> writes:
> In a followup to an earlier question from today from another person, is
> it possible to create and use a function that takes as input a generic
> "record"?

Not in any of the PL languages. I think you could do it in C.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Tom,

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....

Sean

On Feb 22, 2005, at 10:20 AM, Tom Lane wrote:

> Sean Davis <sdavis2@mail.nih.gov> writes:
>> In a followup to an earlier question from today from another person,
>> is
>> it possible to create and use a function that takes as input a generic
>> "record"?
>
> Not in any of the PL languages. I think you could do it in C.
>
> regards, tom lane


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

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

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

On Feb 22, 2005, at 11:03 AM, Tom Lane wrote:

> 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.

Tom,

As usual, thanks for the enlightenment. Allowing generic record types
seems quite intuitive to a perl programmer and since perl is a very
"untyped" language, it seems quite practicable to allow? Of course, I
don't have the knowledge to "make it so".... It does seem that for
some applications, allowing pls other than pgsql to get access to
whatever is passed (a generic record type) would be a useful extension.

Sean


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend