current CVS snapshot of pgsql crash ...

This happens, when I want do this:
(4) $ sql
Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL
[PostgreSQL 6.5.0 on i586-pc-linux-gnu, compiled by gcc egcs-2.91.66]

type \? for help on slash commands
type \q to quit
type \g or terminate with semicolon to execute query
You are currently connected to the database: david

david=> create table t (e oid);
CREATE
david=> insert into t values (lo_import('/tmp/1'));
INSERT 19000 1
david=> \d
Database    = david
+------------------+----------------------------------+----------+
|  Owner           |             Relation             |   Type   |
+------------------+----------------------------------+----------+
| david            | t                                | table    |
| david            | xinx18986                        | index    |
+------------------+----------------------------------+----------+

david=> select textout(byteaout(odata)) from xinv18986;
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
We have lost the connection to the backend, so further processing is impossible. Terminating.

And in log is:
Jun 2 22:56:27 chameleon PGSQL: FATAL 1: Memory exhausted in AllocSetAlloc()

================================
File /tmp/1 contains:
djdjd
djdjdjd
djdjdjdjdjdj
ddjdjdjjd
djdjdjjjdjdjdjdjd
djdjdj

This example doesn't have good meaning, but I dont like crash of my
database ...

Yes, I see your point.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

David Sauer <davids@orfinet.cz> writes:

david=> select textout(byteaout(odata)) from xinv18986;
pqReadData() -- backend closed the channel unexpectedly.

