Re: [HACKERS] current CVS snapshot of pgsql crash ... - Mailing list pgsql-hackers

From wieck@debis.com (Jan Wieck)
Subject Re: [HACKERS] current CVS snapshot of pgsql crash ...
Date
Msg-id m10pUtt-0003kGC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
In response to Re: [HACKERS] current CVS snapshot of pgsql crash ...  (Bruce Momjian <maillist@candle.pha.pa.us>)
Responses Re: [HACKERS] current CVS snapshot of pgsql crash ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] current CVS snapshot of pgsql crash ...  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
> > 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) #

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Backends waiting, spinlocks, shared mem patches
Next
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] Re: Freezing docs for v6.5