Обсуждение: moving FE->BE encoding conversion

Since the encoding conversion now looks up database, it must be
done within a transaction. Currently the encoding conversion function
pg_client_to_server() is called in pq_getstr(), which may not be in a
transaction. So I would like to move the call to pg_client_to_server()
within pg_exec_query_string(), after start_xact_command() gets called.
Comments?
--
Tatsuo Ishii

Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> Since the encoding conversion now looks up database, it must be
> done within a transaction.

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?

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.
        regards, tom lane

> 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

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

OidFunctionCallN will not work, but I believe it would work to
construct an FmgrInfo record during the SET operation, keep that, and
use FunctionCallN when you need to invoke the converter.  This will
definitely work for built-in and new-style dynamically loaded C
functions, and that's probably all we need/want to support anyway.
        regards, tom lane

> OidFunctionCallN will not work, but I believe it would work to
> construct an FmgrInfo record during the SET operation, keep that, and
> use FunctionCallN when you need to invoke the converter.  This will
> definitely work for built-in and new-style dynamically loaded C
> functions, and that's probably all we need/want to support anyway.

Ok, I have committed changes per your suggestion.
--
Tatsuo Ishii