Praescriptum:
If my english is ugly and something is written unclear, please
complaint, and i'll try to rephrase.
anyway i am trying to be understood.
I said
>> WHY SHOULD I RETRIVE A SINGLE BYTEA FIELD IN A SEPARATE QUERY ???
Stephan Szabo wrote:
> What would you expect it to do given a single result format argument?
>
> If you want to propose a new function (set of functions) that have
> different behavior, make a coherent proposal.> Statements like it should> do X because I want it to aren't coherent
proposals.
AFAIK, they convert each value before put it to a result set.
I propose to do the following convertion to the textual-form for bytea
values:
X->X where X is byte [0..255]
> Expect to get asked
> why bytea is special
_Because each type is special._
And at the same time they made bytea MORE special than any other type.
Look:
every type has many representations for its values, some are obvious
some are more usefull, some are less useful.
they define very useful and obvious representations for all the types
but BYTEA.
(They call those representations "textual-form".)
and the input of a value demands escaping (we all undersdand why)
and for each type the following equality is TRUE:
some_data == OUTPUT(INPUT(ESCAPE(some_data)))
but for the BYTEA this equality is FALSE !
Why BYTEA is so special ?
every value of every type is expected to be given to a client UNCHANGED.
I expect a value of BYTEA to be unchaged too.
> why should integer be passed as a string given
because it is not causing problems, as well as if it be passed in any
other common form.
And i ask you:
why integer is actually passed as a string (decimal notation) ?
why not to define your own unique more_sofisticated representation ?
(as for bytea is defined.)
And finally
Why so special textual-form defined for bytea ?
Why not to leave every byte unchanged, since user knows what kind of
data he got.
P.S.
changing a format of a whole result-set is not a solution for a
field-type-dependent problem.