Thread: Re: [COMMITTERS] pgsql: Fix up text concatenation so that it accepts all the reasonable

"Tom Lane" <tgl@postgresql.org> writes:

> Log Message:
> -----------
> Fix up text concatenation so that it accepts all the reasonable cases that
> were accepted by prior Postgres releases.  This takes care of the loose end
> left by the preceding patch to downgrade implicit casts-to-text.  To avoid
> breaking desirable behavior for array concatenation, introduce a new
> polymorphic pseudo-type "anynonarray" --- the added concatenation operators
> are actually text || anynonarray and anynonarray || text.

Just a crazy thought -- probably not worth doing now or perhaps ever -- but I
thought I would get it down in bits:

The above change eliminated cast functions to and from text by using the text
i/o functions. We could do the same for casts to and from bytea using binary
i/o functions.

I'm not sure how important it is for users to be able to reliably store any
data type in a bytea -- certainly not as important as being able to reliably
cast to and from text. 

Perhaps if you're doing some form of replication between different
architectures you might want to use binary representation for your transfers.
Or if you're doing something in a PL language like compressing or bundling up
multiple data in a container format or something.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com

Hi,

Gregory Stark wrote:
> Perhaps if you're doing some form of replication between different
> architectures you might want to use binary representation for your transfers.
> Or if you're doing something in a PL language like compressing or bundling up
> multiple data in a container format or something.

I'm not quite sure I understand where you're coming from, but isn't that 
what the send and recv functions for most data types are for? Don't 
those provide a cross-platform compatible binary representation?

Regards

Markus

Markus Schiltknecht <markus@bluegap.ch> writes:
> Gregory Stark wrote:
>> Perhaps if you're doing some form of replication between different
>> architectures you might want to use binary representation for your transfers.
>> Or if you're doing something in a PL language like compressing or bundling up
>> multiple data in a container format or something.

> I'm not quite sure I understand where you're coming from, but isn't that 
> what the send and recv functions for most data types are for? Don't 
> those provide a cross-platform compatible binary representation?

I think you'd be nuts to bet your data on the binary representations
really being cross-platform compatible.  There might be some excuse for
doing this within a single architecture, but I can't get very excited
about it ...
        regards, tom lane

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> I think you'd be nuts to bet your data on the binary representations
> really being cross-platform compatible.  There might be some excuse for
> doing this within a single architecture, but I can't get very excited
> about it ...

Well they're not very useful for their intended purpose of client-server
communication if they're not.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com

Hello Tom,

Tom Lane wrote:
> I think you'd be nuts to bet your data on the binary representations
> really being cross-platform compatible.

Can you elaborate on this? AFAICT the send/recv functions use network 
byte ordering. What are the other problems between different architectures?

> There might be some excuse for
> doing this within a single architecture, but I can't get very excited
> about it ...

Is the textual representation (i.e. OidOutputFunctionCall) more cross 
platform compatible?

Gregory Stark wrote:> Well they're not very useful for their intended purpose of> client-server communication if
they'renot.
 

Agreed. Up until now, I'd have considered it a bug, if a send/recv on 
different platforms would not lead to the very same result.

Regards

Markus

Markus Schiltknecht <markus@bluegap.ch> writes:
> Tom Lane wrote:
>> I think you'd be nuts to bet your data on the binary representations
>> really being cross-platform compatible.

> Can you elaborate on this? AFAICT the send/recv functions use network 
> byte ordering. What are the other problems between different architectures?

Well, you're probably fine with integers and text, but beyond that it
gets a bit more dicey.  I wouldn't want to assume that floats are
compatible across any random pair of architectures, and in the more
complex datatypes (such as arrays or geometric types) there might be
some impact from alignment rules.  (Or not, I'm too lazy to go look at
the moment.)

In any one situation you can doubtless find out by testing whether
you've got a problem.  I'm just nervous about a blithe suggestion that
someone could build a cross-platform backup solution this way.  That
sounds like a recipe for getting burnt and not finding out till it's
too late to fix it.
        regards, tom lane

Hi,

Tom Lane wrote:
> Well, you're probably fine with integers and text, but beyond that it
> gets a bit more dicey.  I wouldn't want to assume that floats are
> compatible across any random pair of architectures, and in the more
> complex datatypes (such as arrays or geometric types) there might be
> some impact from alignment rules.  (Or not, I'm too lazy to go look at
> the moment.)

Okay, thank you for the hints, I'll go figure out.

Regards

Markus