"Jeff Davis" <pgsql@j-davis.com> writes:
> * Binary formatting
>
> The exclusive use of binary formats is worrisome to me. This circumvents
> one level of indirection that we have (i.e. that everything moves
> through in/out functions), and will impose a backwards-compatibility
> requirement on the internal representation of data types, including
> user-defined data types. As far as I know, we currently have no such
> requirement, even for built-in types.
This is actually incorrect. Binary I/O still goes through a function call, the
send/recv functions instead of the in/out functions. In theory these are also
supposed to be cross-platform.
In practice they are, uhm, less cross-platform. For example they send floats
as raw (presumably) IEEE floats. There have also been fewer clients using
binary mode, so you're more likely to run into bugs.
But the reason fewer clients use binary mode is because they would have to
implement all this type-specific knowledge. It doesn't make sense to do it for
every driver or application but if you're implementing it once in a library it
does start to make more sense.
Note however that not every data type will necessarily provide a binary
send/recv function. The built-in data types do, but only as a matter of
policy. It's not an error to create a type with no binary i/o functions.
So I think you have to support using text mode as an option.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!