From: | wieck(at)debis(dot)com (Jan Wieck) |
---|---|
To: | maillist(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian) |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, davids(at)orfinet(dot)cz, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] current CVS snapshot of pgsql crash ... |
Date: | 1999-06-03 10:39:05 |
Message-ID: | m10pUtt-0003kGC@orion.SAPserv.Hamburg.dsh.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)debis(dot)com (Jan Wieck) #
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 1999-06-03 12:16:33 | Re: [HACKERS] Re: Freezing docs for v6.5 |
Previous Message | Tom Lane | 1999-06-03 06:22:56 | Re: [HACKERS] Backends waiting, spinlocks, shared mem patches |