From: | Alvaro Herrera <alvherre(at)atentus(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: help needed with CREATE CONVERSION |
Date: | 2002-07-13 19:35:55 |
Message-ID: | Pine.LNX.4.44.0207131532430.7008-100000@cm-lcon1-46-187.cm.vtr.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane dijo:
> Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> > I encountered a problem while implementing new CREATE
> > CONVERSION. Since converion procs are dynamically invoked while doing
> > an encoding conversion, it might fail for some reasons:
>
> > (2) buggy conversion proc is defined by a user
>
> This I think we have to be concerned about; there will always be the
> possibility of a failure in the conversion proc.
>
> > Problem is, in any case mentioned above, an ERROR is raised and
> > backend tries to send an error message which again raise an ERROR. As
> > a result, backend goes into an infinite loop.
What about having a separate elog() category that evades the conversion
stuff, so if something fails in character conversion it doesn't get
called again? Some way to ``disable'' recursion in elog().
--
Alvaro Herrera (<alvherre[a]atentus.com>)
Licensee shall have no right to use the Licensed Software
for productive or commercial use. (Licencia de StarOffice 6.0 beta)
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-07-13 20:08:46 | Re: Memo on dropping practices |
Previous Message | Tom Lane | 2002-07-13 17:12:16 | Re: help needed with CREATE CONVERSION |