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:

(1) stale pg_conversion entry. If someone re-register that proc, the
    oid might be changed and the reference from pg_conversion to
    pg_proc becomes stale.

(2) buggy conversion proc is defined by a user

(3) schema search path changed. Since conversion is schema aware, if
    someone sets a wrong schema path, the conversion proc might not be
    found anymore. This is actually not a problem right now, since in
    this case a conversion search would be performed on pg_catalog
    name space which should always be exist. However I am a little bit
    worried about this.

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.

I have to do some syscache searches aginst pg_proc before calling
conversion proc using fmgr, since there seems no API for checking that
conversion proc surely exists without throwing an ERROR. This is ugly
and is not ideal IMO.

Any idea?
--
Tatsuo Ishii

Sat, 13 Jul 2002 15:25:32 +0900 (JST)
Tatsuo Ishii <t-ishii@sra.co.jp>
help needed with CREATE CONVERSION
Tatsuo Ishii <t-ishii@sra.co.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:

> (1) stale pg_conversion entry. If someone re-register that proc, the
>     oid might be changed and the reference from pg_conversion to
>     pg_proc becomes stale.

This could (and should IMHO) be prevented with a dependency.

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

> (3) schema search path changed.

I do not see how that's an issue.  The conversion proc is referred to
by OID, no?

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

As long as we can restrict this failure to the case of a buggy
conversion proc, I think the risk can be lived with.  Buggy C code
can cause crashes in plenty of ways ;-)

			regards, tom lane

Sat, 13 Jul 2002 13:12:16 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: help needed with CREATE CONVERSION 
Tom Lane dijo: 

> Tatsuo Ishii <t-ishii@sra.co.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)


Sat, 13 Jul 2002 15:35:55 -0400 (CLT)
Alvaro Herrera <alvherre@atentus.com>
Re: help needed with CREATE CONVERSION 