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 <br...@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson
