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
Michael Paquier writes:
> This patch seems to have little incidence on the stability, but FWIW I
> am not cool with the concept of asking for objections and commit a
> patch only 4 hours after-the-fact, particularly after feature freeze.
FWIW, I figured it was okay since ECPG has essentially no
> This patch seems to have little incidence on the stability, but FWIW
> I
> am not cool with the concept of asking for objections and commit a
> patch only 4 hours after-the-fact, particularly after feature freeze.
This was only done to beat the pg_indent run as Tom pointed out. I
figured worse
On Wed, May 22, 2019 at 05:10:14AM +0200, Michael Meskes wrote:
> Thanks for the heads-up Tom, pushed.
>
> And thanks to Matsumura-san for the patch.
This patch seems to have little incidence on the stability, but FWIW I
am not cool with the concept of asking for objections and commit a
patch
> None here. You might want to get it in in the next 12 hours or so
> so you don't have to rebase over a pgindent run.
Thanks for the heads-up Tom, pushed.
And thanks to Matsumura-san for the patch.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael Meskes writes:
> Unless somebody objects I will commit it as soon as I have time at
> hand. Given that this patch also and mostly fixes some completely
> broken old logic I'm tempted to do so despite us being pretty far in
> the release cycle. Any objections?
None here. You might want
Hi Matsumura-san,
> (1)
> I attach a new patch. Please review it.
> ...
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.
Unless somebody objects I
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
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
Hi Matsumura-san,
> I defined the following specifications. Please review it.
>
> * ECPG can accept any valid PREPARE AS statement.
> * A char-type host variable can be used as the statement name of
> PREPARE AS,
> but its value is constrained by the specification of PREPARE AS.
> (e.g. the
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
Hi Matsumura-san,
> If we also allow the statement name including white space in PREPRARE
> AS,
> we have to make backend parser to scan it as IDENT.
Correct, without quoting would only work when using PQprepare() et al.
> I cannot think of anything.
> I may notice if I try to merge.
Thanks.
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
Matsumura-san,
> Therefore, I think that the quoting statement name is needed in
> PREPARE/EXECUTE case, too.
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
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
Hi all and thank you Matsumura-san.
> 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().
Sure, let's do this at the very end.
> 1. Specification
> It accepts the following .pgc.
>
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.
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
Hi all,
> ...
> But it doesn't allow to use host variable in parameter clause of
> EXECUTE statement like the following.
> I'm afraid that it's not usefull. I will research the standard and
> other RDBMS.
> If you have some information, please adivise to me.
This also seems to be conflicting
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',
Hi Matsumura-san,
> I must use a midrule action like the following that works as
> expected.
> I wonder how to write the replacement to ecpg.addons.
> I think it's impossible, right? Please give me some advice.
You are right, for this change you have to replace the whole rule. This
cannot be
...@postgresql.org'
> Subject: Re: SQL statement PREPARE does not work in ECPG
>
> Hi Matsumura-san,
>
> > I will read README.parser, ecpg.addons, and *.pl to understand.
>
> Feel free to ask, when anything comes up.
>
> Michael
> --
> Michael Meskes
> Michael at
Hi Matsumura-san,
> I will read README.parser, ecpg.addons, and *.pl to understand.
Feel free to ask, when anything comes up.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes
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
> >
Hi Matsumura-san,
> But I will probably be late because I don't understand parse.pl very
> well.
> I think that the following rule is made by parse.pl.
>
>PreparableStmt:
>SelectStmt
>{
>is_in_preparable_stmt = true; <--- I want to add it.
>$$ = $1;
>
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"
> -
Hi Matsumura-san,
Thank you for your explaining.
> An important point of the route is that it calls PQprepare() and PQprepare()
> needs type-Oid list. (Idea-1) If we fix for Prepare statement with AS clause
> and
> with parameter list to walk through the route, preprocessor must parse the
>
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
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 ||
Takahashi-san,
> It works well for my statement
>
> "EXEC SQL PREPARE test_prep (int) AS SELECT id from test_table where
> id = $1;".
>
> However, since data type information is not used, it does not works
> well
> for prepare statements which need data type information such as
> "EXEC SQL
Hi Meskes-san,
> Ah right, my bad. The workaround should have been:
Thank you. It works.
> As for the PREPARE statement itself, could you try the attached small
> patch please.
It works well for my statement
"EXEC SQL PREPARE test_prep (int) AS SELECT id from test_table where id = $1;".
Takahashi-san,
> EXEC SQL EXECUTE test_prep (2);
Could you please also verify for me if this works correctly if you use
a variable instead of the const? As in:
EXEC SQL BEGIN DECLARE SECTION;
int i=2;
EXEC SQL END DECLARE SECTION;
...
EXEC SQL EXECUTE test_prep (:i);
I guess the problem is
Takahashi-san,
> I tried as follows.
> ...
> Unfortunately, this does not work.
> ECPGst_execute seems good, but prepare statement is the same as my
> first post.
Ah right, my bad. The workaround should have been:
EXEC SQL PREPARE test_prep from "SELECT id from test_table where id =
$1";
EXEC
Matsumura-san,
> Maybe, there is no work-around.
Did you analyze the bug? Do you know where it comes from?
> For supporting it, there are two steps.
Could you please start with explaining where you see the problem? I'm
actually not sure what you are trying to do here.
Michael
--
Michael
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
Hi Meskes-san,
Thank you for your replying.
> Please try this instead:
>
> EXEC SQL PREPARE test_prep (int) AS SELECT id from test_table where id
> = $1;
> EXEC SQL EXECUTE test_prep using 2;
>
> This should work.
I tried as follows.
EXEC SQL PREPARE
> I think SQL statement PREPARE *without* parameter is supported,
> but one with parameter is not supported (or has some fatal bugs).
It surely should be supported.
>> I wrote the source code as follows.
>>
>>
>> EXEC SQL PREPARE test_prep (int) AS SELECT id from
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
38 matches
Mail list logo
