[DOCS] intagg.sgml: example wrongly named and does not compile

[Christophe Courtois]

Hi,

I've found out that the example in intagg.sgml is wrongly named: the
one-to-many table is a many-to-many.

And my colleague Thibaut Madeleine has seen that the "CREATE TABLE
right" and "CREATE TABLE left" examples cannot compile due to the
reserved words.

I propose the attached patch to fix that.

Yours,

-- 
Christophe Courtois
Consultant Dalibo
http://dalibo.com/  -  http://dalibo.org/

-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] intagg.sgml: example wrongly named and does not compile

[Tom Lane]

Christophe Courtois  writes:
> I've found out that the example in intagg.sgml is wrongly named: the
> one-to-many table is a many-to-many.

Well, it'd depend on how it was used.  The example clearly intends that
it be one-to-many, and I'm not sure it still makes sense without that
restriction.  Maybe better to add a unique constraint on
one_to_many(left)?

> And my colleague Thibaut Madeleine has seen that the "CREATE TABLE
> right" and "CREATE TABLE left" examples cannot compile due to the
> reserved words.

Ouch.  Shows you how old this module is :-(

> I propose the attached patch to fix that.

Um, the attached file seems empty from here.

regards, tom lane


-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] intagg.sgml: example wrongly named and does not compile

[Christophe Courtois]

Le 21/04/2017 à 17:45, Tom Lane a écrit :
> Christophe Courtois  writes:
>> I've found out that the example in intagg.sgml is wrongly named: the
>> one-to-many table is a many-to-many.
> Well, it'd depend on how it was used.  The example clearly intends that
> it be one-to-many, and I'm not sure it still makes sense without that
> restriction.  Maybe better to add a unique constraint on
> one_to_many(left)?

Perhaps the whole example can be simplified to get rid of the "left"
table, but I didn't intend to rewrite it.

>> And my colleague Thibaut Madeleine has seen that the "CREATE TABLE
>> right" and "CREATE TABLE left" examples cannot compile due to the
>> reserved words.
> Ouch.  Shows you how old this module is :-(

Indeed.

>> I propose the attached patch to fix that.
> Um, the attached file seems empty from here.

Ooops, sorry. It is attached.




-- 
Christophe Courtois
Consultant Dalibo
http://dalibo.com/  -  http://dalibo.org/
--- intagg.sgml.HEAD	2016-11-17 09:41:53.173988630 +0100
+++ intagg.sgml	2017-04-21 16:29:10.421996579 +0200
@@ -54,20 +54,23 @@
   Sample Uses
 
   
-   Many database systems have the notion of a one to many table. Such a table
+   Many database systems have the notion of a many to many table. Such a table
usually sits between two indexed tables, for example:
 
 
-CREATE TABLE left (id INT PRIMARY KEY, ...);
-CREATE TABLE right (id INT PRIMARY KEY, ...);
-CREATE TABLE one_to_many(left INT REFERENCES left, right INT REFERENCES right);
+CREATE TABLE left_table  (id INT PRIMARY KEY, ...);
+CREATE TABLE right_table (id INT PRIMARY KEY, ...);
+CREATE TABLE many_to_many(id_left  INT REFERENCES left_table, 
+  id_right INT REFERENCES right_table);
 
 
   It is typically used like this:
 
 
-SELECT right.* from right JOIN one_to_many ON (right.id = one_to_many.right)
-  WHERE one_to_many.left = item;
+SELECT right_table.* 
+FROM right_table 
+JOIN many_to_many ON (right_table.id = many_to_many.id_right)
+WHERE many_to_many.id_left = item;
 
 
   This will return all the items in the right hand table for an entry
@@ -76,7 +79,7 @@
 
  
   Now, this methodology can be cumbersome with a very large number of
-  entries in the one_to_many table.  Often,
+  entries in the many_to_many table.  Often,
   a join like this would result in an index scan
   and a fetch for each right hand entry in the table for a particular
   left hand entry. If you have a very dynamic system, there is not much you
@@ -85,9 +88,9 @@
 
 
 CREATE TABLE summary AS
-  SELECT left, int_array_aggregate(right) AS right
-  FROM one_to_many
-  GROUP BY left;
+  SELECT id_left, int_array_aggregate(id_right) AS rights
+  FROM many_to_many
+  GROUP BY id_left;
 
 
   This will create a table with one row per left item, and an array
@@ -95,33 +98,35 @@
   the array; that's why there is an array enumerator.  You can do
 
 
-SELECT left, int_array_enum(right) FROM summary WHERE left = item;
+SELECT id_left, int_array_enum(rights) FROM summary WHERE id_left = item;
 
 
   The above query using int_array_enum produces the same results
   as
 
 
-SELECT left, right FROM one_to_many WHERE left = item;
+SELECT id_left, id_right FROM many_to_many WHERE id_left = item;
 
 
   The difference is that the query against the summary table has to get
   only one row from the table, whereas the direct query against
-  one_to_many must index scan and fetch a row for each entry.
+  many_to_many must index scan and fetch a row for each entry.
  
 
  
   On one system, an EXPLAIN showed a query with a cost of 8488 was
   reduced to a cost of 329.  The original query was a join involving the
-  one_to_many table, which was replaced by:
+  many_to_many table, which was replaced by:
 
 
-SELECT right, count(right) FROM
-  ( SELECT left, int_array_enum(right) AS right
-FROM summary JOIN (SELECT left FROM left_table WHERE left = item) AS lefts
- ON (summary.left = lefts.left)
+SELECT id_right, count(id_right) FROM
+  ( SELECT id_left, int_array_enum(rights) AS id_right
+FROM summary 
+JOIN (SELECT id FROM left_table 
+  WHERE id = item) AS lefts
+ON (summary.id_left = lefts.id)
   ) AS list
-  GROUP BY right
+  GROUP BY id_right
   ORDER BY count DESC;
 
  

-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] There is one "a" too much

[Peter Eisentraut]

On 4/12/17 04:26, d...@dbi-services.com wrote:
> The following documentation comment has been logged on the website:
> 
> Page: https://www.postgresql.org/docs/0.0/static/logical-replication.html
> Description:
> 
> Logical replication of a table typically starts with a taking a snapshot

Fixed, thanks.

-- 
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] Missing lock conflict for ROW SHARE

