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

                                        thanks,

-- 
* David Sauer, student of Czech Technical University
* electronic mail: davids@orfinet.cz (mime compatible)

02 Jun 1999 23:00:40 +0200
David Sauer <davids@orfinet.cz>
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

Wed, 2 Jun 1999 17:21:28 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] current CVS snapshot of pgsql crash ...
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

Wed, 02 Jun 1999 19:51:26 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] current CVS snapshot of pgsql crash ... 
> 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

Wed, 2 Jun 1999 20:16:59 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] current CVS snapshot of pgsql crash ...
> 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

Wed, 2 Jun 1999 20:17:51 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] current CVS snapshot of pgsql crash ...
> > 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) #



Thu, 3 Jun 1999 12:39:05 +0200 (MET DST)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] current CVS snapshot of pgsql crash ...
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

Thu, 03 Jun 1999 10:25:05 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] current CVS snapshot of pgsql crash ... 

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

Wed, 7 Jul 1999 19:52:12 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] current CVS snapshot of pgsql crash ...


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

Wed, 7 Jul 1999 19:54:02 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] current CVS snapshot of pgsql crash ...

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

Wed, 7 Jul 1999 19:55:15 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] current CVS snapshot of pgsql crash ...
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


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

Wed, 07 Jul 1999 20:03:26 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] current CVS snapshot of pgsql crash ... 