Re: plperl vs. bytea

Added to TODO:
               o Allow data to be passed in native language formats, rather                 than only text
                http://archives.postgresql.org/pgsql-hackers/2007-05/msg00289$


---------------------------------------------------------------------------

Andrew Dunstan wrote:
> 
> 
> Tom Lane wrote:
> > Andrew Dunstan <andrew@dunslane.net> writes:
> >   
> >> Tino Wildenhain wrote:
> >>     
> >>> Andrew Dunstan schrieb:
> >>>       
> >>>> This does not need to be over-engineered, IMNSHO.
> >>>>         
> >>> Well could you explain where it would appear over-engineered?
> >>>       
> >
> >   
> >> Anything that imposes extra requirements on type creators seems undesirable.
> >>     
> >
> >   
> >> I'm not sure either that the UUID example is a very good one. This whole 
> >> problem arose because of performance problems handling large gobs of 
> >> data, not just anything that happens to be binary.
> >>     
> >
> > Well, we realize that bytea has got a performance problem, but are we so
> > sure that nothing else does?  I don't want to stick in a one-purpose
> > wart only to find later that we need a few more warts of the same kind.
> >
> > An example of something else we ought to be considering is binary
> > transmission of float values.  The argument in favor of that is not
> > so much performance (although text-and-back conversion is hardly cheap)
> > as it is that the conversion is potentially lossy, since float8out
> > doesn't by default generate enough digits to ensure a unique
> > back-conversion.
> >
> > ISTM there are three reasons for considering non-text-based
> > transmission:
> >
> > 1. Performance, as in the bytea case
> > 2. Avoidance of information loss, as for float
> > 3. Providing a natural/convenient mapping to the PL's internal data types,
> >    as we already do --- but incompletely --- for arrays and records
> >
> > It's clear that the details of #3 have to vary across PLs, but I'd
> > like it not to vary capriciously.  For instance plperl currently has
> > special treatment for returning perl arrays as SQL arrays, but AFAICS
> > from the manual not for going in the other direction; plpython and
> > pltcl overlook arrays entirely, even though there are natural mappings
> > they could and should be using.
> >
> > I don't know to what extent we should apply point #3 to situations other
> > than arrays and records, but now is the time to think about it.  An
> > example: working with the geometric types in a PL function is probably
> > going to be pretty painful for lack of simple access to the constituent
> > float values (not to mention the lossiness problem).
> >
> > We should also be considering some non-core PLs such as PL/Ruby and
> > PL/R; they might provide additional examples to influence our thinking.
> >   
> 
> OK, we have a lot of work to do here, then.
> 
> I can really only speak with any significant knowledge on the perl 
> front. Fundamentally, it has 3 types of scalars: IV, NV and PV (integer, 
> float, string). IV can accomodate at least the largest integer or 
> pointer type on the platform, NV a double, and PV an arbitrary string of 
> bytes.
> 
> As for structured types, as I noted elsewhere we have some of the work 
> done for plperl. My suggestion would be to complete it for plperl and 
> get it fully orthogonal and then retrofit that to plpython/pltcl.
> 
> I've actually been worried for some time that the conversion glue was 
> probably imposing significant penalties on the non-native PLs, so I'm 
> glad to see this getting some attention.
> 
> 
> cheers
> 
> andrew
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo@postgresql.org so that your
>        message can get through to the mailing list cleanly

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +