MIME-Version: 1.0
From: Josh Kupershmidt <schmiddy@gmail.com>
Date: Wed, 8 Jul 2015 17:56:09 -0400
Message-ID: 
 <CAK3UJRE4wGWMjGOfUZcTAOn_k43ETi-jh6FsLF7XX3=Qmkdt3A@mail.gmail.com>
Subject: Outdated note about unique indexes
To: pgsql-docs <pgsql-docs@postgresql.org>
Content-Type: multipart/mixed; boundary=001a113ad65a08d1b9051a6436c4
Precedence: bulk
Sender: pgsql-docs-owner@postgresql.org

--001a113ad65a08d1b9051a6436c4
Content-Type: multipart/alternative; boundary=001a113ad65a08d1b3051a6436c2

--001a113ad65a08d1b3051a6436c2
Content-Type: text/plain; charset=UTF-8

Hi,

I noticed that the note on a page about unique indexes

http://www.postgresql.org/docs/current/static/indexes-unique.html

says "The preferred way to add a unique constraint to a table is ALTER
TABLE ... ADD CONSTRAINT. The use of indexes to enforce unique constraints
could be considered an implementation detail that should not be accessed
directly... ".

That note has been there forever, in particular since before we supported
CONCURRENTLY, which is pretty darn important in many uses nowadays. Since
it seems like some users have taken this suggestion seriously, e.g. on
stackoverflow[1], how about we remove this outdated suggestion? There is
already a previous mention a few sections earlier[2] suggesting the use of
CONCURRENTLY, so I don't think we really need to reiterate that suggestion
here.

Josh

[1]
http://stackoverflow.com/questions/23542794/postgres-unique-constraint-vs-index
[2] http://www.postgresql.org/docs/current/interactive/indexes-intro.html

--001a113ad65a08d1b3051a6436c2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>I noticed that the note on a page a=
bout unique indexes</div><div><br></div><div><a href=3D"http://www.postgres=
ql.org/docs/current/static/indexes-unique.html">http://www.postgresql.org/d=
ocs/current/static/indexes-unique.html</a><br></div><div><br></div><div>say=
s &quot;The preferred way to add a unique constraint to a table is ALTER TA=
BLE ... ADD CONSTRAINT. The use of indexes to enforce unique constraints co=
uld be considered an implementation detail that should not be accessed dire=
ctly... &quot;.</div><div><br></div><div>That note has been there forever, =
in particular since before we supported CONCURRENTLY, which is pretty darn =
important in many uses nowadays. Since it seems like some users have taken =
this suggestion seriously, e.g. on stackoverflow[1], how about we remove th=
is outdated suggestion? There is already a previous mention a few sections =
earlier[2] suggesting the use of CONCURRENTLY, so I don&#39;t think we real=
ly need to reiterate that suggestion here.</div><div><br></div><div>Josh</d=
iv><div><br></div><div>[1]=C2=A0<a href=3D"http://stackoverflow.com/questio=
ns/23542794/postgres-unique-constraint-vs-index">http://stackoverflow.com/q=
uestions/23542794/postgres-unique-constraint-vs-index</a></div><div>[2]=C2=
=A0<a href=3D"http://www.postgresql.org/docs/current/interactive/indexes-in=
tro.html">http://www.postgresql.org/docs/current/interactive/indexes-intro.=
html</a></div><div><br></div></div>

--001a113ad65a08d1b3051a6436c2--

--001a113ad65a08d1b9051a6436c4
Content-Type: text/plain; charset=US-ASCII;
 name="indices_constraint_suggestion.diff"
Content-Disposition: attachment; filename="indices_constraint_suggestion.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_ibvb14q80

ZGlmZiAtLWdpdCBhL2RvYy9zcmMvc2dtbC9pbmRpY2VzLnNnbWwgYi9kb2Mv
c3JjL3NnbWwvaW5kaWNlcy5zZ21sCmluZGV4IDMwOWZkMTIuLjJkMTMxYzkg
MTAwNjQ0Ci0tLSBhL2RvYy9zcmMvc2dtbC9pbmRpY2VzLnNnbWwKKysrIGIv
ZG9jL3NyYy9zZ21sL2luZGljZXMuc2dtbApAQCAtNjU1LDExICs2NTUsNyBA
QCBDUkVBVEUgVU5JUVVFIElOREVYIDxyZXBsYWNlYWJsZT5uYW1lPC9yZXBs
YWNlYWJsZT4gT04gPHJlcGxhY2VhYmxlPnRhYmxlPC9yZXBsYQogCiAgIDxu
b3RlPgogICAgPHBhcmE+Ci0gICAgVGhlIHByZWZlcnJlZCB3YXkgdG8gYWRk
IGEgdW5pcXVlIGNvbnN0cmFpbnQgdG8gYSB0YWJsZSBpcwotICAgIDxsaXRl
cmFsPkFMVEVSIFRBQkxFIC4uLiBBREQgQ09OU1RSQUlOVDwvbGl0ZXJhbD4u
ICBUaGUgdXNlIG9mCi0gICAgaW5kZXhlcyB0byBlbmZvcmNlIHVuaXF1ZSBj
b25zdHJhaW50cyBjb3VsZCBiZSBjb25zaWRlcmVkIGFuCi0gICAgaW1wbGVt
ZW50YXRpb24gZGV0YWlsIHRoYXQgc2hvdWxkIG5vdCBiZSBhY2Nlc3NlZCBk
aXJlY3RseS4KLSAgICBPbmUgc2hvdWxkLCBob3dldmVyLCBiZSBhd2FyZSB0
aGF0IHRoZXJlJ3Mgbm8gbmVlZCB0byBtYW51YWxseQorICAgIFRoZXJlJ3Mg
bm8gbmVlZCB0byBtYW51YWxseQogICAgIGNyZWF0ZSBpbmRleGVzIG9uIHVu
aXF1ZSBjb2x1bW5zOyBkb2luZyBzbyB3b3VsZCBqdXN0IGR1cGxpY2F0ZQog
ICAgIHRoZSBhdXRvbWF0aWNhbGx5LWNyZWF0ZWQgaW5kZXguCiAgICA8L3Bh
cmE+Cg==

--001a113ad65a08d1b9051a6436c4
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


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

--001a113ad65a08d1b9051a6436c4--