Tom Lane wrote:
My GUC proposal would have made it language+type specific, but Tom
didn't like that approach.
It may indeed need to be language+type specific; what I was objecting to
was the proposal of an ad-hoc plperl-specific solution without any
consideration for other languages (or other data types for that matter).
I think that's working at the wrong level of detail, at least for
initial design.
What we've basically got here is a complaint that the default
textual-representation-based method for transmitting PL function
parameters and results is awkward and inefficient for bytea.
So the first question is whether this is really localized to only
bytea, and if not which other types have got similar issues.
(Even if you make the case that no other scalar types need help,
what of bytea[] and composite types containing bytea or bytea[]?)
Well, the proposal would have allowed the user to specify the types to
be passed binary, so it wouldn't have been bytea only.
Array types are currently passed as text. This item used to be on the
TODO list but it disappeared at some stage:
. Pass arrays natively instead of as text between plperl and postgres
(Perhaps it's naughty of me to observe that if we had a tracker we might
know why it disappeared). Arrays can be returned as arrayrefs, and
plperl has a little postprocessing magic that turns that into text which
will in turn be parsed back into a postgres array. Not very efficient
but it's a placeholder until we get better array support.
Composites are in fact passed as hashrefs and can be returned as
hashrefs. Unfortunately, this is not true recursively - a composite
within a composite will be received as text.
Another aspect of this is how we deal with SPI arguments and results. I
need to look into that, but sufficient unto the day ...
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
