Hi, Stephan & Eugene,
Stephan Szabo wrote:
> This is already false AFAICS. Leading or trailing spaces on a string
> containing integer get trimmed during the input for example, the string
> format of date comes back in a particular but other input formats are
> supported. I don't think the above equality is valid for textual
> representation.
It is even true that the server-internal storage format can be distinct
from both the textual and binary representation (aka canonical rep.).
This is e. G. how PostGIS handles their geometries. PostGIS geometries
have even more representations, available via conversion functions.
And for some unicode strings, it even happens that their textual
representation is different depending on the client encoding.
>>I expect a value of BYTEA to be unchaged too.
> I think (as above) that your perception of the problem isn't correct.
I agree. The value of the BYTEA is unchanged, it is just a different
representation of the BYTEA that allows handling its contents as text,
in non-binary safe environments.
Imagine having the text representation as simply HEXing the BYTEA
contents - it still is an unchanged value.
>>why not to define your own unique more_sofisticated representation ?
>>(as for bytea is defined.)
> AFAICS, there is one, the binary format for integer.
Exactly.
AFAICS, all built-in data types have both a text and binary
representation, as well as most extension types.
HTH,
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS
Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org
