Re: [HACKERS] Statement-level rollback
Hello, This feature hasn't been updated for a long time, but I've just been interested in this feature and looking into the mailing list. From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us] > In short, you can't make fundamental changes in transactional behavior without > enormous breakage. That was the lesson we learned from the autocommit fiasco > and I do not believe that it's inapplicable here. I've just wanted to confirm what "autocommit fiasco" points out. Are the below threads and git-log relevant discussion? (If there are any other threads, could you please tell me the link?) https://www.postgresql.org/message-id/flat/3E54526A.121EBEE5%40tpf.co.jp#3e54526a.121eb...@tpf.co.jp https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=f85f43dfb5b9043ea6b01d8b824c195cd7f9ed3c Regards, Takeshi Ideriha -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] visual studio 2017 build support
Hi I’ve noticed src/tools/msvc/README also needs some fix together with your patch. README discription haven’t updated since VS 2012. Regards Ideriha, Takeshi From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Haribabu Kommi Sent: Monday, April 24, 2017 1:24 PM To: pgsql-hackers@postgresql.org Subject: [HACKERS] visual studio 2017 build support Here I attached a small patch that adds the build support for visual studio 2017. The tools version number is still 14.X, irrespective of VS 2017 version of 15.0. I modified the versions accordingly. Regards, Hari Babu Fujitsu Australia
Re: [HACKERS] [WIP] RE: DECLARE STATEMENT setting up a connection in ECPG
Thank you for prompt check! >As per above test steps, it doesn't produce the results and doesn't >generate the error also. I feel this needs to be fixed. >As we are at the end of commitfest, it is better you can move it >to next one commitfest and provide an updated patch to solve the >above problem. I tottaly agreed. I moved to next CF with waiting on author. Regards, Ideriha Takeshi
Re: [HACKERS] [WIP] RE: DECLARE STATEMENT setting up a connection in ECPG
Thank you very much for thorough review and sorry for late replay.
Attched is 002_declareStmt_ecpglib_v7.patch and I haven't revised doc patch yet.
>002_declareStmt_ecpglib_v5.patch:
>+ struct connection *f = NULL;
>+
> ecpg_init_sqlca(sqlca);
> for (con = all_connections; con;)
> {
>- struct connection *f = con;
>+ f = con;
>What is the need of moving the structure declartion
>to outside, i didn't find any usage of it later.
Fixed.
>+ con = ecpg_get_connection(connection_name);
>+ if (!con)
>+ {
>+ return;
>+ }
>
>No need of {}.
Fixed.
>+ if (find_cursor(cursor_name, con))
>+ {
>+ /*
>+ * Should never goto here, because ECPG has checked the duplication of
>+ * the cursor in pre-compile stage.
>+ */
>+ return;
>+ }
>
>Do we really need this check? If it is for additional check, How about
>checking
>it with an Assert? (check for similar instances)
I remove the above check because we check the duplication when parsing
ECPGCursorStmt token at ecpg.trailer and in the existing master code we also
check the cursor name duplication only when pre-compilineg pgc code.
Regarding similar codes, I added ecpg_raise() assertion.
>+ if (!ecpg_init(con, real_connection_name, line))
>+ return false;
>
>What is the need of ecpg_init call? why the same is not done in other
>functions.
>Better if you provide some comments about the need of the function call.
Removed ecpg_init() and added checking if con exists or not.
>-#endif /* _ECPG_LIB_EXTERN_H */
>+#endif /* _ECPG_LIB_EXTERN_H */
>
>Not related change.
Fixed.
>+ * Find the declared name referred by the cursor,
>+ * then return the connection name used by the declared name.
>
>How about rewriting the above statement as follows? This is because
>we are not finding the declare name, as we are looping through all
>the declare statements for this cursor.
>
>"Find the connection name by referring the declared statements
>cursors by using the provided cursor name"
Fixed.
>+ struct declared_statement *cur = NULL;
>+ struct declared_statement *prev = NULL;
>+ struct declared_statement *next = NULL;
>
>The above logic can be written without "next" pointer.
>That way it should be simpler.
Fixed.
>-#endif /* _ECPGTYPE_H */
>+#endif /* _ECPGTYPE_H */
>
>Not related change.
Fixed.
>+ if(connection_name == NULL)
>+ {
>+ /*
>+ * Going to here means not using AT clause in the DECLARE STATEMENT
>+ * We don't allocate a node to store the declared name because the
>+ * DECLARE STATEMENT without using AT clause will be ignored.
>+ */
>+ return true;
>+ }
>
>I am not sure that just ignore the declare statement may be wrong.
>I feel whether such case is possible? Does the preprocessor allows it?
As you pointed out, the above thing should be discussed.
The current implementation is as follows:
ECPG pre-processor allows the DECLARE STATEMENT without using AT clause.
And the following statement after DECLARE STATEMENT such as PREPARE, EXECUTE
are
executed as usual on the current connection.
But there's a limitation here.
(This limitation should be disccused earlier and be specified in the doc...
but I didn't realize this clearly by myself, sorry)
When using DECLARE STATEMENT without AT clause
and using OPEN statement with AT clause, it doesn't work.
There's an example where you cannot fetch rows from db:
EXEC SQL CONNECT TO db AS con;
EXEC SQL DECLARE stmt STATEMENT;
EXEC SQL AT con PREPARE stmt FROM :selectString;
EXEC SQL AT con DECLARE cur CURSOR FOR stmt;
EXEC SQL AT con OPEN cur;
...
This limitation looks troublesome for users,
so maybe I need to fix this implementation.
regards,
Ideriha Takeshi
002_declareStmt_ecpglib_v7.patch
Description: 002_declareStmt_ecpglib_v7.patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Other formats in pset like markdown, rst, mediawiki
>>I like the idea taking advantage of linestyle utilities >>to implement rst and markdown format efficiently instead of newly developing >>pset format things. >>But I'm thinking two comments below needs change to something about not >>focusing only linestyle. >>That's because they really take care of both '\pset linestyle and \pset >>format' and it may lead to misunderstanding to readers. >> >>--- >>/* Line style control structures */ >>const printTextFormat pg_markdown = >> >>/* get selected or default line style */ >>const printTextFormat * >>get_line_style(const printTableOpt *opt) >>--- >It is in command.c? >I have it done that \pset format changes linestyle >psql (9.6.2, server 9.6.1) >Type "help" for help. >jelen=# \pset linestyle ascii >Line style is ascii. >jelen=# \pset format rst >Output format is rst. >jelen=# \pset linestyle >Line style is rst. >jelen=# >Peter wrote that this is not right, but i don`t know how it should like, >because most of this is done on linestyle, format is used only for switch from >console. Thank you for explanation! That's about print.c, but my explanation was poor... My point was a slight thing about comments in source code. I've just wanted to say comments needs change to match actual code. These comments says about line style but the corresponding codes are about both line style and format. But these points should be considered after how to implement the new formats are decided. So please don't care. (I've just thought implementing the new formats using linestyle code came into consensus.) Regards, Ideriha Takeshi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Other formats in pset like markdown, rst, mediawiki
Hi, I like your suggestion and took a look at your patch though I’m not the expert about psql. I like the idea taking advantage of linestyle utilities to implement rst and markdown format efficiently instead of newly developing pset format things. But I'm thinking two comments below needs change to something about not focusing only linestyle. That's because they really take care of both '\pset linestyle and \pset format' and it may lead to misunderstanding to readers. --- /* Line style control structures */ const printTextFormat pg_markdown = /* get selected or default line style */ const printTextFormat * get_line_style(const printTableOpt *opt) --- The rest things are about code style convention. - there are some indents with white spaces around skip_leading_spaces_print() but Postgresql conventions says indents should be with 4 column tab. https://www.postgresql.org/docs/devel/static/source-format.html - On the other hand, in docs there are some tab indent but white space indenet is preferable. Looking around sgml files, white space is used. - some multi-line comment style also needs fix according to the above documentation (link) - And I also found patch cannot be applied to current master. Regards, Ideriha, Takeshi From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Jan Michalek Sent: Sunday, March 19, 2017 5:10 AM To: Peter Eisentraut <peter.eisentr...@2ndquadrant.com> Cc: Pavel Stehule <pavel.steh...@gmail.com>; PostgreSQL mailing lists <pgsql-hackers@postgresql.org> Subject: Re: [HACKERS] Other formats in pset like markdown, rst, mediawiki 2017-03-12 19:21 GMT+01:00 Jan Michálek <godzilalal...@gmail.com<mailto:godzilalal...@gmail.com>>: 2017-03-10 9:43 GMT+01:00 Jan Michálek <godzilalal...@gmail.com<mailto:godzilalal...@gmail.com>>: 2017-03-09 20:10 GMT+01:00 Peter Eisentraut <peter.eisentr...@2ndquadrant.com<mailto:peter.eisentr...@2ndquadrant.com>>: This is looking pretty neat. I played around with it a bit. There are a couple of edge cases that you need to address, I think. Thanks, original code is very synoptical and and well prepared for adding new formats. - Does not support \x I know, i dnot`t know, if \x make sense in this case. I will look, how it is done in other formats like html. I think, that it should work in sense, that table generated to rst should give similar output after processing like output of html format. I prepared something like this (i have no prepared diff, i need do some another changes) There a few things I need to do. First problem is bold column names, i should do it in sme fashin as "RECORD", but i need to do some research about length of column. Bigger problem is with tab indent, rst processor doesn`t work with this in this case. In new diff is added \x for rst and skipping leading spaces in rst in both. make check passed Jan jelen=# execute q \g | xclip +-++ | **RECORD 1** | +-++ | column1 | Elephant, kangaroo, | | | squirrel, gorilla | +-++ | column2 | 121 | +-++ | column3 | 1.0035971223021583 | +-++ | column4 | 0. | +-++ | column5 | Hello Hello Hello Hello Hello Hello Hello Hello Hello Hello | +-++ | **RECORD 2** | +-++ | column1 | goat, rhinoceros, | | | monkey, ape | +-++ | column2 | 11121 | +-++ | column3 | 1.0007824726134585 | +-+
Re: [HACKERS] GUC for cleanup indexes threshold.
Hi, I tried regression test and found some errors concerning brin and gin,
though I didn't look into this.
Here's a log:
*** /home/ideriha/postgres-master/src/test/regress/expected/brin.out
2017-02-13 11:33:43.270942937 +0900
--- /home/ideriha/postgres-master/src/test/regress/results/brin.out
2017-02-15 14:58:24.725984474 +0900
***
*** 403,408
SELECT brin_summarize_new_values('brinidx'); -- ok, no change expected
brin_summarize_new_values
---
! 0
(1 row)
--- 403,408
SELECT brin_summarize_new_values('brinidx'); -- ok, no change expected
brin_summarize_new_values
---
! 5
(1 row)
==
*** /home/ideriha/postgres-master/src/test/regress/expected/gin.out
2016-12-20 16:49:09.513050050 +0900
--- /home/ideriha/postgres-master/src/test/regress/results/gin.out
2017-02-15 14:58:25.536984461 +0900
***
*** 20,26
select gin_clean_pending_list('gin_test_idx'); -- nothing to flush
gin_clean_pending_list
! 0
(1 row)
-- Test vacuuming
--- 20,26
select gin_clean_pending_list('gin_test_idx'); -- nothing to flush
gin_clean_pending_list
! 8
(1 row)
-- Test vacuuming
==
Regards,
Ideriha Takeshi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] multivariate statistics (v19)
Hi When you have time, could you rebase the pathes? Some patches cannot be applied to the current HEAD. 0001 patch can be applied but the following 0002 patch cannot be. I've just started reading your patch (mainly docs and README, not yet source code.) Though these are minor things, I've found some typos or mistakes in the document and README. >+ statistics on the table. The statistics will be created in the in the >+ current database. The statistics will be owned by the user issuing Regarding line 629 at 0002-PATCH-shared-infrastructure-and-ndistinct-coeffi-v22.patch, there is a double "in the". >+ knowledge of a value in the first column is sufficient for detemining the >+ value in the other column. Then functional dependencies are built on those Regarding line 701 at 0002-PATCH, "determining" is mistakenly spelled "detemining". >@@ -0,0 +1,98 @@ >+Multivariate statististics >+== Regarding line 2415 at 0002-PATCH, "statististics" should be statistics >+ >+ CREATE STATISTICS >+ define a new statistics >+ >+ >+ DROP STATISTICS >+ remove a statistics >+ Regarding line 612 and 771 at 0002-PATCH, I assume saying "multiple statistics" explicitly is easier to understand to users since these commands don't for the statistics we already have in the pg_statistics in my understanding. >+ [1] http://en.wikipedia.org/wiki/Database_normalization Regarding line 386 at 0003-PATCH, is it better to change this link to this one: https://en.wikipedia.org/wiki/Functional_dependency ? README.dependencies cites directly above link. Though I pointed out these typoes and so on, I believe these feedback are less priority compared to the source code itself. So please work on my feedback if you have time. regards, Ideriha Takeshi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [WIP] RE: [HACKERS] DECLARE STATEMENT setting up a connection in ECPG
Hi, I'm sorry but I think I don't have time to work on this patch in this CF. I've gotten busy for another work. So I moved this patch to next CF with "waiting on author" status. Regards, Ideriha Takeshi > -Original Message- > From: Ideriha, Takeshi > Sent: Friday, January 20, 2017 6:12 PM > To: 'Michael Paquier' <michael.paqu...@gmail.com> > Cc: Michael Meskes <mes...@postgresql.org>; pgsql-hackers@postgresql.org > Subject: RE: [WIP] RE: [HACKERS] DECLARE STATEMENT setting up a connection in > ECPG > > > Idehira-san, this is a very intrusive patch... It really needs a > > specific reviewer to begin with, but really it would be nice if you > > could review someone else's patch, with a difficulty rather equivalent to > what we have here. > > Michael, thank you for taking a look at my patch and giving me an advice. > And sorry that I didn't follow a procedure of developing postgresql. > I think I should have sent a system design idea or small patch first and made > it bigger and bigger step by step instead of dumping a huge patch suddenly. > > Yeah, I'm going to reviewing hackers' patches. > > > By the way, I have been able to crash your patch when running the > > regression > > tests: > > Thank you for checking and I'm going to handle this. > > Regards, > Ideriha Takeshi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [WIP] RE: [HACKERS] DECLARE STATEMENT setting up a connection in ECPG
> Idehira-san, this is a very intrusive patch... It really needs a specific > reviewer to begin with, but really it would be nice if you could review > someone > else's patch, with a difficulty rather equivalent to what we have here. Michael, thank you for taking a look at my patch and giving me an advice. And sorry that I didn't follow a procedure of developing postgresql. I think I should have sent a system design idea or small patch first and made it bigger and bigger step by step instead of dumping a huge patch suddenly. Yeah, I'm going to reviewing hackers' patches. > By the way, I have been able to crash your patch when running the regression > tests: Thank you for checking and I'm going to handle this. Regards, Ideriha Takeshi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[WIP] RE: [HACKERS] DECLARE STATEMENT setting up a connection in ECPG
> > I'm looking forward to seeing your patch. > I created a patch. I marked [WIP] to the title because some documentation is lacked and format needs some fixing. I'm going to post this patch to the January CF. But it's my first time to send a patch so please excuse me if there's something you feel bad with. Regards, Ideriha Takeshi > -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Meskes > Sent: Tuesday, November 22, 2016 2:57 AM > To: Ideriha, Takeshi <ideriha.take...@jp.fujitsu.com> > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] DECLARE STATEMENT setting up a connection in ECPG > > > I wanted to say that in order to use the connection pointed by the > > DECLARE STATEMENT some functions like ECPGdo() would be modified or > > new function would be added under the directory ecpglib/. > > > > This modification or new function will be used to get the connection > > by statement_name. > > Ah, now I understand. Thank you for your explanation. > > I'm looking forward to seeing your patch. > > 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 dot org VfL Borussia! Força Barça! SF > 49ers! > Use Debian GNU/Linux, PostgreSQL > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers 001_declareStatement_v1.patch.tar.gz Description: 001_declareStatement_v1.patch.tar.gz -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Forbid use of LF and CR characters in database and role names
> > [Summary] > > 1. apply patch and make world > > -> failed because was mistakenly coded . > > > > 2．correct this mistake and make check-world > > -> got 1 failed test: "'pg_dumpall with \n\r in database name'" > > because test script cannot createdb "foo\n\rbar" > > The attached version addresses those problems. I have replaced the test in > src/bin/pg_dump/t/ by tests in src/bin/scripts/t/ to check if the role name > and database name with CR or LF fail to be created. I have as well added a > test > for initdb when the data directory has an incorrect character in 0002. Thanks for your modification. I applied your fixed patch and new one, and confirmed the applied source passed the tests successfully. And I also checked manually the error messages were emitted successfully when cr/lf are included in dbname or rolename or data_directory. AFAICT, this patch satisfies the concept discussed before. So I’ve switched this patch “Ready for Committer”. Regards, Ideriha, Takeshi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Forbid use of LF and CR characters in database and role names
Hi, Here's a summary for what I tested in RHEL7.0, details follow. [Summary] 1. apply patch and make world -> failed because was mistakenly coded . 2．correct this mistake and make check-world -> got 1 failed test: "'pg_dumpall with \n\r in database name'" because test script cannot createdb "foo\n\rbar" Details follows: [1. apply patch and make world>] I tried to make world after applying patch and there seems to be one small mistake in create_role. === openjade:ref/create_role.sgml:413:7:E: document type does not allow element "PARA" here; missing one of "FOOTNOTE", "ITEMIZEDLIST", "ORDEREDLIST", "VARIABLELIST", "CAUTION", "IMPORTANT", "NOTE", "TIP", "WARNING", "BLOCKQUOTE", "INFORMALEXAMPLE" start-tag openjade:ref/create_role.sgml:414:11:E: end tag for "PARA" omitted, but OMITTAG NO was specified openjade:ref/create_role.sgml:413:2: start tag was here openjade:ref/create_role.sgml:414:11:E: end tag for "PARA" omitted, but OMITTAG NO was specified openjade:ref/create_role.sgml:408:2: start tag was here make[3]: *** [HTML.index] Error 1 make[3]: *** Deleting file `HTML.index' === [2．correct this mistake and make check-world] After fixing this mistake locally by correcting to end tag, postgresql and documentation were successfully made. And also "make check" tests passed (not "make check-world"). diff --git a/doc/src/sgml/ref/create_role.sgml b/doc/src/sgml/ref/create_role.sgml index 9d6926e..ff4b6f6 100644 --- a/doc/src/sgml/ref/create_role.sgml +++ b/doc/src/sgml/ref/create_role.sgml @@ -410,7 +410,7 @@ CREATE ROLE name [ [ WITH ] + = This failure seems actually caused by t/010_dump_connstr.pl line 65 "$node->run_log(['createdb', "foo\n\rbar"]);". This means your patch works well. Excerpt from log follows. === # Failed test 'pg_dumpall with \n\r in database name' # at /home/ideriha/postgres-master/src/bin/pg_dump/../../../src/test/perl/TestLib.pm line 230. # Looks like you failed 1 test of 14. t/010_dump_connstr.pl .. not ok 6 - pg_dumpall with \n\r in database name Failed 1/14 subtests Test Summary Report --- t/010_dump_connstr.pl (Wstat: 256 Tests: 14 Failed: 1) Failed test: 6 Non-zero exit status: 1 Files=3, Tests=1822, 58 wallclock secs ( 0.20 usr 0.01 sys + 12.52 cusr 1.94 csys = 14.67 CPU) Result: FAIL = Regards, Ideriha, Takeshi Fujitsu -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DECLARE STATEMENT setting up a connection in ECPG
Thank you for your comment. Friday, November 18, 2016 4:45 AM Michael Meskes wrote : > > - Translate the DECLARE STATEMENT into a new function with parameters. > >These parameters carry the information like connection_name and > statement_name. > > - The function is a new function defined in the ECPG library. > > Why's that? I haven't checked if the standard says anything about this and my > memory might be wrong, but isn't "DECLARE STATEMENT" supposed to be purely > declarative, i.e. not executed at run time? My lack of explanation caused the confusion, sorry. Your point is true. "DECLARE STATEMENT" is declarative ,not function in .pgc file. I wanted to say that in order to use the connection pointed by the DECLARE STATEMENT some functions like ECPGdo() would be modified or new function would be added under the directory ecpglib/. This modification or new function will be used to get the connection by statement_name. Regards, Ideriha, Takeshi Fujitsu -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] DECLARE STATEMENT setting up a connection in ECPG
Hi, Making developing ECPG application more efficiently and improve portability, I'd like to suggest DECLARE STATEMENT support in ECPG. This DECLARE STATEMENT is one of the statement that lets users declare an identifier pointing a connection. This identifier will be used in other embedded dynamic SQL statement such as PREPARE, EXECUTE, DECLARE CURSOR and so on. (Oracle implements this.) https://docs.oracle.com/cd/B10501_01/appdev.920/a42525/apf.htm#declare_stmt Under the current system, a user must use the AT clause in every SQL statements when executing the dynamic SQL at non-default connection. https://www.postgresql.org/docs/current/static/ecpg-connect.html When a user needs to connect to a non-default connection, AT clause can be used in DECLARE STATEMENT once and need not to be in every dynamic SQL statements. This helps a user with making ECPG application easily and efficiently without explicitly designating a connection for each SQL statement. Moreover, writing code without designating connection explicitly improves portability. [Use-case] It is very useful when the data needed for a report, business decision is spread across several data sources, and one application needs to connect multiple database server. Especially these days, multiple database servers are easily set up without taking time and cost because virtualization such as docker and microservices are in fashion. This trend leads to be growing importance of this handy connection switching function. [Interface] The syntax for the DECLARE STATEMENT in ECPG is as following: EXEC SQL [ AT connection-name ] DECLARE statement-name STATEMENT , where "statement-name" is an SQL identifier and "connection name" points to the connection which will be used to execute the dynamic SQL statements. [Example] EXEC SQL AT con1 DECLARE sql_stmt STATEMENT EXEC SQL DECLARE cursor_name CURSOR FOR sql_stmt EXEC SQL PREPARE sql_stmt FROM :dyn_string [System Design Plan] To support above functionality, ecpg precompiler should support: - To understand the DECLARE STATEMENT syntax - Translate the DECLARE STATEMENT into a new function with parameters. These parameters carry the information like connection_name and statement_name. - The function is a new function defined in the ECPG library. Following functions are going to be modified: - ECPGprepare - ECPGdeallocate - ECPGdescribe - ECPGdo But I think there is room for discussing modifying ECPGdo, because it's a very common function that will map many SQL statement including SELECT, INSERT, EXECTUTE, CURSOR and so on. It seems to me there is no discussion on this topic. But if exists, would you let me know? Regards. Ideriha Takeshi, Fujitsu (Fujitsu Enterprise Postgres ) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
