On Tue, Sep 23, 2014 at 4:59 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Sep 18, 2014 at 11:21 AM, Michael Paquier > <michael.paqu...@gmail.com> wrote: >> On Thu, Sep 18, 2014 at 9:56 AM, Andres Freund <and...@2ndquadrant.com> >> wrote: >>> On 2014-09-18 09:50:38 -0500, Michael Paquier wrote: >>>> > Do you see the difference between what your doc patch states and the >>>> > explanation I've given nearby in this thread? >>>> Perhaps that's the lack of documentation... >>> >>> Man. I've explained it to you about three times. The previous attempts >>> at doing so didn't seem to help. If my explanations don't explain it so >>> you can understand it adding them to the docs won't change a thing. >>> That's why I ask whether you see the difference? >> Urg sorry for the misunderstanding. The patch stated that this >> parameter only influences the output of the SQL functions while it >> defines if "the output plugin requires the output method to support >> binary data"? > > I'm not sure exactly what that sentence means. > > But here's the point: every series of bytes is a valid bytea, except > maybe if it's over 1GB and runs afould of MaxAllocSize. But a series > of bytes is only a valid text datum if it's a valid sequence of > characters according to the database encoding. We like to think of > text as being an arbitrary series of bytes, but it isn't. It can't > contain any \0 bytes, and it can't contain anything that's invalid in > the database encoding. bytea isn't subject to either of those > restrictions. > > So if we were going to have one universal output format for output > plugins, it would have to be bytea because that, really, can be > anything. We could make users convert from that to text or whatever > they like. But that's unappealing for several reasons: bytea output > is printed as unreadable hexademical garbage, and encoding conversions > are expensive. So what we do instead is provide a text output method > and a binary output method. That way, plugins that want to return > binary data are free to do so, and output methods that are happy to > return text can *declare* that what they return is legal text - and > then we just assume that to be true, and need not do an encoding > conversion. Aha, thanks. That's all clear then! -- Michael
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
