RE: [Patch] PQconnectPoll() is blocked if target_session_attrs is read-write

Tsunakawa-san Thank you for your comment. I understand the sense. I don't require an explicit rule. Regards Ryo Matsumura

RE: [Patch] PQconnectPoll() is blocked if target_session_attrs is read-write

Kyotaro-san Thank you for your review. > First, this patch looks broken. I took a serious mistake. > You also need to update the corresponding documentation. I attach a new patch that includes updating of document. Regards Ryo Matasumura libpq_state_change_bugfix.ver1.1.patch Description: l

[Patch] PQconnectPoll() is blocked if target_session_attrs is read-write

Hi # I rewrote my previous mail. PQconnectPoll() is used as method for asynchronous using externally or internally. If a caller confirms a socket ready for writing or reading that is requested by return value of previous PQconnectPoll(), next PQconnectPoll() must not be blocked. But if the calle

A suspicious code in PQconnectPoll()

Hi I find a suspicious code in libpq:PQconnectPoll(). I think it should be fixed, but I could not produce a concrete problem. What do you think about it? I understand that PQconnectPoll() returns PGRES_POLLING_WRITING or PGRES_POLLING_READ until state machine reaches terminal state(OK or BAD). Th

RE: Bug: ECPG: Cannot use CREATE AS EXECUTE statemnt

Meskes-san Thank you for your comment. I attach a patch. It doesn't include tests, but it passed some test(*1). Explanation about the patch: - Add a new ECPGst_exec_embedded_in_other_stmt whether EXECUTE statement has exprlist or not. This type name may not be good. It is a type for [CRE

RE: [PATCH] memory leak in ecpglib

Hi On Mon. June. 10, 2019 at 09:54 AM Zhang, Jie < zhangj...@cn.fujitsu.com > wrote: > > Memory leaks occur when the ecpg_update_declare_statement() is called the > second time. Certainly it is. But I wonder if it is safe that the old cursor_name is forgotten. Regards Ryo Matsumura > -Ori

Bug: ECPG: Cannot use CREATE AS EXECUTE statemnt

Meskes-san This thread is branched from the following. https://www.postgresql.org/message-id/03040DFF97E6E54E88D3BFEE5F5480F74ABEADE7@G01JPEXMBYT04 > > Type1. Bugs or intentional unsupported features. > > - EXPLAIN EXECUTE > > - **CREATE TABLE AS with using clause** I noticed that CREATE AS

RE: SQL statement PREPARE does not work in ECPG

Meskes-san > This looks good to me. It passes all my tests, too. > > There were two minor issues, the regression test did not run and gcc > complained about the indentation in ECPGprepare(). Both I easily fixed. Thank you so much ! > > (2) > > I found some bugs (two types). I didn't fix them an

RE: Patch: doc for pg_logical_emit_message()

On Thu. May. 9, 2019 at 01:48 AM Masao, Fujii wrote: > Thanks! Pushed. Thank you. Regards Ryo Matsumura

RE: SQL statement PREPARE does not work in ECPG

Hi Meskes-san There are two points. (1) I attach a new patch. Please review it. - Preproc replaces any prepared_name to "$0" and changes it to an input-variable for PREARE with typelist and EXECUTE with paramlist. $0 is replaced in ecpg_build_params(). It's enable not to change EC

RE: SQL statement PREPARE does not work in ECPG

Meskes-san > This look very reasonable to me. I'm completely fine with this > restriction being placed on PREPARE FROM. Thank you. I start making a new patch. Regards Ryo Matsumura

RE: SQL statement PREPARE does not work in ECPG

Hi, Meskes-san I'm sorry for my long blank. I restarted. Review of previous discussion: I made a patch that makes ecpglib to send "PREPARE st(typelist) AS PreparableStmt" with PQexec(), because the type resolution is difficult. I tried to merge PREPARE FROM that uses PQprepare() to the PREPARE A

RE: Patch: doc for pg_logical_emit_message()

On Wed. Apr. 24, 2019 at 11:40 PM Masao, Fujii wrote: Thank you for the comment. I understand about REPLICATION privilege and notice my unecessary words. I update the patch. Regards Ryo Matsumura pg_logical_emit_message_doc_v1_2.patch Description: pg_logical_emit_message_doc_v1_2.patch

RE: Patch: doc for pg_logical_emit_message()

On Tue. Apr. 23, 2019 at 02:59 AM Masao, Fujii wrote: Thank you for the comment. > So I think that the patch should fix also the description for those > replication functions. Thought? I think so too. I attach a new patch. Regards Ryo Matsumura replication_functions_doc.patch Description: re

Patch: doc for pg_logical_emit_message()

Hi, Hackers pg_logical_emit_message() can be used by any user, but the following document says that it can be used by only superuser. > Table 9.88. Replication SQL Functions > Use of these functions is restricted to superusers. I think that pg_logicl_emit_message() should be used by any user. Th

RE: Qestion about .partial WAL file

Michael-san Thank for your advice. > then a promoted standby which archives WAL segments in the same > location as the primary > if the previous primary is still running after the standby I could not come up with the combination, but I understand now. Sorry for bothering you. Regards Ryo Matsu

Qestion about .partial WAL file

Hi, Hackers I noticed something strange. Does it cause nothing? I didn't detect anything, but feel restless. Step: - There are two standbys that connect to primary. - Kill primary and promote one standby. - Restart another standby that is reset primary_conninfo to connect new primary. I expected

RE: SQL statement PREPARE does not work in ECPG

Meskes-san I'm sorry for my slow reply. > I agree that we have to accept a quoted statement name and your > observations are correct of course, I am merely wondering if we need > the escaped quotes in the call to the ecpg functions or the libpq > functions. The following allows to use statement

RE: SQL statement PREPARE does not work in ECPG

Meskes-san Thank you for your comment. > One question though, why is the statement name always quoted? Do we > really need that? Seems to be more of a hassle than and advantage. The following can be accepted by preproc, ecpglib, libpq, and backend in previous versions. exec sql prepare "st x"

RE: Is PREPARE of ecpglib thread safe?

Horiguchi-san, Kuroda-san > Horiguchi-san wrote: > > A namespace of declared statement is not connection independent. > > Therefore, we must manage the namespce in global and consider about race > > condition. > > Right, and but thread independent. I was wrong. I understand that DECLARE STATEME

RE: Is PREPARE of ecpglib thread safe?

Hi Horiguchi-san, Kuroda-san Horiguchi-san, thank you for your comment. I have a question. A bug of StatementCache is occurred in previous versions. Should a patch be separated? > Horiguchi-san wrote: > It seems like a local cache of server-side data, which is similar > to catcache on server sid

RE: Is PREPARE of ecpglib thread safe?

Horiguchi-san Thank you for your comment. > A connection cannot be concurrently used by multiple threads so > the programmer must guard connections using mutex [1] or > friends. If it is done by a single mutex (I suppose it is > common.), there's no race condition also on the prepared > statement

Is PREPARE of ecpglib thread safe?

Hi I'm afraid that PREPARE of ecpglib is not thread safe. The following global variables are modified without any locking system. Is it unnecessary worry? [interfaces/ecpg/ecpglib/prepare.c] static int nextStmtID = 1; static stmtCacheEntry *stmtCacheEntries = NULL; static struct declared

RE: SQL statement PREPARE does not work in ECPG

Hi Meskes-san cc: Takahashi-san, Kuroda-san, Ideriha-san I attach a new patch. Please review it. Excuse: It doesn't include regression tests and pass them. Because I must reset all expected C program of regression. # I add an argument to ECPGdo(). I explain the patch as follows: 1. Spec

RE: ECPG regression with DECLARE STATEMENT support

Hi Kurokawa-san I reviewd it. It's ok. I also confirm there is no same bug. Regards Ryo Matsumura

RE: ECPG regression with DECLARE STATEMENT support

Hi Kuroda-san I think that the 2nd argument of following ecpg_init() must be real_connection_name. Is it right? ECPGdeallocate(int lineno, int c, const char *connection_name, const char *name) : con = ecpg_get_connection(real_connection_name); if (!ecpg_init(con, connection_name, lineno)

RE: SQL statement PREPARE does not work in ECPG

Hi Meskes-san Thank you for your comment. I write three points in this mail. 1. > This also seems to be conflicting with > bd7c95f0c1a38becffceb3ea7234d57167f6d4bf. If we want to keep this > commit in for the release, I think we need to get these things fixed. I understand it. My idea is that a

RE: SQL statement PREPARE does not work in ECPG

Hi Meskes-san Thank you for your advice. I attach a patch. I didn't add additional tests to regression yet. The patch allows the following: exec sql prepare(int) as select $1; 　exec sql execute st(1) into :out; exec sql prepare(text, text) as select $1 || $2; 　exec sql execute st('aaa',

RE: SQL statement PREPARE does not work in ECPG

false; } | PREPARE prepared_name FROM execstring Regards Ryo Matsumura > -Original Message- > From: Michael Meskes [mailto:mes...@postgresql.org] > Sent: Friday, March 1, 2019 8:42 PM > To: Matsumura, Ryo/松村 量 ; Takahashi, > Ryohei/高橋 良平 ; > '

RE: SQL statement PREPARE does not work in ECPG

Meskes-san Thank you for your comment. > The only way to add this is by creating a replacement production for > this rule. parse.pl cannot do it itself. I will read README.parser, ecpg.addons, and *.pl to understand. > > I will use @1 instend of $$1 because the replacing is almost same as > > t

RE: SQL statement PREPARE does not work in ECPG

Hi Meskes-san, Takahashi-san > If the standard allows it, we want to be able to process it. I will try to implement it with the Idea-2 that doesn't use PQprepare() and Takahasi-san's following idea. > For example, > - ECPG convert ":ID" to "$1" and "$1" in the original statement to "$$1" > - n

RE: SQL statement PREPARE does not work in ECPG

Meskes-san I made mistake. > The checking (line-1495) is meaningless for AS clause. > It checks if all $0 is replaced to literal and all ? is replaced to $[0-9]* > by insert_tobeinserted(), > but it always fails because $[0-9]* in AS clause are not replaced (and should > not be replaced). > I d

RE: SQL statement PREPARE does not work in ECPG

Meskes-san > Did you analyze the bug? Do you know where it comes from? At first, I show the flow of Prepare statement without AS clause and the flow of Prepare statement with AS clause but without parameter list. [preproc/preproc.y] 1832 | PrepareStmt 1834 if ($1.type == NULL || strlen($1.ty

RE: SQL statement PREPARE does not work in ECPG

Hi, Maybe, there is no work-around. For supporting it, there are two steps. step1. fix for PREPARE. step2. fix for EXECUTE. About step1, there are two way. I want to choose Idea-2. Idea-1. ecpglib prepares Oids of type listed in PREPARE statement for 5th argument of PQprepare(). But it's dif

RE: SQL statement PREPARE does not work in ECPG

Hi I think SQL statement PREPARE *without* parameter is supported, but one with parameter is not supported (or has some fatal bugs). Because route for SQL statement PREPARE (line-1837 of preproc.y) always has output an invalid SQL statement and there is no regression test for SQL statement PREPA

RE: [PROPOSAL]a new data type 'bytea' for ECPG

Meskes-san > This looks very good. Committed to HEAD. Thank you so match. Regards Ryo Matsumura

RE: [PROPOSAL]a new data type 'bytea' for ECPG

Meskes-san I attach a new patch. - ECPGset_desc and ecpg_build_params are changed. - implement Idea-2. - get if(is_binary)-block out from main flow to new functions (set_desc_attr, store_input_from_desc). Regards Ryo Matsumura ecpg_bytea_v1_4.patch Description: ecpg_bytea_v1_4.patch

RE: [PROPOSAL]a new data type 'bytea' for ECPG

tobeinserted; Regards Ryo Matsumura > -Original Message- > From: Michael Meskes [mailto:mes...@postgresql.org] > Sent: Wednesday, February 13, 2019 9:09 PM > To: Matsumura, Ryo/松村 量 > Cc: Tsunakawa, Takayuki/綱川 貴之 ; > pgsql-hackers@lists.postgresql.org > Subject: Re: [PRO

RE: [PROPOSAL]a new data type 'bytea' for ECPG

re_input: if (descriptor_item.is_binary) memcpy(&tobeinserted, descriptor_item.data, descriptor_item.data_len) Thank you. Ryo Matsumura > -Original Message- > From: Michael Meskes [mailto:mes...@postgresql.org] > Sent: Tuesday, February 12, 2019 11:06 PM > To: Matsumu

RE: [PROPOSAL]a new data type 'bytea' for ECPG

Meskes-san Thank you for your review. > There is one thing that I don't understand right now. YOu > change ecpg_store_input() to handle the bytea data type, yet you also > change ECPGset_desc() to not use ecpg_store_input() in case of an > bytea. This looks odd to me. Can you please explain that

RE: [PROPOSAL]a new data type 'bytea' for ECPG

2019 6:29 PM > To: Matsumura, Ryo/松村 量 > Cc: 'Michael Meskes' ; Tsunakawa, Takayuki/綱川 貴 > 之 ; pgsql-hackers@lists.postgresql.org > Subject: Re: [PROPOSAL]a new data type 'bytea' for ECPG > > Matsumura-san, > > > Sorry to bother you, but I would be g

RE: [PROPOSAL]a new data type 'bytea' for ECPG

Meskes-san Sorry to bother you, but I would be grateful if you would comment to me. Regards Ryo Matsumura > -Original Message- > From: Matsumura, Ryo [mailto:matsumura@jp.fujitsu.com] > Sent: Wednesday, December 19, 2018 7:05 PM > > Cc: pgsql-hackers@lists.postgresq

RE: [suggestion]support UNICODE host variables in ECPG

> * What's the benefit of supporting UTF16 in host variables? I think that the first benefit of suggestion is providing a way to treat UTF16 chars for application. Whether or not to support above U+ (e.g. surrogate pair) may be a next discussion. For that purpose, implementation for the sugge

RE: [PROPOSAL]a new data type 'bytea' for ECPG

Meskes-san > > I do think, though, we should change the debug output for > > ecpg_free_params(). > > I try to change about it. Next patch will print binary in hex-format. I implement and attach it. Please review a new patch in this mail. I have a question about ecpg manual when I add article

RE: [suggestion]support UNICODE host variables in ECPG

Nagaura-san I understand that the previous discussion pointed that the feature had better be implemented more simply or step-by-step and description about implementation is needed more. I also think it prevented the discussion to reach to the detail of feature. What is your opinion about it? Reg

RE: [PROPOSAL]a new data type 'bytea' for ECPG

Meskes-san I noticed that I was confused. My topic was about adding bytea as new host variable type. The topic *didn't* include that receiving binary format data into SQLDATA descriptor like the following. sqlda_t *sqlda; exec sql create table if not exists test (c1 bytea); exec sql select

RE: [PROPOSAL]a new data type 'bytea' for ECPG

Meskes-san Maybe I understand your comments about compatibility. I will try to implement for sqlda. # I am not goot at library version mechanism. # I will learn about it. Regards Ryo Matsumura

RE: [PROPOSAL]a new data type 'bytea' for ECPG

Meskes-san > > > > The patch does not support ECPG.bytea in sqltype of "struct > > > > sqlvar_struct" > > > > because of compatibility. > > > > Sorry I do not really understand what you mean. Could you please > > explain? > > I meaned that existing applications that receive data of bytea column

RE: [PROPOSAL]a new data type 'bytea' for ECPG

uct.sqltype. Regards Ryo Matsumura > -Original Message- > From: Michael Meskes [mailto:mes...@postgresql.org] > Sent: Wednesday, December 5, 2018 8:24 PM > To: Matsumura, Ryo/松村 量 ; Tsunakawa, > Takayuki/綱川 貴之 > Cc: pgsql-hackers@lists.postgresql.org > Subject: Re: [PROP

RE: [PROPOSAL]a new data type 'bytea' for ECPG

Meskes-san Sorry to bother you, but I hope any comment of yours. Regards Ryo Matsumura > Subject: RE: [PROPOSAL]a new data type 'bytea' for ECPG > > > From: Tsunakawa, Takayuki [mailto:tsunakawa.ta...@jp.fujitsu.com] > > > > I think the host variable data type that corresponds to the server-sid

RE: [PROPOSAL]a new data type 'bytea' for ECPG

> From: Tsunakawa, Takayuki [mailto:tsunakawa.ta...@jp.fujitsu.com] > > I think the host variable data type that corresponds to the server-side bytea > should be bytea. As the following pages state or imply, it would be better > to create standard-compliant LOB types someday, and use the keyword

RE: [PROPOSAL]a new data type 'bytea' for ECPG

nably possible. I think there is no special reason to follow to existing varchar. I can accept the standard. (Re-implementation is not difficult.) Thank you. Regards Ryo Matsumura > -Original Message- > From: Michael Meskes [mailto:mes...@postgresql.org] > Sent: Saturday,

RE: [PROPOSAL]a new data type 'bytea' for ECPG

Hi Michael Thank you for your comment. # Please call me Ryo. Matsumura is too long. > > I think that set/put data for host variable should be more simple. > > The following is an example of Oracle Pro *C program for RAW type > > column. > > Just to be clear, Oracle can use varchars for binary d

RE: [PROPOSAL]a new data type 'bytea' for ECPG

ernal area(struct descriptor_item) for execution phase, but doesn't save type information that is needed in case of bytea. So I add a member is_binary to descriptor_item structure. Thank you. Regards Ryo Matsumura > -Original Message- > From: Matsumura, Ryo [

[PROPOSAL]a new data type 'bytea' for ECPG

Hi, Hackers # This is my first post. I will try to implement a new data type 'bytea' for ECPG. I think that the implementation is not complicated. Does anyone need it ? * Why do I need bytea ? Currently, ECPG program can treat binary data for bytea column with 'char' type of C language, but it