pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedhave you feel anything when you read this ?
47+ messages / 12 participants
[nested] [flat]
* have you feel anything when you read this ?
@ 2006-03-20 08:06 Eugene E. <sad@bankir.ru>
0 siblings, 2 replies; 47+ messages in thread
From: Eugene E. @ 2006-03-20 08:06 UTC (permalink / raw)
To: pgsql-sql
http://dev.mysql.com/doc/refman/5.0/en/news-5-0-19.html
--- cut ---
mysql no longer terminates data value display when it encounters a NUL
byte. Instead, it displays NUL bytes as spaces. (Bug #16859)
--- cut ---
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 08:27 PFC <lists@peufeu.com>
parent: Eugene E. <sad@bankir.ru>
1 sibling, 1 reply; 47+ messages in thread
From: PFC @ 2006-03-20 08:27 UTC (permalink / raw)
To: Eugene E. <sad@bankir.ru>; pgsql-sql
> have you feel anything when you read this ?
Business as usual...
It's more fun to grep "crash" on this page, which gets about 27 results...
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 08:29 Eugene E. <sad@bankir.ru>
parent: PFC <lists@peufeu.com>
0 siblings, 1 reply; 47+ messages in thread
From: Eugene E. @ 2006-03-20 08:29 UTC (permalink / raw)
To: PFC <lists@peufeu.com>; +Cc: pgsql-sql
PFC wrote:
>
>> have you feel anything when you read this ?
>
>
> Business as usual...
>
> It's more fun to grep "crash" on this page, which gets about 27
> results...
i am not trying to fight against or for any brandname: not Mesql nor
postgres.
just sed 's/MySQL/SomeDBMS/g' and concentrate on the fact:
that even so stupid DBMS handling NULs properly. :-)
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 08:50 Peter Eisentraut <peter_e@gmx.net>
parent: Eugene E. <sad@bankir.ru>
0 siblings, 1 reply; 47+ messages in thread
From: Peter Eisentraut @ 2006-03-20 08:50 UTC (permalink / raw)
To: pgsql-sql; +Cc: Eugene E. <sad@bankir.ru>; PFC <lists@peufeu.com>
Eugene E. wrote:
> PFC wrote:
> >> have you feel anything when you read this ?
> >
> > Business as usual...
> >
> > It's more fun to grep "crash" on this page, which gets about 27
> > results...
>
> i am not trying to fight against or for any brandname: not Mesql nor
> postgres.
>
> just sed 's/MySQL/SomeDBMS/g' and concentrate on the fact:
> that even so stupid DBMS handling NULs properly. :-)
So printing a space is "properly"? Curious ...
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 08:57 Eugene E. <sad@bankir.ru>
parent: Peter Eisentraut <peter_e@gmx.net>
0 siblings, 1 reply; 47+ messages in thread
From: Eugene E. @ 2006-03-20 08:57 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: pgsql-sql@postgresql.org, PFC <lists@peufeu.com>
Peter Eisentraut wrote:
> Eugene E. wrote:
>
>>PFC wrote:
>>
>>>>have you feel anything when you read this ?
>>>
>>> Business as usual...
>>>
>>> It's more fun to grep "crash" on this page, which gets about 27
>>>results...
>>
>>i am not trying to fight against or for any brandname: not Mesql nor
>>postgres.
>>
>>just sed 's/MySQL/SomeDBMS/g' and concentrate on the fact:
>>that even so stupid DBMS handling NULs properly. :-)
>
>
> So printing a space is "properly"? Curious ...
>
you may decide to print something else, aint'you ?
BUT
if they print them then they at least OUTPUT them.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 10:47 Peter Eisentraut <peter_e@gmx.net>
parent: Eugene E. <sad@bankir.ru>
0 siblings, 1 reply; 47+ messages in thread
From: Peter Eisentraut @ 2006-03-20 10:47 UTC (permalink / raw)
To: Eugene E. <sad@bankir.ru>; +Cc: pgsql-sql@postgresql.org, PFC <lists@peufeu.com>
Eugene E. wrote:
> you may decide to print something else, aint'you ?
> BUT
> if they print them then they at least OUTPUT them.
I'm not sure what you are getting at here. The only data type in
PostgreSQL that has a notion of null bytes is bytea, and bytea prints
out null bytes in unambigious form. Note that printing out a space
will lose the null byte on restore, so that solution does not seem
satisfactory.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 10:59 Eugene E. <sad@bankir.ru>
parent: Peter Eisentraut <peter_e@gmx.net>
0 siblings, 1 reply; 47+ messages in thread
From: Eugene E. @ 2006-03-20 10:59 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: pgsql-sql@postgresql.org, PFC <lists@peufeu.com>
Peter Eisentraut wrote:
> Eugene E. wrote:
>
>>you may decide to print something else, aint'you ?
>>BUT
>>if they print them then they at least OUTPUT them.
>
>
> I'm not sure what you are getting at here. The only data type in
> PostgreSQL that has a notion of null bytes is bytea, and bytea prints
> out null bytes in unambigious form.
the bytea does not output NULs at all.
don't mock me.
> Note that printing out a space
> will lose the null byte on restore,
ok, if you or they or me miscall OUTPUT "the printing"
then "print" NUL-byte itself to preserve it on restore.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 11:51 Peter Eisentraut <peter_e@gmx.net>
parent: Eugene E. <sad@bankir.ru>
0 siblings, 2 replies; 47+ messages in thread
From: Peter Eisentraut @ 2006-03-20 11:51 UTC (permalink / raw)
To: Eugene E. <sad@bankir.ru>; +Cc: pgsql-sql
Eugene E. wrote:
> the bytea does not output NULs at all.
> don't mock me.
peter=# create table test (a bytea);
CREATE TABLE
peter=# insert into test values ('a\\000b');
INSERT 0 1
peter=# select * from test;
a
--------
a\000b
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 12:07 Eugene E. <sad@bankir.ru>
parent: Peter Eisentraut <peter_e@gmx.net>
1 sibling, 1 reply; 47+ messages in thread
From: Eugene E. @ 2006-03-20 12:07 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: pgsql-sql
Peter Eisentraut wrote:
> Eugene E. wrote:
>
>>the bytea does not output NULs at all.
>>don't mock me.
>
>
> peter=# create table test (a bytea);
> CREATE TABLE
> peter=# insert into test values ('a\\000b');
> INSERT 0 1
> peter=# select * from test;
> a
> --------
> a\000b
are you kidding ?
where is NUL-byte in "a\000b" ???
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 12:13 Alvaro Herrera <alvherre@commandprompt.com>
parent: Achilleus Mantzios <achill@matrix.gatewaynet.com>
0 siblings, 3 replies; 47+ messages in thread
From: Alvaro Herrera @ 2006-03-20 12:13 UTC (permalink / raw)
To: Achilleus Mantzios <achill@matrix.gatewaynet.com>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Eugene E. <sad@bankir.ru>; pgsql-sql
Achilleus Mantzios wrote:
> dynacom=# SELECT '\000\150\145\154\154\157'::text;
> text
> ------
>
> (1 row)
>
> dynacom=#
>
> Oops!
text is not bytea.
alvherre=# SELECT $$\000\150\145\154\154\157$$::bytea;
bytea
-----------
\000hello
(1 fila)
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 12:18 Alvaro Herrera <alvherre@commandprompt.com>
parent: Achilleus Mantzios <achill@matrix.gatewaynet.com>
0 siblings, 0 replies; 47+ messages in thread
From: Alvaro Herrera @ 2006-03-20 12:18 UTC (permalink / raw)
To: Achilleus Mantzios <achill@matrix.gatewaynet.com>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Eugene E. <sad@bankir.ru>; pgsql-sql
Achilleus Mantzios wrote:
> O Alvaro Herrera ?????? ???? Mar 20, 2006 :
>
> > text is not bytea.
> >
> > alvherre=# SELECT $$\000\150\145\154\154\157$$::bytea;
> > bytea
> > -----------
> > \000hello
> > (1 fila)
>
> Sure, but we are trying to reproduce the mysql phaenomenon right? :)
I don't really know what we are doing in this thread. This Eugene E.
seems to be only trolling and the rest of us are feeding him.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 12:19 Eugene E. <sad@bankir.ru>
parent: Alvaro Herrera <alvherre@commandprompt.com>
2 siblings, 1 reply; 47+ messages in thread
From: Eugene E. @ 2006-03-20 12:19 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@commandprompt.com>; +Cc: Achilleus Mantzios <achill@matrix.gatewaynet.com>; Peter Eisentraut <peter_e@gmx.net>; pgsql-sql
Alvaro Herrera wrote:
> Achilleus Mantzios wrote:
>
>
>>dynacom=# SELECT '\000\150\145\154\154\157'::text;
>> text
>>------
>>
>>(1 row)
>>
>>dynacom=#
>>
>>Oops!
>
>
> text is not bytea.
source says:
typedef text varlena;
typedef bytea varlena;
:-)
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 12:27 Alvaro Herrera <alvherre@commandprompt.com>
parent: Eugene E. <sad@bankir.ru>
0 siblings, 1 reply; 47+ messages in thread
From: Alvaro Herrera @ 2006-03-20 12:27 UTC (permalink / raw)
To: Eugene E. <sad@bankir.ru>; +Cc: Achilleus Mantzios <achill@matrix.gatewaynet.com>; Peter Eisentraut <peter_e@gmx.net>; pgsql-sql
Eugene E. wrote:
> Alvaro Herrera wrote:
> >text is not bytea.
>
> source says:
>
> typedef text varlena;
> typedef bytea varlena;
This means that as far as the C type system is concerned, both bytea and
text are treated as "struct varlena". It doesn't mean that they are
processed by the same input/output functions, which they aren't.
NUL bytes are preserved in bytea, and used as terminators in text. I
don't find this surprising at all, do you?
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 12:31 Eugene E. <sad@bankir.ru>
parent: Achilleus Mantzios <achill@matrix.gatewaynet.com>
0 siblings, 2 replies; 47+ messages in thread
From: Eugene E. @ 2006-03-20 12:31 UTC (permalink / raw)
To: Achilleus Mantzios <achill@matrix.gatewaynet.com>; +Cc: Peter Eisentraut <peter_e@gmx.net>; pgsql-sql
Achilleus Mantzios wrote:
>>> a
>>>--------
>>> a\000b
>>
>>are you kidding ?
>>where is NUL-byte in "a\000b" ???
>
>
> Null byte is a byte of value zero,
> and allow me to say that the \000 in "a\000b" is exactly this.
if ("\0"=="\\000")
printf("congratulations!!!");
NOTE:
I am not care about a _display_ NUL-byte on a screen !
weither it'll be "space" or "some escape sequence"
the problem is: you'll get this four byte sequence '\000' _instead_ of
NUL-byte anyway.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 12:44 Eugene E. <sad@bankir.ru>
parent: Alvaro Herrera <alvherre@commandprompt.com>
0 siblings, 1 reply; 47+ messages in thread
From: Eugene E. @ 2006-03-20 12:44 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@commandprompt.com>; +Cc: Achilleus Mantzios <achill@matrix.gatewaynet.com>; Peter Eisentraut <peter_e@gmx.net>; pgsql-sql
Alvaro Herrera wrote:
> Eugene E. wrote:
>
>>Alvaro Herrera wrote:
>
>
>>>text is not bytea.
>>
>>source says:
>>
>>typedef text varlena;
>>typedef bytea varlena;
>
>
> This means that as far as the C type system is concerned, both bytea and
> text are treated as "struct varlena". It doesn't mean that they are
> processed by the same input/output functions, which they aren't.
>
> NUL bytes are preserved in bytea, and used as terminators in text. I
> don't find this surprising at all, do you?
I do found surprising it.
since both (text and bytea) I/O functions has CSTRING arguments and
resut type. - this only means a user should perform some unescaping on
the bytea value he got. THE SAME THING he should do with a string value
if he decide to use type text and to escape NUL-bytes before input.
then what a difference bitween those types except strlen() ?
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 13:06 Achilleus Mantzios <achill@matrix.gatewaynet.com>
parent: Peter Eisentraut <peter_e@gmx.net>
1 sibling, 1 reply; 47+ messages in thread
From: Achilleus Mantzios @ 2006-03-20 13:06 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: Eugene E. <sad@bankir.ru>; pgsql-sql
O Peter Eisentraut Ýãñáøå óôéò Mar 20, 2006 :
> Eugene E. wrote:
> > the bytea does not output NULs at all.
> > don't mock me.
>
> peter=# create table test (a bytea);
> CREATE TABLE
> peter=# insert into test values ('a\\000b');
> INSERT 0 1
> peter=# select * from test;
> a
> --------
> a\000b
Just did
dynacom=# SELECT '\150\145\154\154\157'::text;
text
-------
hello
(1 row)
dynacom=#
dynacom=#
dynacom=# SELECT '\000\150\145\154\154\157'::text;
text
------
(1 row)
dynacom=#
Oops!
>
>
--
-Achilleus
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 13:15 Peter Eisentraut <peter_e@gmx.net>
parent: Eugene E. <sad@bankir.ru>
1 sibling, 1 reply; 47+ messages in thread
From: Peter Eisentraut @ 2006-03-20 13:15 UTC (permalink / raw)
To: Eugene E. <sad@bankir.ru>; +Cc: Achilleus Mantzios <achill@matrix.gatewaynet.com>; pgsql-sql
Eugene E. wrote:
> the problem is: you'll get this four byte sequence '\000' _instead_
> of NUL-byte anyway.
What you seem to be missing is that PostgreSQL data can be represented
in textual and in binary form. What you in psql is the textual form.
If you want the binary form you need to select it. Then you can pass
the exact bytes back and forth.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 13:16 Peter Eisentraut <peter_e@gmx.net>
parent: Eugene E. <sad@bankir.ru>
0 siblings, 0 replies; 47+ messages in thread
From: Peter Eisentraut @ 2006-03-20 13:16 UTC (permalink / raw)
To: Eugene E. <sad@bankir.ru>; +Cc: Alvaro Herrera <alvherre@commandprompt.com>; Achilleus Mantzios <achill@matrix.gatewaynet.com>; pgsql-sql
Eugene E. wrote:
> input. then what a difference bitween those types except strlen() ?
bytea does not consider character set encodings and locales, and it
handles null bytes.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 13:21 Achilleus Mantzios <achill@matrix.gatewaynet.com>
parent: Alvaro Herrera <alvherre@commandprompt.com>
2 siblings, 1 reply; 47+ messages in thread
From: Achilleus Mantzios @ 2006-03-20 13:21 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@commandprompt.com>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Eugene E. <sad@bankir.ru>; pgsql-sql
O Alvaro Herrera Ýãñáøå óôéò Mar 20, 2006 :
> Achilleus Mantzios wrote:
>
> > dynacom=# SELECT '\000\150\145\154\154\157'::text;
> > text
> > ------
> >
> > (1 row)
> >
> > dynacom=#
> >
> > Oops!
>
> text is not bytea.
>
> alvherre=# SELECT $$\000\150\145\154\154\157$$::bytea;
> bytea
> -----------
> \000hello
> (1 fila)
Sure, but we are trying to reproduce the mysql phaenomenon right? :)
>
>
--
-Achilleus
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 13:26 Achilleus Mantzios <achill@matrix.gatewaynet.com>
parent: Eugene E. <sad@bankir.ru>
0 siblings, 1 reply; 47+ messages in thread
From: Achilleus Mantzios @ 2006-03-20 13:26 UTC (permalink / raw)
To: Eugene E. <sad@bankir.ru>; +Cc: Peter Eisentraut <peter_e@gmx.net>; pgsql-sql
O Eugene E. Ýãñáøå óôéò Mar 20, 2006 :
> Peter Eisentraut wrote:
> > Eugene E. wrote:
> >
> >>the bytea does not output NULs at all.
> >>don't mock me.
> >
> >
> > peter=# create table test (a bytea);
> > CREATE TABLE
> > peter=# insert into test values ('a\\000b');
> > INSERT 0 1
> > peter=# select * from test;
> > a
> > --------
> > a\000b
>
> are you kidding ?
> where is NUL-byte in "a\000b" ???
Null byte is a byte of value zero,
and allow me to say that the \000 in "a\000b" is exactly this.
A NULL value is commonly used in C to terminate a pointer's data.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
--
-Achilleus
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 14:19 PFC <lists@peufeu.com>
parent: Eugene E. <sad@bankir.ru>
1 sibling, 1 reply; 47+ messages in thread
From: PFC @ 2006-03-20 14:19 UTC (permalink / raw)
To: Eugene E. <sad@bankir.ru>; Achilleus Mantzios <achill@matrix.gatewaynet.com>; +Cc: Peter Eisentraut <peter_e@gmx.net>; pgsql-sql
> the problem is: you'll get this four byte sequence '\000' _instead_ of
> NUL-byte anyway.
http://www.postgresql.org/docs/8.1/interactive/datatype-binary.html says :
"A binary string is a sequence of octets (or bytes). Binary strings are
distinguished from character strings by two characteristics: First, binary
strings specifically allow storing octets of value zero and other
"non-printable" octets (usually, octets outside the range 32 to 126).
Character strings disallow zero octets, and also disallow any other octet
values and sequences of octet values that are invalid according to the
database's selected character set encoding. Second, operations on binary
strings process the actual bytes, whereas the processing of character
strings depends on locale settings. In short, binary strings are
appropriate for storing data that the programmer thinks of as "raw bytes",
whereas character strings are appropriate for storing text."
That's the whole point of escaping, so that data generated by COPY, for
instance, does not include any funky characters, including the \0 (zero)
character, so that you can use any standard tool on it, including grep...
I LIKE the fact that TEXT refuses invalid characters. It helps find bugs
in my applications, like when I forget to process some 8-bit string before
inserting it in my database which uses UNICODE. I definitely prefer an
error than finding a month later that half my data has had all its
accented characters screwed up.
in psql, you have to use the escaped syntax :
SELECT length('\\000'::BYTEA), length('\\001'::BYTEA),
length('\\000'::TEXT), length('\\001'::TEXT);
length | length | length | length
--------+--------+--------+--------
1 | 1 | 4 | 4
Your client library should take care of escaping and de-escaping. Here, in
python :
>>> cursor.execute( "SELECT %s,%s::BYTEA", ("this is a normal string",
>>> psycopg2.Binary( ">\x00< this is a string with a zero byte" ),) )
>>> r = cursor.fetchone()
>>> print r
['this is a normal string', <read-only buffer for 0x2aaaaab32210, size 37,
offset 0 at 0x2aaaace27c70>]
>>> print str(r[1])
> < this is a string with a zero byte
>>> print repr(str(r[1]))
'>\x00< this is a string with a zero byte'
>>> ord(r[1][1])
0
Note : \x00 is python's escaping for the null byte
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 14:53 Eugene E. <sad@bankir.ru>
parent: PFC <lists@peufeu.com>
0 siblings, 2 replies; 47+ messages in thread
From: Eugene E. @ 2006-03-20 14:53 UTC (permalink / raw)
To: PFC <lists@peufeu.com>; +Cc: Achilleus Mantzios <achill@matrix.gatewaynet.com>; Peter Eisentraut <peter_e@gmx.net>; pgsql-sql
I wrote:
>> the problem is: you'll get this four byte sequence '\000' _instead_
>> of NUL-byte anyway.
You wrote:
> Your client library should take care of escaping and de-escaping.
We both agree as you see.
Then i am asking:
WHY should a client take care of de-escaping ? Why not to get his data
unchanged ?
If i forced to de-escape when using bytea then i may use text with the
same escaping/de-escaping AS WELL.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 15:58 Rod Taylor <pg@rbt.ca>
parent: Eugene E. <sad@bankir.ru>
1 sibling, 0 replies; 47+ messages in thread
From: Rod Taylor @ 2006-03-20 15:58 UTC (permalink / raw)
To: Eugene E. <sad@bankir.ru>; +Cc: PFC <lists@peufeu.com>; Achilleus Mantzios <achill@matrix.gatewaynet.com>; Peter Eisentraut <peter_e@gmx.net>; pgsql-sql
On Mon, 2006-03-20 at 17:53 +0300, Eugene E. wrote:
> I wrote:
>
> >> the problem is: you'll get this four byte sequence '\000' _instead_
> >> of NUL-byte anyway.
>
> You wrote:
>
> > Your client library should take care of escaping and de-escaping.
>
> We both agree as you see.
>
> Then i am asking:
> WHY should a client take care of de-escaping ? Why not to get his data
> unchanged ?
Request the data be delivered to you in binary format instead of text
format (see PQexecParams, PQexecPrepared, etc).
When you request text format it requires some escaping to occur for
obvious reasons, but you don't need to worry about the length of the
data.
When you request binary escaping is not required but you do need to
worry about the length of the data.
Pick the method that suits you best.
--
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 16:10 Scott Marlowe <smarlowe@g2switchworks.com>
parent: Eugene E. <sad@bankir.ru>
1 sibling, 1 reply; 47+ messages in thread
From: Scott Marlowe @ 2006-03-20 16:10 UTC (permalink / raw)
To: Eugene E. <sad@bankir.ru>; +Cc: pgsql-sql
On Mon, 2006-03-20 at 02:06, Eugene E. wrote:
> http://dev.mysql.com/doc/refman/5.0/en/news-5-0-19.html
> --- cut ---
> mysql no longer terminates data value display when it encounters a NUL
> byte. Instead, it displays NUL bytes as spaces. (Bug #16859)
> --- cut ---
Everyone here realizes that this is a mysql CLIENT bug, not server side.
i.e. if you're writing an application and request that binary text
string, you'll get it with nuls in it, just like you put in.
Now, I'm not sure that turning nulls into spaces is the best way to
handle this in the client. In fact, I'm sure it's not. But this is not
a server bug, it's a client bug.
Just FYI.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 16:44 PFC <lists@peufeu.com>
parent: Eugene E. <sad@bankir.ru>
1 sibling, 1 reply; 47+ messages in thread
From: PFC @ 2006-03-20 16:44 UTC (permalink / raw)
To: Eugene E. <sad@bankir.ru>; +Cc: Achilleus Mantzios <achill@matrix.gatewaynet.com>; Peter Eisentraut <peter_e@gmx.net>; pgsql-sql
> I wrote:
>
>>> the problem is: you'll get this four byte sequence '\000' _instead_
>>> of NUL-byte anyway.
>
> You wrote:
>
>> Your client library should take care of escaping and de-escaping.
>
> We both agree as you see.
>
> Then i am asking:
> WHY should a client take care of de-escaping ? Why not to get his data
> unchanged ?
I can understand why you say that for something as simple as a BYTEA, but
if the value to be passed to the client is an ARRAY of geometric types or
something, you gonna need an open, platform-agnostic exchange format
between the way postgres internally represents it and the way the client
represents it (in my case, a python list containing instances of python
classes representing boxes, etc, it'll be different for every language).
Exporting data from postgres in binary is only useful to C programmers
who can import the required struct definitions, and you still have to
manage the format, it's just that you walk struct's instead of unescaping
\'s
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-20 22:40 Tom Lane <tgl@sss.pgh.pa.us>
parent: Alvaro Herrera <alvherre@commandprompt.com>
2 siblings, 1 reply; 47+ messages in thread
From: Tom Lane @ 2006-03-20 22:40 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@commandprompt.com>; +Cc: Achilleus Mantzios <achill@matrix.gatewaynet.com>; Peter Eisentraut <peter_e@gmx.net>; Eugene E. <sad@bankir.ru>; pgsql-sql
Alvaro Herrera <alvherre@commandprompt.com> writes:
> text is not bytea.
Indeed. I wonder whether we shouldn't tweak the SQL string literal
parser to reject \000, because AFAICS that isn't going to do anything
useful for any datatype, and it leads to what are at best questionable
results. (bytea's processing of \000 happens somewhere further
downstream, and wouldn't be affected.)
regards, tom lane
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-21 10:33 Eugene E. <sad@bankir.ru>
parent: PFC <lists@peufeu.com>
0 siblings, 0 replies; 47+ messages in thread
From: Eugene E. @ 2006-03-21 10:33 UTC (permalink / raw)
To: PFC <lists@peufeu.com>; +Cc: Achilleus Mantzios <achill@matrix.gatewaynet.com>; Peter Eisentraut <peter_e@gmx.net>; pgsql-sql
PFC wrote:
>
>> I wrote:
>>
>>>> the problem is: you'll get this four byte sequence '\000' _instead_
>>>> of NUL-byte anyway.
>>
>>
>> You wrote:
>>
>>> Your client library should take care of escaping and de-escaping.
>>
>>
>> We both agree as you see.
>>
>> Then i am asking:
>> WHY should a client take care of de-escaping ? Why not to get his
>> data unchanged ?
>
>
> I can understand why you say that for something as simple as a
> BYTEA, but if the value to be passed to the client is an ARRAY of
> geometric types or something
Who said "array" ? I just want to restore _one byte_ from bytea storage.
that's all.
> Exporting data from postgres in binary is only useful to C
> programmers
Serious judgment ! Extremely seriuos...
nonetheless C programmers could not do this.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-21 10:36 Eugene E. <sad@bankir.ru>
parent: Scott Marlowe <smarlowe@g2switchworks.com>
0 siblings, 0 replies; 47+ messages in thread
From: Eugene E. @ 2006-03-21 10:36 UTC (permalink / raw)
To: Scott Marlowe <smarlowe@g2switchworks.com>; +Cc: pgsql-sql
Scott Marlowe wrote:
> On Mon, 2006-03-20 at 02:06, Eugene E. wrote:
>
>>http://dev.mysql.com/doc/refman/5.0/en/news-5-0-19.html
>>--- cut ---
>>mysql no longer terminates data value display when it encounters a NUL
>>byte. Instead, it displays NUL bytes as spaces. (Bug #16859)
>>--- cut ---
>
>
> Everyone here realizes that this is a mysql CLIENT bug, not server side.
>
> i.e. if you're writing an application and request that binary text
> string, you'll get it with nuls in it, just like you put in.
>
> Now, I'm not sure that turning nulls into spaces is the best way to
> handle this in the client. In fact, I'm sure it's not. But this is not
> a server bug, it's a client bug.
I was not sure about MySQL, thank you for your explaination.
This ensures me that even MySQL server handles NUL-bytes properly
regardless to client problems.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-22 03:29 Bruno Wolff III <bruno@wolff.to>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 47+ messages in thread
From: Bruno Wolff III @ 2006-03-22 03:29 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Alvaro Herrera <alvherre@commandprompt.com>; Achilleus Mantzios <achill@matrix.gatewaynet.com>; Peter Eisentraut <peter_e@gmx.net>; Eugene E. <sad@bankir.ru>; pgsql-sql
On Mon, Mar 20, 2006 at 17:40:03 -0500,
Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Indeed. I wonder whether we shouldn't tweak the SQL string literal
> parser to reject \000, because AFAICS that isn't going to do anything
> useful for any datatype, and it leads to what are at best questionable
> results. (bytea's processing of \000 happens somewhere further
> downstream, and wouldn't be affected.)
I think that makes sense. That character is effectively not allowed in text, so
it shouldn't be accepted as input.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-31 06:17 Eugene E. <sad@bankir.ru>
parent: Peter Eisentraut <peter_e@gmx.net>
0 siblings, 1 reply; 47+ messages in thread
From: Eugene E. @ 2006-03-31 06:17 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: Achilleus Mantzios <achill@matrix.gatewaynet.com>; pgsql-sql
Peter Eisentraut wrote:
> Eugene E. wrote:
>
>>the problem is: you'll get this four byte sequence '\000' _instead_
>>of NUL-byte anyway.
>
>
> What you seem to be missing is that PostgreSQL data can be represented
> in textual and in binary form. What you in psql is the textual form.
> If you want the binary form you need to select it. Then you can pass
> the exact bytes back and forth.
your sentence is not true.
I can not select exact bytes even if i use BYTEA type
the folloiwing tiny C-program shows this pretty clear
#include <stdlib.h>
#include <stdio.h>
#include "libpq-fe.h"
int
main (void)
{
PGconn * conn;
PGresult * res;
char * val;
char * l;
int len;
conn = PQconnectdb("user=scott password=tiger dbname=test_db");
PQexec(conn, "CREATE TABLE t (a BYTEA)");
PQexec(conn, "INSERT INTO t VALUES ('ab\\\\000cd')");
res = PQexec(conn, "SELECT a,length(a) FROM t");
val = PQgetvalue(res,0,0);
l = PQgetvalue(res,0,1);
len = PQgetlength(res,0,0);
printf("what_we_retrive='%s' its_value_length=%i but
orig_length=%s\n",val,len,l);
PQclear(res);
PQfinish(conn);
return 0;
}
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-03-31 16:47 Stephan Szabo <sszabo@megazone.bigpanda.com>
parent: Eugene E. <sad@bankir.ru>
0 siblings, 1 reply; 47+ messages in thread
From: Stephan Szabo @ 2006-03-31 16:47 UTC (permalink / raw)
To: Eugene E. <sad@bankir.ru>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Achilleus Mantzios <achill@matrix.gatewaynet.com>; pgsql-sql
On Fri, 31 Mar 2006, Eugene E. wrote:
> Peter Eisentraut wrote:
> > Eugene E. wrote:
> >
> >>the problem is: you'll get this four byte sequence '\000' _instead_
> >>of NUL-byte anyway.
> >
> >
> > What you seem to be missing is that PostgreSQL data can be represented
> > in textual and in binary form. What you in psql is the textual form.
> > If you want the binary form you need to select it. Then you can pass
> > the exact bytes back and forth.
>
> your sentence is not true.
> I can not select exact bytes even if i use BYTEA type
No, that is still using the textual form. If you use PQexecParams and set
the last argument to show you want binary data, you should get binary
data.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-04-04 10:30 Eugene E. <sad@bankir.ru>
parent: Stephan Szabo <sszabo@megazone.bigpanda.com>
0 siblings, 2 replies; 47+ messages in thread
From: Eugene E. @ 2006-04-04 10:30 UTC (permalink / raw)
To: Stephan Szabo <sszabo@megazone.bigpanda.com>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Achilleus Mantzios <achill@matrix.gatewaynet.com>; pgsql-sql
Stephan Szabo wrote:
> On Fri, 31 Mar 2006, Eugene E. wrote:
>
>
>>Peter Eisentraut wrote:
>>
>>>Eugene E. wrote:
>>>
>>>
>>>>the problem is: you'll get this four byte sequence '\000' _instead_
>>>>of NUL-byte anyway.
>>>
>>>
>>>What you seem to be missing is that PostgreSQL data can be represented
>>>in textual and in binary form. What you in psql is the textual form.
>>>If you want the binary form you need to select it. Then you can pass
>>>the exact bytes back and forth.
>>
>>your sentence is not true.
>>I can not select exact bytes even if i use BYTEA type
>
>
> No, that is still using the textual form. If you use PQexecParams and set
> the last argument to show you want binary data, you should get binary
> data.
Documentation says:
===
PQexecParams
Submits a command to the server and waits for the result, with the
ability to pass parameters separately from the SQL command text.
===
How should i use this func to change so-called "textual form" of a
select-result to so-called "binary form" ?
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-04-04 11:05 Michael Glaesemann <grzm@myrealbox.com>
parent: Eugene E. <sad@bankir.ru>
1 sibling, 0 replies; 47+ messages in thread
From: Michael Glaesemann @ 2006-04-04 11:05 UTC (permalink / raw)
To: Eugene E. <sad@bankir.ru>; +Cc: pgsql-sql
On Apr 4, 2006, at 19:30 , Eugene E. wrote:
> Stephan Szabo wrote:
>> On Fri, 31 Mar 2006, Eugene E. wrote:
>>> Peter Eisentraut wrote:
>>>
>> No, that is still using the textual form. If you use PQexecParams
>> and set
>> the last argument to show you want binary data, you should get binary
>> data.
>
> Documentation says:
> ===
> PQexecParams
>
> Submits a command to the server and waits for the result, with
> the ability to pass parameters separately from the SQL command text.
> ===
>
> How should i use this func to change so-called "textual form" of a
> select-result to so-called "binary form" ?
It looks like you quoted
http://www.postgresql.org/docs/8.1/interactive/libpq-exec.html#AEN25123
If you read the rest of the explanation of PQexecParams, I think
you'll find the answer you're looking for. (Please note I don't have
any experience using libpq. I'm just trying to help you find an
answer to your question.)
The usage block includes the parameters PQexecParams accepts.
> PGresult *PQexecParams(PGconn *conn,
> const char *command,
> int nParams,
> const Oid *paramTypes,
> const char * const *paramValues,
> const int *paramLengths,
> const int *paramFormats,
> int resultFormat);
That last parameter (resultFormat) looks promising.
The next sentence gives query result formats:
> PQexecParams is like PQexec, but offers additional functionality:
> parameter values can be specified separately from the command
> string proper, and query results can be requested in either text or
> binary format.
And in the next paragraph:
> ... resultFormat is zero to obtain results in text format, or one
> to obtain results in binary format. ...
Hope this helps.
Michael Glaesemann
grzm myrealbox com
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-04-04 14:21 Stephan Szabo <sszabo@megazone.bigpanda.com>
parent: Eugene E. <sad@bankir.ru>
1 sibling, 1 reply; 47+ messages in thread
From: Stephan Szabo @ 2006-04-04 14:21 UTC (permalink / raw)
To: Eugene E. <sad@bankir.ru>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Achilleus Mantzios <achill@matrix.gatewaynet.com>; pgsql-sql
On Tue, 4 Apr 2006, Eugene E. wrote:
> Stephan Szabo wrote:
> > On Fri, 31 Mar 2006, Eugene E. wrote:
> >
> >
> >>Peter Eisentraut wrote:
> >>
> >>>Eugene E. wrote:
> >>>
> >>>
> >>>>the problem is: you'll get this four byte sequence '\000' _instead_
> >>>>of NUL-byte anyway.
> >>>
> >>>
> >>>What you seem to be missing is that PostgreSQL data can be represented
> >>>in textual and in binary form. What you in psql is the textual form.
> >>>If you want the binary form you need to select it. Then you can pass
> >>>the exact bytes back and forth.
> >>
> >>your sentence is not true.
> >>I can not select exact bytes even if i use BYTEA type
> >
> >
> > No, that is still using the textual form. If you use PQexecParams and set
> > the last argument to show you want binary data, you should get binary
> > data.
>
> Documentation says:
> ===
> PQexecParams
>
> Submits a command to the server and waits for the result, with the
> ability to pass parameters separately from the SQL command text.
> ===
>
> How should i use this func to change so-called "textual form" of a
> select-result to so-called "binary form" ?
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-04-05 06:34 Eugene E. <sad@bankir.ru>
parent: Stephan Szabo <sszabo@megazone.bigpanda.com>
0 siblings, 1 reply; 47+ messages in thread
From: Eugene E. @ 2006-04-05 06:34 UTC (permalink / raw)
To: Stephan Szabo <sszabo@megazone.bigpanda.com>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Achilleus Mantzios <achill@matrix.gatewaynet.com>; pgsql-sql
Stephan Szabo wrote:
> On Tue, 4 Apr 2006, Eugene E. wrote:
>
>
>>Stephan Szabo wrote:
>>
>>>On Fri, 31 Mar 2006, Eugene E. wrote:
>>>
>>>
>>>
>>>>Peter Eisentraut wrote:
>>>>
>>>>
>>>>>Eugene E. wrote:
>>>>>
>>>>>
>>>>>
>>>>>>the problem is: you'll get this four byte sequence '\000' _instead_
>>>>>>of NUL-byte anyway.
>>>>>
>>>>>
>>>>>What you seem to be missing is that PostgreSQL data can be represented
>>>>>in textual and in binary form. What you in psql is the textual form.
>>>>>If you want the binary form you need to select it. Then you can pass
>>>>>the exact bytes back and forth.
>>>>
>>>>your sentence is not true.
>>>>I can not select exact bytes even if i use BYTEA type
>>>
>>>
>>>No, that is still using the textual form. If you use PQexecParams and set
>>>the last argument to show you want binary data, you should get binary
>>>data.
ok
then i am using PQexecParams
the following tiny program shows a wonderful lameness...
#include <stdlib.h>
#include <stdio.h>
#include "libpq-fe.h"
int
main (void)
{
PGconn * conn;
PGresult * res;
char * val;
char * l;
int len;
conn = PQconnectdb("user=scott password=tiger name=test_db");
PQexec(conn, "CREATE TABLE t (a BYTEA)");
PQexec(conn, "INSERT INTO t VALUES ('ab\\\\000cd')");
res = PQexecParams(conn, "SELECT a,length(a) FROM t", 0, NULL, NULL,
NULL, NULL, 1);
val = PQgetvalue(res,0,0);
l = PQgetvalue(res,0,1);
len = PQgetlength(res,0,0);
printf("what_we_retrive='screened' its_value_length=%i but
orig_length=%s\n",len,l);
PQclear(res);
PQfinish(conn);
return 0;
}
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-04-05 14:36 Stephan Szabo <sszabo@megazone.bigpanda.com>
parent: Eugene E. <sad@bankir.ru>
0 siblings, 1 reply; 47+ messages in thread
From: Stephan Szabo @ 2006-04-05 14:36 UTC (permalink / raw)
To: Eugene E. <sad@bankir.ru>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Achilleus Mantzios <achill@matrix.gatewaynet.com>; pgsql-sql
On Wed, 5 Apr 2006, Eugene E. wrote:
> Stephan Szabo wrote:
> > On Tue, 4 Apr 2006, Eugene E. wrote:
> >
> >
> >>Stephan Szabo wrote:
> >>
> >>>On Fri, 31 Mar 2006, Eugene E. wrote:
> >>>
> >>>
> >>>
> >>>>Peter Eisentraut wrote:
> >>>>
> >>>>
> >>>>>Eugene E. wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>the problem is: you'll get this four byte sequence '\000' _instead_
> >>>>>>of NUL-byte anyway.
> >>>>>
> >>>>>
> >>>>>What you seem to be missing is that PostgreSQL data can be represented
> >>>>>in textual and in binary form. What you in psql is the textual form.
> >>>>>If you want the binary form you need to select it. Then you can pass
> >>>>>the exact bytes back and forth.
> >>>>
> >>>>your sentence is not true.
> >>>>I can not select exact bytes even if i use BYTEA type
> >>>
> >>>
> >>>No, that is still using the textual form. If you use PQexecParams and set
> >>>the last argument to show you want binary data, you should get binary
> >>>data.
>
> ok
> then i am using PQexecParams
>
> the following tiny program shows a wonderful lameness...
What lameness? The fact that you're trying to use a binary (network order
maybe) integer as a string? That's not the fault of PQexecParams but
of the code calling it.
It'd be nice for ease of use to be able to say, give me this
column (the integer) as a string and this column (the bytea) as binary,
especially as the commentary implies that the protocol supports it. But as
I said before, that's a separate discussion from whether or not Peter's
claim that it's possible to get binary data is false.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-04-06 05:07 Eugene E. <sad@bankir.ru>
parent: Stephan Szabo <sszabo@megazone.bigpanda.com>
0 siblings, 1 reply; 47+ messages in thread
From: Eugene E. @ 2006-04-06 05:07 UTC (permalink / raw)
To: Stephan Szabo <sszabo@megazone.bigpanda.com>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Achilleus Mantzios <achill@matrix.gatewaynet.com>; pgsql-sql
Stephan Szabo wrote:
> On Wed, 5 Apr 2006, Eugene E. wrote:
>
>
>>Stephan Szabo wrote:
>>
>>>On Tue, 4 Apr 2006, Eugene E. wrote:
>>>
>>>
>>>
>>>>Stephan Szabo wrote:
>>>>
>>>>
>>>>>On Fri, 31 Mar 2006, Eugene E. wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Peter Eisentraut wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Eugene E. wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>the problem is: you'll get this four byte sequence '\000' _instead_
>>>>>>>>of NUL-byte anyway.
>>>>>>>
>>>>>>>
>>>>>>>What you seem to be missing is that PostgreSQL data can be represented
>>>>>>>in textual and in binary form. What you in psql is the textual form.
>>>>>>>If you want the binary form you need to select it. Then you can pass
>>>>>>>the exact bytes back and forth.
>>>>>>
>>>>>>your sentence is not true.
>>>>>>I can not select exact bytes even if i use BYTEA type
>>>>>
>>>>>
>>>>>No, that is still using the textual form. If you use PQexecParams and set
>>>>>the last argument to show you want binary data, you should get binary
>>>>>data.
>>
>>ok
>>then i am using PQexecParams
>>
>>the following tiny program shows a wonderful lameness...
>
>
> What lameness? The fact that you're trying to use a binary (network order
> maybe) integer as a string? That's not the fault of PQexecParams but
> of the code calling it.
You're right !
That's is not a fault of PQexecParams at all. That's the fault of its
design. (I pretty know why an integer has been not displayed, but why
they designed this function that way ? i do not know)
> It'd be nice for ease of use to be able to say, give me this
> column (the integer) as a string and this column (the bytea) as binary,
I always want to retrieve TEXT (and mostly INT) in TEXTUAL-FORM, and
BYTEA always in BINARY-FORM. (at least by defaul)
WHY SHOULD I RETRIVE A SINGLE BYTEA FIELD IN A SEPARATE QUERY ???
Look: if i define a field as of type BYTEA, doesn't it mean the field
tends to store binary data ? If does, then WHY they (by default) convert
its value to TEXTUAL-FORM which is not needed by default -- i already
inform the server: "i want some BINARY to in and out" when i have
choosed the type BYTEA
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-04-06 06:24 Stephan Szabo <sszabo@megazone.bigpanda.com>
parent: Eugene E. <sad@bankir.ru>
0 siblings, 1 reply; 47+ messages in thread
From: Stephan Szabo @ 2006-04-06 06:24 UTC (permalink / raw)
To: Eugene E. <sad@bankir.ru>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Achilleus Mantzios <achill@matrix.gatewaynet.com>; pgsql-sql
On Thu, 6 Apr 2006, Eugene E. wrote:
> Stephan Szabo wrote:
> > On Wed, 5 Apr 2006, Eugene E. wrote:
> >
> >
> >>Stephan Szabo wrote:
> >>
> >>>On Tue, 4 Apr 2006, Eugene E. wrote:
> >>>
> >>>
> >>>
> >>>>Stephan Szabo wrote:
> >>>>
> >>>>
> >>>>>On Fri, 31 Mar 2006, Eugene E. wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Peter Eisentraut wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Eugene E. wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>the problem is: you'll get this four byte sequence '\000' _instead_
> >>>>>>>>of NUL-byte anyway.
> >>>>>>>
> >>>>>>>
> >>>>>>>What you seem to be missing is that PostgreSQL data can be represented
> >>>>>>>in textual and in binary form. What you in psql is the textual form.
> >>>>>>>If you want the binary form you need to select it. Then you can pass
> >>>>>>>the exact bytes back and forth.
> >>>>>>
> >>>>>>your sentence is not true.
> >>>>>>I can not select exact bytes even if i use BYTEA type
> >>>>>
> >>>>>
> >>>>>No, that is still using the textual form. If you use PQexecParams and set
> >>>>>the last argument to show you want binary data, you should get binary
> >>>>>data.
> >>
> >>ok
> >>then i am using PQexecParams
> >>
> >>the following tiny program shows a wonderful lameness...
> >
> >
> > What lameness? The fact that you're trying to use a binary (network order
> > maybe) integer as a string? That's not the fault of PQexecParams but
> > of the code calling it.
>
> You're right !
> That's is not a fault of PQexecParams at all. That's the fault of its
> design.
No, I'd argue in this case that it was the fault of a programmer not
paying enough attention/not thinking through what the api doc says.
>(I pretty know why an integer has been not displayed, but why
> they designed this function that way ? i do not know)
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. Expect to get asked
why bytea is special -- why should integer be passed as a string given
that you may often want to do operations on the value which expect it as
an actual number not the string representation of a number.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-04-06 07:18 Eugene E. <sad@bankir.ru>
parent: Stephan Szabo <sszabo@megazone.bigpanda.com>
0 siblings, 1 reply; 47+ messages in thread
From: Eugene E. @ 2006-04-06 07:18 UTC (permalink / raw)
To: Stephan Szabo <sszabo@megazone.bigpanda.com>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Achilleus Mantzios <achill@matrix.gatewaynet.com>; pgsql-sql
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.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-04-06 11:52 Stephan Szabo <sszabo@megazone.bigpanda.com>
parent: Eugene E. <sad@bankir.ru>
0 siblings, 3 replies; 47+ messages in thread
From: Stephan Szabo @ 2006-04-06 11:52 UTC (permalink / raw)
To: Eugene E. <sad@bankir.ru>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Achilleus Mantzios <achill@matrix.gatewaynet.com>; pgsql-sql
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.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-04-06 12:33 Stephan Szabo <sszabo@megazone.bigpanda.com>
parent: Stephan Szabo <sszabo@megazone.bigpanda.com>
2 siblings, 0 replies; 47+ messages in thread
From: Stephan Szabo @ 2006-04-06 12:33 UTC (permalink / raw)
To: Eugene E. <sad@bankir.ru>; +Cc: pgsql-sql
On Thu, 6 Apr 2006, Stephan Szabo wrote:
> On Thu, 6 Apr 2006, Eugene E. wrote:
>
> 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).
For notes sake, the example code with binary retrieval in the docs seems
to have
ntohl(*((uint32_t *) iptr))
for iptr being the result of PQgetvalue on an integer column.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-04-06 12:33 Eugene E. <sad@bankir.ru>
parent: Stephan Szabo <sszabo@megazone.bigpanda.com>
2 siblings, 2 replies; 47+ messages in thread
From: Eugene E. @ 2006-04-06 12:33 UTC (permalink / raw)
To: Stephan Szabo <sszabo@megazone.bigpanda.com>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Achilleus Mantzios <achill@matrix.gatewaynet.com>; pgsql-sql
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.
WHY strcmp ?! do you really think the user is a fool ?
if the user declared something "binary", he obviously knows what he has
done.
WHY c-string ? the user only wants to get PGresult structure.
Since this structure provides a length of each value, you have no need
in c-string. Why do think the user needs it ?
"textual-form" is just a name of actually existent convertion rule.
i am not trying to find out a philosophy here.
> 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?
the actual representasion of most types is pretty useful.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-04-06 12:39 Markus Schaber <schabi@logix-tt.com>
parent: Stephan Szabo <sszabo@megazone.bigpanda.com>
2 siblings, 0 replies; 47+ messages in thread
From: Markus Schaber @ 2006-04-06 12:39 UTC (permalink / raw)
To: pgsql-sql
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-04-06 12:42 Stephan Szabo <sszabo@megazone.bigpanda.com>
parent: Eugene E. <sad@bankir.ru>
1 sibling, 0 replies; 47+ messages in thread
From: Stephan Szabo @ 2006-04-06 12:42 UTC (permalink / raw)
To: Eugene E. <sad@bankir.ru>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Achilleus Mantzios <achill@matrix.gatewaynet.com>; pgsql-sql
On Thu, 6 Apr 2006, Eugene E. wrote:
> 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.
>
> WHY strcmp ?! do you really think the user is a fool ?
> if the user declared something "binary", he obviously knows what he has
> done.
>
> WHY c-string ? the user only wants to get PGresult structure.
> Since this structure provides a length of each value, you have no need
> in c-string. Why do think the user needs it ?
>
> "textual-form" is just a name of actually existent convertion rule.
> i am not trying to find out a philosophy here.
Then, honestly, nothing anyone can say will help, because you're not
willing to actually hold a conversation on the topic.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-04-06 12:47 Markus Schaber <schabi@logix-tt.com>
parent: Eugene E. <sad@bankir.ru>
1 sibling, 1 reply; 47+ messages in thread
From: Markus Schaber @ 2006-04-06 12:47 UTC (permalink / raw)
To: pgsql-sql
Hi, Eugene,
Eugene E. wrote:
>> 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.
> WHY strcmp ?! do you really think the user is a fool ?
> if the user declared something "binary", he obviously knows what he has
> done.
But when the user requests the canonical _text_ representation of a byte
area data type, why do you consider him declaring it "binary"?
> WHY c-string ? the user only wants to get PGresult structure.
And he does request the _text_ represenation of the datatypes in this
structure.
> Since this structure provides a length of each value, you have no need
> in c-string. Why do think the user needs it ?
A user that does not have a need in C-Strings can fetch the binary
representation, getting higher efficency for all datatypes.
> "textual-form" is just a name of actually existent convertion rule.
> i am not trying to find out a philosophy here.
There is no philosophy but orthogonality.
There's a textual and a binary form of datatypes. For varchar, byta,
int4, float, PostGIS geometries etc...
>> 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?
> the actual representasion of most types is pretty useful.
The text representation is pretty useful for human readers for _most_
datatypes, the binary representation is much easier to parse for programs.
So use the binary representation for everything if you don't want to
display the data to the user directly.
One could speculate that the textual representation is just a little
help for "generic" tools like pg_dump, pgadmin or psql that display data
to the user without having any knowledge of the specific datatypes (and
without the possibility to have such knowledge).
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-04-06 13:20 Eugene E. <sad@bankir.ru>
parent: Markus Schaber <schabi@logix-tt.com>
0 siblings, 1 reply; 47+ messages in thread
From: Eugene E. @ 2006-04-06 13:20 UTC (permalink / raw)
To: Markus Schaber <schabi@logix-tt.com>; +Cc: pgsql-sql
Markus Schaber wrote:
> Hi, Eugene,
>
> Eugene E. wrote:
>
>
>>>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.
>>
>>WHY strcmp ?! do you really think the user is a fool ?
>>if the user declared something "binary", he obviously knows what he has
>>done.
>
>
> But when the user requests the canonical _text_ representation of a byte
> area data type, why do you consider him declaring it "binary"?
he did not request this representation. it is _by_default_
if you wish to provide it by request, please do it.
i ask you to provide minimal convertion by default, mentioned the user
wants his data unchanged.
and let the user interpret his own data himself.
>>Since this structure provides a length of each value, you have no need
>>in c-string. Why do think the user needs it ?
>
> A user that does not have a need in C-Strings can fetch the binary
> representation, getting higher efficency for all datatypes.
and lose the pretty good representation of all other columns in the same
request.
>>"textual-form" is just a name of actually existent convertion rule.
>>i am not trying to find out a philosophy here.
>
> There is no philosophy but orthogonality.
>
> There's a textual and a binary form of datatypes. For varchar, byta,
> int4, float, PostGIS geometries etc...
good. i ask you to slightly change "textual" representation of bytea.
> The text representation is pretty useful for human readers for _most_
> datatypes, the binary representation is much easier to parse for programs.
You are right.
but
Who said that i can not display something ?
i thougth, human-readability of some data depends completely on how
CLIENT-SIDE interpret it.
server do not know and should not know
what data is human readable or printable... etc.
> So use the binary representation for everything if you don't want to
> display the data to the user directly.
The problem we discuss is not about displaing or printig at all.
Some applications want "textual-form" -- most applications
but not only to display
and in the _same_ query the same applications want bytea...
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: have you feel anything when you read this ?
@ 2006-04-10 16:31 Markus Schaber <schabi@logix-tt.com>
parent: Eugene E. <sad@bankir.ru>
0 siblings, 0 replies; 47+ messages in thread
From: Markus Schaber @ 2006-04-10 16:31 UTC (permalink / raw)
To: pgsql-sql
Hi, Eugene,
Eugene E. wrote:
> he did not request this representation. it is _by_default_
He used a function that provided it by default. He could use the other
function that allows him to select which representation he wants.
> if you wish to provide it by request, please do it.
I cannot provide anything, because I'm not a PostgreSQL developer. To be
honest, I can provide the user with nice Java Objects, because I'm the
maintainer of the PostGIS Java extension, but that's all.
>> A user that does not have a need in C-Strings can fetch the binary
>> representation, getting higher efficency for all datatypes.
> and lose the pretty good representation of all other columns in the same
> request.
It is not "pretty good". It is human readable, but it are C-Strings with
some text. It uses much more CPU power on both sides, Date Formats can
be misleading, and PostGIS even reverted to a binary like format for
their canonical text representation because the users complained about
coordinate drift due to rounding errors in the floating point
input/output routines, so pg_dump and restoring the database changed the
data.
So I cannot see that the textual from is superior for _any_ of the
datatypes. IMHO, its sole purpose is to have a generic way to represent
the data for generic tools as pg_dump -F p, pgadmin3, psql and such,
which cannot know the (possibly user-defined) datatypes in advance.
>> There is no philosophy but orthogonality.
>> There's a textual and a binary form of datatypes. For varchar, byta,
>> int4, float, PostGIS geometries etc...
> good. i ask you to slightly change "textual" representation of bytea.
This will achieve at least the following:
- It will break all libraries, tools and applications that rely on the
current behaviour.
- It will break the guarantee for generic applications that the text
representation of every datatype can be handled as text.
- It will break pg_dump -F p (which is the default for pg_dump by the
way), thus making it _impossible_ to have "plaintext" dumps of a
database, with no easy way of reinventing this behaviour. Those dumps
are to be edited with text editors, which don't cope easily with
nullbytes and other waste...
>> The text representation is pretty useful for human readers for _most_
>> datatypes, the binary representation is much easier to parse for
>> programs.
> You are right.
> but
> Who said that i can not display something ?
> i thougth, human-readability of some data depends completely on how
> CLIENT-SIDE interpret it.
> server do not know and should not know
> what data is human readable or printable... etc.
So what you say is that the canonical text representation should be
abandoned completely. Fine.
The problem is that all generic applications, that don't know about the
concrete datatypes, will get impossible. psql, pg_dump, pgadmin and others.
Different from "normal" applications which can have their specific
datatypes hardwired in the code or whatever, those applications cannot
be taught about how to present the data to an user in a generic way, if
there's nothing in the backend.
Users and extensions can invent new datatypes as they want, how do you
expect the authors of pgadmin or psql to cope with proprietary in-house
datatypes of a certain PostgreSQL user?
>> So use the binary representation for everything if you don't want to
>> display the data to the user directly.
> The problem we discuss is not about displaing or printig at all.
> Some applications want "textual-form" -- most applications
> but not only to display
> and in the _same_ query the same applications want bytea...
Why do you try so hard to resist understanding the whole point?
Those applications _get_ bytea. They just get a Cstring-safe
representation of it. It's just like you have to put "quotes" around and
\escapes into a string in your program sources if you use any of the
weird characters.
You have the decision between text and binary format for your query. As
libpq is a low level API, it does not abstract you from this difference.
You can you use a higher level API that abstracts over the whole issue
and gives you nice Objects (like the jdbc library), then you don't have
to cope with those representations at all.
It also may make sense to provide an extension for lipq that lets you
select binary and textual representation column-wise (which might need a
protocol extension, I don't have the specs in mind).
But it absolutely does not make any sense to break the whole concept of
text representations by making it binary for a single datatype.
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
^ permalink raw reply [nested|flat] 47+ messages in thread
end of thread, other threads:[~2006-04-10 16:31 UTC | newest]
Thread overview: 47+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-03-20 08:06 have you feel anything when you read this ? Eugene E. <sad@bankir.ru>
2006-03-20 08:27 ` PFC <lists@peufeu.com>
2006-03-20 08:29 ` Eugene E. <sad@bankir.ru>
2006-03-20 08:50 ` Peter Eisentraut <peter_e@gmx.net>
2006-03-20 08:57 ` Eugene E. <sad@bankir.ru>
2006-03-20 10:47 ` Peter Eisentraut <peter_e@gmx.net>
2006-03-20 10:59 ` Eugene E. <sad@bankir.ru>
2006-03-20 11:51 ` Peter Eisentraut <peter_e@gmx.net>
2006-03-20 12:07 ` Eugene E. <sad@bankir.ru>
2006-03-20 13:26 ` Achilleus Mantzios <achill@matrix.gatewaynet.com>
2006-03-20 12:31 ` Eugene E. <sad@bankir.ru>
2006-03-20 13:15 ` Peter Eisentraut <peter_e@gmx.net>
2006-03-31 06:17 ` Eugene E. <sad@bankir.ru>
2006-03-31 16:47 ` Stephan Szabo <sszabo@megazone.bigpanda.com>
2006-04-04 10:30 ` Eugene E. <sad@bankir.ru>
2006-04-04 11:05 ` Michael Glaesemann <grzm@myrealbox.com>
2006-04-04 14:21 ` Stephan Szabo <sszabo@megazone.bigpanda.com>
2006-04-05 06:34 ` Eugene E. <sad@bankir.ru>
2006-04-05 14:36 ` Stephan Szabo <sszabo@megazone.bigpanda.com>
2006-04-06 05:07 ` Eugene E. <sad@bankir.ru>
2006-04-06 06:24 ` Stephan Szabo <sszabo@megazone.bigpanda.com>
2006-04-06 07:18 ` Eugene E. <sad@bankir.ru>
2006-04-06 11:52 ` Stephan Szabo <sszabo@megazone.bigpanda.com>
2006-04-06 12:33 ` Stephan Szabo <sszabo@megazone.bigpanda.com>
2006-04-06 12:33 ` Eugene E. <sad@bankir.ru>
2006-04-06 12:42 ` Stephan Szabo <sszabo@megazone.bigpanda.com>
2006-04-06 12:47 ` Markus Schaber <schabi@logix-tt.com>
2006-04-06 13:20 ` Eugene E. <sad@bankir.ru>
2006-04-10 16:31 ` Markus Schaber <schabi@logix-tt.com>
2006-04-06 12:39 ` Markus Schaber <schabi@logix-tt.com>
2006-03-20 14:19 ` PFC <lists@peufeu.com>
2006-03-20 14:53 ` Eugene E. <sad@bankir.ru>
2006-03-20 15:58 ` Rod Taylor <pg@rbt.ca>
2006-03-20 16:44 ` PFC <lists@peufeu.com>
2006-03-21 10:33 ` Eugene E. <sad@bankir.ru>
2006-03-20 13:06 ` Achilleus Mantzios <achill@matrix.gatewaynet.com>
2006-03-20 12:13 ` Alvaro Herrera <alvherre@commandprompt.com>
2006-03-20 12:19 ` Eugene E. <sad@bankir.ru>
2006-03-20 12:27 ` Alvaro Herrera <alvherre@commandprompt.com>
2006-03-20 12:44 ` Eugene E. <sad@bankir.ru>
2006-03-20 13:16 ` Peter Eisentraut <peter_e@gmx.net>
2006-03-20 13:21 ` Achilleus Mantzios <achill@matrix.gatewaynet.com>
2006-03-20 12:18 ` Alvaro Herrera <alvherre@commandprompt.com>
2006-03-20 22:40 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-03-22 03:29 ` Bruno Wolff III <bruno@wolff.to>
2006-03-20 16:10 ` Scott Marlowe <smarlowe@g2switchworks.com>
2006-03-21 10:36 ` Eugene E. <sad@bankir.ru>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox