RE: Is PREPARE of ecpglib thread safe?

From: "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>, "matsumura(dot)ryo(at)jp(dot)fujitsu(dot)com" <matsumura(dot)ryo(at)jp(dot)fujitsu(dot)com>, 'Kyotaro HORIGUCHI' <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: Is PREPARE of ecpglib thread safe?
Date: 2019-06-13 05:53:19
Message-ID: OSAPR01MB20048298F882D25897C6AB23F5EF0@OSAPR01MB2004.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear all,

I apologize for my late reply.
I realized that the current implementation could not imitate the oracle's precompiler.
The attached example can be accepted by both precompilers, but building the c file made by ecpg fails.

For handling this source, we have to refactor some sources related with DECLARE STATEMENT.
My draft amendment is converting the sentence from executable to declarative, that is:

* change to operate only if a pgc file is precompiled
* remove related code from ecpglib directory

In this case, the namespace of a SQL identifier is file independent, and
sources becomes more simple.

I will start making patches.
Do you have any comments or suggestions?

Best Regards.
Hayato Kuroda
Fujitsu LIMITED

Attachment Content-Type Size
output.txt text/plain 106 bytes
test.pgc application/octet-stream 129 bytes

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tsunakawa, Takayuki 2019-06-13 05:57:50 RE: [PATCH] Speedup truncates of relation forks
Previous Message Iwata, Aya 2019-06-13 05:43:21 RE: libpq debug log