No documentation exists about ecpg ORACLE comptaible mode
Hi.
(CCing Michael Meskes)
One of my customers asked me about what oracle compatibility mode in ecpg means,
and I noticed current documentation does not explain ecpg ORACLE compatible mode (ecpg -C ORACLE) in detail.
I myself learned the feature of "-C ORACLE" from regression test (src/interfaces/ecpg/test/compat_oracle) and source code.
Is lacking documentation intentional or do commit 3b7ab4380 and 3b9b7516f just forget adding the explanation?
As for as I know, "ecpg -C ORACLE" is written briefly in ecpg command reference and PostgreSQL 11 release note,
but they are not enougn information for users to understand feature of "ecpg -C ORACLE".
https://www.postgresql.org/docs/current/app-ecpg.html
-------------------------------
-C mode
Set a compatibility mode. mode can be INFORMIX, INFORMIX_SE, or ORACLE.
-------------------------------
https://www.postgresql.org/docs/11/release-11.html#id-1.11.6.21.5.9
-------------------------------
Add an ecpg mode to enable Oracle Pro*C-style handling of char arrays.
This mode is enabled with -C.
-------------------------------
On the other hand, informix compatible mode is written in detail.
https://www.postgresql.org/docs/current/ecpg-informix-compat.html
Best regards,
Takeshi Ideriha
On Tue, Jun 7, 2022 at 08:28:55AM +0000, ideriha.takeshi@fujitsu.com wrote:
Hi.
(CCing Michael Meskes)One of my customers asked me about what oracle compatibility mode in ecpg means,
and I noticed current documentation does not explain ecpg ORACLE compatible mode (ecpg -C ORACLE) in detail.
I myself learned the feature of "-C ORACLE" from regression test (src/interfaces/ecpg/test/compat_oracle) and source code.Is lacking documentation intentional or do commit 3b7ab4380 and 3b9b7516f just forget adding the explanation?
As for as I know, "ecpg -C ORACLE" is written briefly in ecpg command reference and PostgreSQL 11 release note,
but they are not enougn information for users to understand feature of "ecpg -C ORACLE".https://www.postgresql.org/docs/current/app-ecpg.html
-------------------------------
-C mode
Set a compatibility mode. mode can be INFORMIX, INFORMIX_SE, or ORACLE.
-------------------------------https://www.postgresql.org/docs/11/release-11.html#id-1.11.6.21.5.9
-------------------------------
Add an ecpg mode to enable Oracle Pro*C-style handling of char arrays.This mode is enabled with -C.
-------------------------------On the other hand, informix compatible mode is written in detail.
https://www.postgresql.org/docs/current/ecpg-informix-compat.html
This is a very good point. I have studied the issue and created the
attached patch to document Oracle-compatibility mode.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson
Attachments:
ecpg.difftext/x-diff; charset=us-asciiDownload+38-1
On Sat, Jul 09, 2022 at 09:15:52PM -0400, Bruce Momjian wrote:
This is a very good point. I have studied the issue and created the
attached patch to document Oracle-compatibility mode.
...
Looks good to me. Thanks a bunch Bruce.
I wonder if we should also mention somewhere that some other Oracle
compatibility features are enable in all modes, like a slightly different
CONNECT syntax.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
On Tue, Jul 12, 2022 at 10:20:08AM +0200, Michael Meskes wrote:
On Sat, Jul 09, 2022 at 09:15:52PM -0400, Bruce Momjian wrote:
This is a very good point. I have studied the issue and created the
attached patch to document Oracle-compatibility mode.
...Looks good to me. Thanks a bunch Bruce.
Great, thanks.
I wonder if we should also mention somewhere that some other Oracle
compatibility features are enable in all modes, like a slightly different
CONNECT syntax.
Good question. We support syntax from other databases, only sometimes
with documentation. I think the rules we use are that we document
compatibility-only behavior when it is useful and obviously if it is
turned in by an option.
In contrast, look at this from backend/parser/gram.y:
/* INOUT is SQL99 standard, IN OUT is for Oracle compatibility */
arg_class: IN_P { $$ = FUNC_PARAM_IN; }
| OUT_P { $$ = FUNC_PARAM_OUT; }
| INOUT { $$ = FUNC_PARAM_INOUT; }
| IN_P OUT_P { $$ = FUNC_PARAM_INOUT; }
| VARIADIC { $$ = FUNC_PARAM_VARIADIC; }
We don't document "IN OUT" anywhere, we just support it silently for
Oracle compatibility, and I am guessing your ecpg connection syntax is
similar. I think this is done so we don't confuse people with syntax
that has not value unless they are coming from another database.
Therefore, I don't think we should document it, but I would be
interested to hear if anyone disagrees.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson
Bruce Momjian <bruce@momjian.us> wrote:
This is a very good point. I have studied the issue and created the attached patch to document Oracle-compatibility mode.
Hi Bruce, thank you for writing the document.
I checked it and I'm very glad!
Regards,
Takeshi Ideriha
On Thu, Jul 14, 2022 at 02:41:45AM +0000, ideriha.takeshi@fujitsu.com wrote:
Bruce Momjian <bruce@momjian.us> wrote:
This is a very good point. I have studied the issue and created the attached patch to document Oracle-compatibility mode.
Hi Bruce, thank you for writing the document.
I checked it and I'm very glad!
Patch applied to PG 11, where the feature was added, and later.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson