Re: have you feel anything when you read this ?

On Thu, 6 Apr 2006, Eugene E. wrote:

> 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 ???

I didn't answer this because I didn't feel that it moved the argument
forward, but...

If you meant that you must retrieve them in a separate query, you're
incorrect, since you *could* use the binary form for the others. I can't
understand if you don't realize that there is one for all these various
types, or that you just don't wish to use it (for example, I believe using
%d on ntohl(value from pqgetvalue) or something similar will print your
integer).

If you are arguing that you don't *wish* to do use that binary form for
the other values, I don't see how that's relevant until you've proven the
rest of the argument (*).

> 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]

Okay, now pass that to strcmp or a %s format. AFAIK, the "textual-form" of
values is meant to be a c-string. "ab\0cd\0" is not a c-string containing
ab\0cd, it's a c-string containing ab.

> > 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.

I don't think that it's appreciably more special.

> 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.

There are two representations of (at least most) types. There's a binary
format and a textual format.

> (They call those representations "textual-form".)

I think I don't exactly agree with this description, but I'm unclear
exactly what you're saying. Are you saying that textual-form is the
useful representation, or are you saying that textual-form is the
representation and it is useful?

> 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.

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.

In addition, input could be binary and output textual or the other way
around, in some_data is different on both sides. There's no reason that
you can't be passing an integer that way.

> I expect a value of BYTEA to be unchaged too.

I think (as above) that your perception of the problem isn't correct.

> > 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) ?

It's not always. It can be, just as bytea can be passed as a string
needing escaping, however it can be passed as effectively a binary blob
containing an integer value (in network order I believe) just as bytea can
be passed as a binary blob.

> why not to define your own unique more_sofisticated representation ?
> (as for bytea is defined.)

AFAICS, there is one, the binary format for integer.

> 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.

I think this is mostly answered by the above with a little bit of
connecting the dots.

> P.S.
> changing a format of a whole result-set is not a solution for a
> field-type-dependent problem.

Since we're still arguing about whether it's a field-type-dependent
problem or a field-use-dependent problem, I can't really argue this point
since it assumes the former and I don't believe that's been shown yet.

(*) Yes, it might be nice to have something that did it for you. Having
one is not, in my mind, a requirement for the API but instead something to
make it easier.