Thread: Note new NULLS NOT DISTINCT on unique index tutorial page
The SQL Language part of the docs has a brief page on unique indexes. It doesn't mention the new NULLS NOT DISTINCT functionality on unique indexes and this is a good place to mention it, as it already warns the user about the old/default behavior. -- David Gilman :DG<
Attachment
On Wed, Apr 12, 2023 at 10:40 AM David Gilman <davidgilman1@gmail.com> wrote:
The SQL Language part of the docs has a brief page on unique indexes.
It doesn't mention the new NULLS NOT DISTINCT functionality on unique
indexes and this is a good place to mention it, as it already warns
the user about the old/default behavior.
I'm ok with the wording as-is, but perhaps we can phrase it as "distinct" vs "not equal", thus leaning into the syntax a bit:
By default, null values in a unique column are considered distinct, allowing multiple nulls in the column.
or maybe
By default, null values in a unique column are considered <literal>DISTINCT</literal>, allowing multiple nulls in the column.
On Thu, 13 Apr 2023 at 02:40, David Gilman <davidgilman1@gmail.com> wrote: > The SQL Language part of the docs has a brief page on unique indexes. > It doesn't mention the new NULLS NOT DISTINCT functionality on unique > indexes and this is a good place to mention it, as it already warns > the user about the old/default behavior. I think we should do this and apply it to v15 too. It seems like a good idea to include the [NULLS [NOT] DISTINCT] in the syntax synopsis too. Otherwise, the reader of that page is just left guessing where they'll put NULLS NOT DISTINCT to get the behaviour you've added the text for. I've attached an updated patch with that plus 2 very small wording tweaks to your proposed text. David
Attachment
On Tue, 18 Apr 2023 at 05:01, Corey Huinker <corey.huinker@gmail.com> wrote: > I'm ok with the wording as-is, but perhaps we can phrase it as "distinct" vs "not equal", thus leaning into the syntaxa bit: > > By default, null values in a unique column are considered distinct, allowing multiple nulls in the column. > > > or maybe > > By default, null values in a unique column are considered <literal>DISTINCT</literal>, allowing multiple nulls in the column.> I acknowledge your input, but I didn't think either of these was an improvement over what David suggested. I understand that many people will know that "SELECT DISTINCT" and "WHERE x IS NOT DISTINCT FROM y" means treat NULLs equally, but I don't think we should expect the reader here to know that's what we're talking about. In any case, we're talking about existing wording here, not something David is adding. David
The revised patch is good. Please go ahead and commit whatever phrasing you or the other committers find acceptable. I don't really have any preferences in how this is exactly phrased, I just think it should be mentioned in the docs. On Mon, Apr 17, 2023 at 11:15 PM David Rowley <dgrowleyml@gmail.com> wrote: > > On Thu, 13 Apr 2023 at 02:40, David Gilman <davidgilman1@gmail.com> wrote: > > The SQL Language part of the docs has a brief page on unique indexes. > > It doesn't mention the new NULLS NOT DISTINCT functionality on unique > > indexes and this is a good place to mention it, as it already warns > > the user about the old/default behavior. > > I think we should do this and apply it to v15 too. > > It seems like a good idea to include the [NULLS [NOT] DISTINCT] in the > syntax synopsis too. Otherwise, the reader of that page is just left > guessing where they'll put NULLS NOT DISTINCT to get the behaviour > you've added the text for. > > I've attached an updated patch with that plus 2 very small wording > tweaks to your proposed text. > > David -- David Gilman :DG<
On Thu, 20 Apr 2023 at 12:04, David Gilman <davidgilman1@gmail.com> wrote: > The revised patch is good. Please go ahead and commit whatever > phrasing you or the other committers find acceptable. I don't really > have any preferences in how this is exactly phrased, I just think it > should be mentioned in the docs. Thanks. With that, I admit to further adjusting the wording before I pushed the result. David