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
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:
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
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
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,
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
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
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
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 ?
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
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
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
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
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.
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
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
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
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
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
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 ---
---(end of broadcast)---
TIP 2:
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...
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
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
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
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
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
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
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/
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
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
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
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
---
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
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;
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;
:-)
---(end of
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
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
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
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
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/
---(end of
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
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
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
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
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
Alvaro Herrera [EMAIL PROTECTED] 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
45 matches
Mail list logo
