Re: No documentation exists about ecpg ORACLE comptaible mode
On Tue, Jun 7, 2022 at 08:28:55AM +, [email protected] 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 https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson diff --git a/doc/src/sgml/ecpg.sgml b/doc/src/sgml/ecpg.sgml index 7f8b4dd5c0..999b7ca0ae 100644 --- a/doc/src/sgml/ecpg.sgml +++ b/doc/src/sgml/ecpg.sgml @@ -1890,7 +1890,8 @@ EXEC SQL SELECT b INTO :val :val_ind FROM test1; The indicator variable val_ind will be zero if the value was not null, and it will be negative if the value was -null. +null. (See to enable +Oracle-specific behavior.) @@ -9799,6 +9800,42 @@ risnull(CINTTYPE, (char *) &i); + + Oracle Compatibility Mode + + ecpg can be run in a so-called Oracle + compatibility mode. If this mode is active, it tries to + behave as if it were Oracle Pro*C. + + + + Specifically, this mode changes ecpg in three ways: + + + + + Pad character arrays receiving character string types with + trailing spaces to the specified length + + + + + + Zero byte terminate these character arrays, and set the indicator + variable if truncation occurs + + + + + + Set the null indicator to -1 when character + arrays receive empty character string types + + + + + + Internals
Re: Section I - 2.9: Use SELECT to confirm set of rows before DELETE
On Mon, Jun 6, 2022 at 09:19:17PM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/14/tutorial-delete.html > Description: > > Since this tutorial section is coined at beginners, I think it could be > useful to tip users about the possibility to use a SELECT statement with the > exact same qualification(s) as the DELETE statement they're planning to run > to see which rows are about to be deleted, to avoid unintended deletion of > rows. I suggest something like this: > > ... > Without a qualification, DELETE will remove all rows from the given table, > leaving it empty. The system will not request confirmation before doing > this! > > You can check which rows will be deleted by any DELETE statement on the > form: > ```DELETE FROM tablename ... ...``` > by rewriting it into a corresponding SELECT statement: > ```SELECT * FROM tablename ... ...``` > > This is my first attempt at contributing to the community, so please be > nice. :) Uh, this is more of a general SQL training that we don't normally cover in the Postgres docs --- we try to focus on Postgres-specific stuff that people need to know. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson
Re: Fwd: Adding more detail to pg_upgrade documentation
On Sat, Jun 4, 2022 at 03:08:58PM +0530, Nikhil Shetty wrote: > Hi Jack, > > I followed the same steps multiple times but each time, slot had to be > recreated. > > The slots under directory pg_replslot are not created in the new cluster > during > pg_upgrade. > > Thanks and Regards, > Nikhil > > On Sat, 4 Jun 2022 at 1:48 AM, Jack DeVries wrote: > > Hi Nikhil, > > >From the pgupgrade docs: > > > 9. Prepare for standby server upgrades > > > > If you are upgrading standby servers using methods outlined in section > > Step 11, verify that the old standby servers are caught up by running > > pg_controldata against the old primary and standby clusters. Verify > > that the “Latest checkpoint location” values match in all clusters. > > (There will be a mismatch if old standby servers were shut down before > > the old primary or if the old standby servers are still running.) > > Also, make sure wal_level is not set to minimal in the postgresql.conf > > file on the new primary cluster. > > (source: https://www.postgresql.org/docs/devel/pgupgrade.html) > > I'm a new contributor so please forgive me if I'm on the wrong track, > but if you follow this step, won't you also be ensuring that replication > slots do not need to be migrated, since you've just ensured that standby > clusters are in sync with the primary cluster? Please let me know if I'm > missing anything! I have written the attached patch to document this. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml index f3eb7fbd33..d065227656 100644 --- a/doc/src/sgml/ref/pgupgrade.sgml +++ b/doc/src/sgml/ref/pgupgrade.sgml @@ -619,7 +619,8 @@ rsync --archive --delete --hard-links --size-only --no-inc-recursive /vol1/pg_tb Configure the servers for log shipping. (You do not need to run pg_backup_start() and pg_backup_stop() or take a file system backup as the standbys are still synchronized - with the primary.) + with the primary.) Replication slots are not copied and must + be recreated.
Re: Section I - 2.9: Use SELECT to confirm set of rows before DELETE
That makes sense. Thanks for letting me know! On Sun, Jul 10, 2022, 3:17 AM Bruce Momjian wrote: > On Mon, Jun 6, 2022 at 09:19:17PM +, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/14/tutorial-delete.html > > Description: > > > > Since this tutorial section is coined at beginners, I think it could be > > useful to tip users about the possibility to use a SELECT statement with > the > > exact same qualification(s) as the DELETE statement they're planning to > run > > to see which rows are about to be deleted, to avoid unintended deletion > of > > rows. I suggest something like this: > > > > ... > > Without a qualification, DELETE will remove all rows from the given > table, > > leaving it empty. The system will not request confirmation before doing > > this! > > > > You can check which rows will be deleted by any DELETE statement on the > > form: > > ```DELETE FROM tablename ... ...``` > > by rewriting it into a corresponding SELECT statement: > > ```SELECT * FROM tablename ... ...``` > > > > This is my first attempt at contributing to the community, so please be > > nice. :) > > Uh, this is more of a general SQL training that we don't normally cover > in the Postgres docs --- we try to focus on Postgres-specific stuff that > people need to know. > > -- > Bruce Momjian https://momjian.us > EDB https://enterprisedb.com > > Indecision is a decision. Inaction is an action. Mark Batterson > >