I think this is not related to large objects per se --- it's a
typechecking failure. textout is expecting a text datum, and it's
not getting one because that's not what comes out of byteaout.
(The proximate cause of the crash is that textout tries to interpret
the first four bytes of byteaout's output as a varlena length...)

The parser's typechecking machinery is unable to catch this
error because textout is declared to take any parameter type
whatever (its proargtype is 0).

Why don't the type output functions have the correct input types
declared for them in pg_proc???

For that matter, why do we allow user expressions to call the type
input/output functions at all? They're not really usable as SQL
functions AFAICS...

regards, tom lane

David Sauer <davids@orfinet.cz> writes:

david=> select textout(byteaout(odata)) from xinv18986;
pqReadData() -- backend closed the channel unexpectedly.

I think this is not related to large objects per se --- it's a
typechecking failure. textout is expecting a text datum, and it's
not getting one because that's not what comes out of byteaout.
(The proximate cause of the crash is that textout tries to interpret
the first four bytes of byteaout's output as a varlena length...)

The parser's typechecking machinery is unable to catch this
error because textout is declared to take any parameter type
whatever (its proargtype is 0).

Why don't the type output functions have the correct input types
declared for them in pg_proc???

For that matter, why do we allow user expressions to call the type
input/output functions at all? They're not really usable as SQL
functions AFAICS...

Yes, they take C pointers, don't they. You can't return one of those in
any SQL function or column name.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

For that matter, why do we allow user expressions to call the type
input/output functions at all? They're not really usable as SQL
functions AFAICS...

What probably happened is that those are in the system catalogs, but are
assigned a zero for input, rather than a non-valid oid. Does zero mean
any type? I guess so.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

For that matter, why do we allow user expressions to call the type
input/output functions at all? They're not really usable as SQL
functions AFAICS...

Yes, they take C pointers, don't they. You can't return one of those in
any SQL function or column name.

Doing textout(byteaout(... really makes no sense. But being
able to do a textin(mytypeout(... does make sense for me.
Without that, there MUST be type casting support for
MYTYPE->TEXT in the parser.

Sometimes ppl implement user defined types. I assume this
kind of type casting is used somewhere in a couple of
applications.

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

wieck@debis.com (Jan Wieck) writes:

For that matter, why do we allow user expressions to call the type
input/output functions at all? They're not really usable as SQL
functions AFAICS...

Doing textout(byteaout(... really makes no sense. But being
able to do a textin(mytypeout(... does make sense for me.
Without that, there MUST be type casting support for
MYTYPE->TEXT in the parser.

The real problem here is that the type system needs to have a notion
of "C string" as a datatype so that the type input and output functions
can be declared *properly* with the true nature of their inputs and
results given correctly. Then typeain(typebout(typebvalue)) would work
and textout(byteaout(...)) would be rejected, as it should be.

The typechecking escape convention (zero in the proargtypes signature)
should only be used for functions that really do accept any kind of
datum. I think there are some (count(*) for one) but not many.

The "C string" type is not quite a real type, because we don't want to
let people declare columns of that type (I assume). OTOH it must be
real enough to let people declare user-defined functions that accept or
return it. Right now, the I/O functions for user-defined types are
supposed to be declared to take or return type OPAQUE, but I think
that pseudo-type is being used for too many different things.

Obviously none of this is going to happen for 6.5, but it should go
on the TODO list.

regards, tom lane

Added to TODO:

* Fix typein/out functions to not be user-callable

David Sauer <davids@orfinet.cz> writes:

david=> select textout(byteaout(odata)) from xinv18986;
pqReadData() -- backend closed the channel unexpectedly.

I think this is not related to large objects per se --- it's a
typechecking failure. textout is expecting a text datum, and it's
not getting one because that's not what comes out of byteaout.
(The proximate cause of the crash is that textout tries to interpret
the first four bytes of byteaout's output as a varlena length...)

The parser's typechecking machinery is unable to catch this
error because textout is declared to take any parameter type
whatever (its proargtype is 0).

Why don't the type output functions have the correct input types
declared for them in pg_proc???

For that matter, why do we allow user expressions to call the type
input/output functions at all? They're not really usable as SQL
functions AFAICS...

regards, tom lane

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Removed from TODO list:

* Fix typein/out functions to not be user-callable

For that matter, why do we allow user expressions to call the type
input/output functions at all? They're not really usable as SQL
functions AFAICS...

Yes, they take C pointers, don't they. You can't return one of those in
any SQL function or column name.

Doing textout(byteaout(... really makes no sense. But being
able to do a textin(mytypeout(... does make sense for me.
Without that, there MUST be type casting support for
MYTYPE->TEXT in the parser.

Sometimes ppl implement user defined types. I assume this
kind of type casting is used somewhere in a couple of
applications.

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                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Re-added to TODO list :-)

* Fix typein/out functions to not be user-callable

wieck@debis.com (Jan Wieck) writes:

For that matter, why do we allow user expressions to call the type
input/output functions at all? They're not really usable as SQL
functions AFAICS...

Doing textout(byteaout(... really makes no sense. But being
able to do a textin(mytypeout(... does make sense for me.
Without that, there MUST be type casting support for
MYTYPE->TEXT in the parser.

The real problem here is that the type system needs to have a notion
of "C string" as a datatype so that the type input and output functions
can be declared *properly* with the true nature of their inputs and
results given correctly. Then typeain(typebout(typebvalue)) would work
and textout(byteaout(...)) would be rejected, as it should be.

The typechecking escape convention (zero in the proargtypes signature)
should only be used for functions that really do accept any kind of
datum. I think there are some (count(*) for one) but not many.

The "C string" type is not quite a real type, because we don't want to
let people declare columns of that type (I assume). OTOH it must be
real enough to let people declare user-defined functions that accept or
return it. Right now, the I/O functions for user-defined types are
supposed to be declared to take or return type OPAQUE, but I think
that pseudo-type is being used for too many different things.

Obviously none of this is going to happen for 6.5, but it should go
on the TODO list.

regards, tom lane

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <maillist@candle.pha.pa.us> writes:

Re-added to TODO list :-)

* Fix typein/out functions to not be user-callable

Please rephrase it:

* Declare typein/out functions in pg_proc with a special "C string" data type

We want to type-check their uses correctly, not forbid their use.

regards, tom lane