Cannot
On 10/26/2011 02:16 PM, David E. Wheeler wrote:
Suggested doc �patch�:
grep -lri 'can not' doc | xargs perl -i -pe 's/can not/cannot/g'
Why? "can not" is perfectly grammatical AFAIK.
cheers
andrew
On Oct 26, 2011, at 2:06 PM, Andrew Dunstan wrote:
Suggested doc “patch”:
grep -lri 'can not' doc | xargs perl -i -pe 's/can not/cannot/g'
Why? "can not" is perfectly grammatical AFAIK.
True, but there's a logic issue. Take this example from doc/src/sgml/func.sgml:
<para>
<function>pg_advisory_xact_lock</> works the same as
<function>pg_advisory_lock</>, expect the lock is automatically released
at the end of the current transaction and can not be released explicitly.
</para>
I read this as equivalent to "can be not released." Which of course is silly, so as I read it I realize what it means, but it trips up my overly logical brain. It interrupts the flow. There is no such confusion in "cannot be released" and thus no tripping up on meaning.
Best,
David
On 10/26/2011 05:15 PM, David E. Wheeler wrote:
On Oct 26, 2011, at 2:06 PM, Andrew Dunstan wrote:
Suggested doc �patch�:
grep -lri 'can not' doc | xargs perl -i -pe 's/can not/cannot/g'
Why? "can not" is perfectly grammatical AFAIK.
True, but there's a logic issue. Take this example from doc/src/sgml/func.sgml:
<para>
<function>pg_advisory_xact_lock</> works the same as
<function>pg_advisory_lock</>, expect the lock is automatically released
at the end of the current transaction and can not be released explicitly.
</para>I read this as equivalent to "can be not released." Which of course is silly, so as I read it I realize what it means, but it trips up my overly logical brain. It interrupts the flow. There is no such confusion in "cannot be released" and thus no tripping up on meaning.
Here's what I would do:
1. s/expect/except that/
2. s/can not be released explicitly/can not be explicitly released/
cheers
andrew
"David E. Wheeler" <david@kineticode.com> writes:
On Oct 26, 2011, at 2:06 PM, Andrew Dunstan wrote:
Why? "can not" is perfectly grammatical AFAIK.
True, but there's a logic issue. Take this example from doc/src/sgml/func.sgml:
<para>
<function>pg_advisory_xact_lock</> works the same as
<function>pg_advisory_lock</>, expect the lock is automatically released
at the end of the current transaction and can not be released explicitly.
</para>
I read this as equivalent to "can be not released." Which of course is silly, so as I read it I realize what it means, but it trips up my overly logical brain. It interrupts the flow. There is no such confusion in "cannot be released" and thus no tripping up on meaning.
This particular change seems like an improvement to me, but it's hardly
an adequate argument for a global search-and-replace. There might be
other places where such a change renders things *less* readable.
regards, tom lane
On Oct 26, 2011, at 2:58 PM, Tom Lane wrote:
I read this as equivalent to "can be not released." Which of course is silly, so as I read it I realize what it means, but it trips up my overly logical brain. It interrupts the flow. There is no such confusion in "cannot be released" and thus no tripping up on meaning.
This particular change seems like an improvement to me, but it's hardly
an adequate argument for a global search-and-replace. There might be
other places where such a change renders things *less* readable.
The patch is actually quite modest; there are only a few instances of "can not". Attached.
Best,
David
Attachments:
cannot.patchapplication/octet-stream; name=cannot.patch; x-unix-mode=0644Download
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
new file mode 100644
index 8dd6933..1ce1dd8
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgml
*************** SELECT (pg_stat_file('filename')).modifi
*** 15025,15031 ****
<para>
<function>pg_advisory_xact_lock</> works the same as
<function>pg_advisory_lock</>, expect the lock is automatically released
! at the end of the current transaction and can not be released explicitly.
</para>
<indexterm>
--- 15025,15031 ----
<para>
<function>pg_advisory_xact_lock</> works the same as
<function>pg_advisory_lock</>, expect the lock is automatically released
! at the end of the current transaction and cannot be released explicitly.
</para>
<indexterm>
*************** SELECT (pg_stat_file('filename')).modifi
*** 15034,15040 ****
<para>
<function>pg_advisory_xact_lock_shared</> works the same as
<function>pg_advisory_lock_shared</>, expect the lock is automatically released
! at the end of the current transaction and can not be released explicitly.
</para>
<indexterm>
--- 15034,15040 ----
<para>
<function>pg_advisory_xact_lock_shared</> works the same as
<function>pg_advisory_lock_shared</>, expect the lock is automatically released
! at the end of the current transaction and cannot be released explicitly.
</para>
<indexterm>
*************** SELECT (pg_stat_file('filename')).modifi
*** 15044,15050 ****
<function>pg_try_advisory_xact_lock</> works the same as
<function>pg_try_advisory_lock</>, expect the lock, if acquired,
is automatically released at the end of the current transaction and
! can not be released explicitly.
</para>
<indexterm>
--- 15044,15050 ----
<function>pg_try_advisory_xact_lock</> works the same as
<function>pg_try_advisory_lock</>, expect the lock, if acquired,
is automatically released at the end of the current transaction and
! cannot be released explicitly.
</para>
<indexterm>
*************** SELECT (pg_stat_file('filename')).modifi
*** 15054,15060 ****
<function>pg_try_advisory_xact_lock_shared</> works the same as
<function>pg_try_advisory_lock_shared</>, expect the lock, if acquired,
is automatically released at the end of the current transaction and
! can not be released explicitly.
</para>
<indexterm>
--- 15054,15060 ----
<function>pg_try_advisory_xact_lock_shared</> works the same as
<function>pg_try_advisory_lock_shared</>, expect the lock, if acquired,
is automatically released at the end of the current transaction and
! cannot be released explicitly.
</para>
<indexterm>
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
new file mode 100644
index 1ec07dd..c6aaa5c
*** a/doc/src/sgml/mvcc.sgml
--- b/doc/src/sgml/mvcc.sgml
*************** UPDATE accounts SET balance = balance -
*** 1234,1240 ****
session already holds a given lock, additional requests will always succeed,
even if other sessions are awaiting the lock.) Transaction level locks on
the other hand behave more like regular locks; they are automatically
! released at the end of the transaction, and can not be explicitly unlocked.
Session and transaction level locks share the same lock space, which means
that a transaction level lock will prevent another session from obtaining
a session level lock on that same resource and vice versa.
--- 1234,1240 ----
session already holds a given lock, additional requests will always succeed,
even if other sessions are awaiting the lock.) Transaction level locks on
the other hand behave more like regular locks; they are automatically
! released at the end of the transaction, and cannot be explicitly unlocked.
Session and transaction level locks share the same lock space, which means
that a transaction level lock will prevent another session from obtaining
a session level lock on that same resource and vice versa.