[Peter Eisentraut]

On 4/12/17 06:00, diemersebast...@yahoo.fr wrote:
> The following documentation comment has been logged on the website:
> 
> Page: https://www.postgresql.org/docs/9.4/static/explicit-locking.html
> Description:
> 
> In my experience ROW SHARE conflicts with ROW EXCLUSIVE and this is not
> mentioned in the documentation. Am I missing something ?

This is not correct.  See the source for how the lock conflicts are
defined:


-- 
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

[DOCS] Small patch for the section "rules-views"

[Zertrin]

Hello,

While reading the documentation I spotted a minor glitch in the section 
"rules-views"


The reference at the bottom stating "That is the topic of the next 
section." is incorrect since the materialized views documentation got 
inserted between the section "rules-views" and "rules-update".


Attached is a small patch that fixes it by linking to the relevant 
section. (the patch should be applicable with "patch -p1" from the root 
dir of the postgres repo)


Regards,

Marc

diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml
index ca1b767..bcbc170 100644
--- a/doc/src/sgml/rules.sgml
+++ b/doc/src/sgml/rules.sgml
@@ -862,7 +862,7 @@ SELECT t1.a, t2.b, t1.ctid FROM t1, t2 WHERE t1.a = t2.a;
 UPDATE, and DELETE commands on
 a view. These rules will rewrite the command, typically into a command
 that updates one or more tables, rather than views. That is the topic
-of the next section.
+of .
 

 
-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] Small patch for the section "rules-views"

[Peter Eisentraut]

On 4/21/17 06:03, Zertrin wrote:
> While reading the documentation I spotted a minor glitch in the section 
> "rules-views"
> 
> The reference at the bottom stating "That is the topic of the next 
> section." is incorrect since the materialized views documentation got 
> inserted between the section "rules-views" and "rules-update".

Committed, thanks.

-- 
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs