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



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?


Reply via email to