Re: [QUESTIONS] impossible insert data into VARCHAR

Hi,

There's an error while inserting data into a column defined as VARCHAR without
length in PostgreSQL 6.3.
Take a look:

postgres=> CREATE TABLE prova ( uno VARCHAR(10) );
CREATE
postgres=> INSERT INTO prova VALUES ( 'OK' );
INSERT 153042 1

postgres=> CREATE TABLE prova2 ( uno VARCHAR );
CREATE
postgres=> INSERT INTO prova2 VALUES ( 'NOT OK' );
PQexec() -- Request was sent to backend, but backend closed the channel before responding.
This probably means the backend terminated abnormally before or while processing the request.

Jose, please post problem reports to hackers, not to questions, on not-yet-released versions. I've moved
this to hackers.

btw, I saw this too but in a different context and wasn't certain if it was a new problem:

postgres=> select char_length('hi'::text);
length
------
2
(1 row)

postgres=> select character_length('hi'::varchar);
PQexec() -- Request was sent to backend, but backend closed the channel before responding.
This probably means the backend terminated abnormally before or while processing the request.

- Tom

ARRRRG - then next problem with VARSIZE - damn thing.

This time it's during the parser (gdb told me). varcharin()
is called with a atttypmod of 0 causing a palloc() of 0
bytes. How should a VARCHAR type whithout a specified length
behave? Is this type 1 character or a variable size up to
4096?

Until later, Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

Jan Wieck wrote:

Hi,

There's an error while inserting data into a column defined as VARCHAR without
length in PostgreSQL 6.3.
Take a look:

postgres=> CREATE TABLE prova ( uno VARCHAR(10) );
CREATE
postgres=> INSERT INTO prova VALUES ( 'OK' );
INSERT 153042 1

postgres=> CREATE TABLE prova2 ( uno VARCHAR );
CREATE
postgres=> INSERT INTO prova2 VALUES ( 'NOT OK' );
PQexec() -- Request was sent to backend, but backend closed the channel before responding.
This probably means the backend terminated abnormally before or while processing the request.

Jose, please post problem reports to hackers, not to questions, on not-yet-released versions. I've moved
this to hackers.

btw, I saw this too but in a different context and wasn't certain if it was a new problem:

postgres=> select char_length('hi'::text);
length
------
2
(1 row)

postgres=> select character_length('hi'::varchar);
PQexec() -- Request was sent to backend, but backend closed the channel before responding.
This probably means the backend terminated abnormally before or while processing the request.

- Tom

ARRRRG - then next problem with VARSIZE - damn thing.

This time it's during the parser (gdb told me). varcharin()
is called with a atttypmod of 0 causing a palloc() of 0
bytes. How should a VARCHAR type whithout a specified length
behave? Is this type 1 character or a variable size up to
4096?

It should allow any length (up to the implementation maximum of 4096). The usage is not defined for SQL92,
unlike the case for "char" with no explicit size which defaults to one.

- Tom

Jan Wieck wrote:

[... quoting level exceeded ...]

ARRRRG - then next problem with VARSIZE - damn thing.

This time it's during the parser (gdb told me). varcharin()
is called with a atttypmod of 0 causing a palloc() of 0
bytes. How should a VARCHAR type whithout a specified length
behave? Is this type 1 character or a variable size up to
4096?

It should allow any length (up to the implementation maximum of 4096). The usage is not defined for SQL92,
unlike the case for "char" with no explicit size which defaults to one.

Could be hacked into varcharin(). If the test on atttypmod is
changed from "!= -1" into "> 0" it works that way. Don't
have the time right now to run a regression test, but some
typed queries with

select into t values ...

and

select into t select ...

worked O.K.

Until later, Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

Do we need to disallow varchar() and char() without a length?

There's an error while inserting data into a column defined as VARCHAR without
length in PostgreSQL 6.3.
Take a look:

postgres=> CREATE TABLE prova ( uno VARCHAR(10) );
CREATE
postgres=> INSERT INTO prova VALUES ( 'OK' );
INSERT 153042 1

postgres=> CREATE TABLE prova2 ( uno VARCHAR );
CREATE
postgres=> INSERT INTO prova2 VALUES ( 'NOT OK' );
PQexec() -- Request was sent to backend, but backend closed the channel before responding.
This probably means the backend terminated abnormally before or while processing the request.

Jose, please post problem reports to hackers, not to questions, on not-yet-released versions. I've moved
this to hackers.

btw, I saw this too but in a different context and wasn't certain if it was a new problem:

postgres=> select char_length('hi'::text);
length
------
2
(1 row)

postgres=> select character_length('hi'::varchar);
PQexec() -- Request was sent to backend, but backend closed the channel before responding.
This probably means the backend terminated abnormally before or while processing the request.

- Tom

--
Bruce Momjian
maillist@candle.pha.pa.us

On Thu, 5 Feb 1998, Thomas G. Lockhart wrote:

There's an error while inserting data into a column defined as VARCHAR without
length in PostgreSQL 6.3.
Take a look:

postgres=> CREATE TABLE prova ( uno VARCHAR(10) );
CREATE
postgres=> INSERT INTO prova VALUES ( 'OK' );
INSERT 153042 1

postgres=> CREATE TABLE prova2 ( uno VARCHAR );
CREATE
postgres=> INSERT INTO prova2 VALUES ( 'NOT OK' );
PQexec() -- Request was sent to backend, but backend closed the channel before responding.
This probably means the backend terminated abnormally before or while processing the request.

Jose, please post problem reports to hackers, not to questions, on not-yet-released versions. I've moved
this to hackers.

Ok, sorry.

btw, I saw this too but in a different context and wasn't certain if it was a new problem:

postgres=> select char_length('hi'::text);
length
------
2
(1 row)

I've another problem about connection
when I try to connect to PostgreSQL using:
psql postgres -h server
I have this error:

Connection to database 'postgres' failed.
User authentication failed

I'd ran postmaster with -i as:

postmaster -i -o -F -B 512 -S > server.log 2>&1

Any idea?
Thanks, Jose'

I am applying such a fix right now.

Could be hacked into varcharin(). If the test on atttypmod is
changed from "!= -1" into "> 0" it works that way. Don't
have the time right now to run a regression test, but some
typed queries with

select into t values ...

and

select into t select ...

worked O.K.

Until later, Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

--
Bruce Momjian
maillist@candle.pha.pa.us

Do we need to disallow varchar() and char() without a length?

The question might be moot since Jan's suggestion may fix the behavior. But, just for completeness...

char, char(), and varchar() are SQL92 character types. varchar - with no arguments - is not, and seems as
though it is functionally equivalent to "text". Could do without it if necessary, but it is a nice extension.

- Tom