Re: [HACKERS] Typo in insert.sgml - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: [HACKERS] Typo in insert.sgml
Date
Msg-id CAKFQuwasN1kW474xbZNO7HYtcj7RUDMDDQ9GquyTtybEc7N+5A@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Typo in insert.sgml  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Jun 20, 2017 at 1:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Jun 20, 2017 at 2:34 PM, Peter Eisentraut
>> <peter.eisentraut@2ndquadrant.com> wrote:
>>> This was not a typo, this was intentional.
>
>> To me, Julien's change seems to make it easier to understand, but
>> maybe I'm misunderstanding what it's trying to say in the first place.
>
> I think there are two subtly different things here: the sequence counters
> will continue to be attached to the identity columns, and the counters
> will continue in sequence (ie, no implied ALTER SEQUENCE RESTART).
> The existing text seems to mean the latter but Julien's change makes it
> about the former.
>
> It could use rewording for clarity, just not this rewording.

Tom, I'm not following your train of thought:

Given one sequenced IDENTITY column in each table (some rows were
delete from each already):
tbl1
4
5
6

tbl2
10
11
12

The point being made is that inserting all rows from tbl1 into tbl2
will result in tbl2 having:
10
11
12
13
14
15

and not:
10
11
12
4
5
6

That the sequence counters continue to be attached seems like it can
and should be taken for granted.  Inserting to a table likewise should
never cause an ALTER SEQUENCE RESTART to occur and so can and should
be taken for granted.

ISTM that both the existing text and Julien's variation say this, just
differently.  I think the word "continue" is part of the problem.  I
also think not being explicit about the fact that its tbl2's sequence
that supplies the new values - instead of using the values already
present in tbl1 - requires one to think harder about the scenario than
need be.

David J.



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: [HACKERS] Is exec_simple_check_node still doing anything?
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Is exec_simple_check_node still doing anything?