Re: moving FE->BE encoding conversion

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: moving FE->BE encoding conversion
Date: 2002-08-07 14:42:37
Message-ID: 20020807.234237.28785529.t-ishii@sra.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Lamar Owen 2002-08-07 14:43:20 Re: Open 7.3 items
Previous Message Hannu Krosing 2002-08-07 14:38:47 Re: Why is MySQL more chosen over PostgreSQL?