From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: help needed with CREATE CONVERSION |
Date: | 2002-07-13 17:12:16 |
Message-ID: | 4013.1026580336@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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:
> (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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2002-07-13 19:35:55 | Re: help needed with CREATE CONVERSION |
Previous Message | Tom Lane | 2002-07-13 17:07:52 | Re: [COMMITTERS] pgsql/ oc/src/sgml/catalogs.sgml oc/src/sgml/r ... |