> I still think that this is a fundamentally unworkable design. How will
> you deal with reporting errors outside a transaction, or for that matter
> inside an already-failed transaction?
In those cases we could detect the state and could do no conversion.
> ISTM the conversion function *must* be kept as a persistent state
> variable, with an initial default of "no conversion", and the actual
> setting done via a SET command (which can do the lookup inside a
> transaction). Then you can use the current conversion function without
> any assumptions about transaction state.
Are you saying keeping conversion function's oids in memory after
current conversion is explicitly set by SET command or others? Even
if we do that, fmgr might want to look up pg_proc to load the
functions outside the transaction, no?
Or are you saying we should load the functions when the SET command is
executed? I'm not sure if OidFunctionCall could invoke the function
without looking up pg_proc in this case.
--
Tatsuo Ishii
