Re: "an SQL" vs. "a SQL"

[David Rowley]

On Tue, 9 Apr 2024 at 16:18, David Rowley  wrote:
> There's just 1 instance of "a SQL" that crept into PG16 after
> d866f0374.  This probably means I'd be better off doing this in June a
> few weeks before branching...
>
> Patch attached.

Pushed.

David

Re: "an SQL" vs. "a SQL"

[David Rowley]

On Tue, 11 Apr 2023 at 17:43, David Rowley  wrote:
>
> On Fri, 11 Jun 2021 at 13:44, David Rowley  wrote:
> > Anyway, I'll set an alarm for this time next year so I can check on
> > how many inconsistencies have crept back in over the development
> > cycle.
>
> That alarm went off today.
>
> There seem to be only 3 "a SQL"s in the docs to change to "an SQL".
>
> This is a pretty old thread, so here's a link [1] to the discussion.
>
> [1] 
> https://postgr.es/m/caaphdvpml27uqfxnryo1mjddskvmqoizispvsaghke_tskx...@mail.gmail.com

Link to the old thread above.

There's just 1 instance of "a SQL" that crept into PG16 after
d866f0374.  This probably means I'd be better off doing this in June a
few weeks before branching...

Patch attached.

David
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 8ff9a520ca..2aa25f62f5 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -5479,7 +5479,7 @@ CREATE FUNCTION get_color_note (rainbow) RETURNS text AS
   
 
   
-   On the other hand, for a SQL-language function or procedure whose body
+   On the other hand, for an SQL-language function or procedure whose body
is written in SQL-standard style, the body is parsed at function
definition time and all dependencies recognized by the parser are
stored.  Thus, if we write the function above as

Re: "an SQL" vs. "a SQL"

[Michael Paquier]

On Tue, Apr 11, 2023 at 05:43:04PM +1200, David Rowley wrote:
> That alarm went off today.
> 
> There seem to be only 3 "a SQL"s in the docs to change to "an SQL".
> 
> This is a pretty old thread, so here's a link [1] to the discussion.

Good catches!
--
Michael


signature.asc
Description: PGP signature

Re: "an SQL" vs. "a SQL"

[David Rowley]

On Fri, 11 Jun 2021 at 13:44, David Rowley  wrote:
> Anyway, I'll set an alarm for this time next year so I can check on
> how many inconsistencies have crept back in over the development
> cycle.

That alarm went off today.

There seem to be only 3 "a SQL"s in the docs to change to "an SQL".

This is a pretty old thread, so here's a link [1] to the discussion.

David

[1] 
https://postgr.es/m/caaphdvpml27uqfxnryo1mjddskvmqoizispvsaghke_tskx...@mail.gmail.com


a_SQL_to_an_SQL.patch
Description: Binary data

Re: "an SQL" vs. "a SQL"

[Andrew Dunstan]

On 6/13/21 7:13 AM, Michael Paquier wrote:
> On Sun, Jun 13, 2021 at 07:36:54AM +0100, Geoff Winkless wrote:
>> On Thu, 10 Jun 2021, 15:35 Alvaro Herrera,  wrote:
>>> src/backend/libpq/auth.c:847:* has.  If it's an MD5 hash, we must do
>>> MD5 authentication, and if it's a
>>> src/backend/libpq/auth.c:848:* SCRAM secret, we must do SCRAM
>>> authentication.
>> Not sure whether you were just listing examples and you weren't suggesting
>> this should be changed, but surely "SCRAM" is pronounced "scram" and is
>> thus "a SCRAM"?
> RFC 5802 uses "a SCRAM something" commonly, but "a SCRAM" alone does
> not make sense:
> https://datatracker.ietf.org/doc/html/rfc5802
>
> The sentences quoted above look fine to me.


I don't think anyone was suggesting SCRAM should be used as a noun
rather than as an adjective. But adjectives can be preceded by an
indefinite article just as nouns can. The discussion simply left out the
implied following noun.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Re: "an SQL" vs. "a SQL"

[Michael Paquier]

On Sun, Jun 13, 2021 at 07:36:54AM +0100, Geoff Winkless wrote:
> On Thu, 10 Jun 2021, 15:35 Alvaro Herrera,  wrote:
>> src/backend/libpq/auth.c:847:* has.  If it's an MD5 hash, we must do
>> MD5 authentication, and if it's a
>> src/backend/libpq/auth.c:848:* SCRAM secret, we must do SCRAM
>> authentication.
> 
> Not sure whether you were just listing examples and you weren't suggesting
> this should be changed, but surely "SCRAM" is pronounced "scram" and is
> thus "a SCRAM"?

RFC 5802 uses "a SCRAM something" commonly, but "a SCRAM" alone does
not make sense:
https://datatracker.ietf.org/doc/html/rfc5802

The sentences quoted above look fine to me.
--
Michael


signature.asc
Description: PGP signature

Re: "an SQL" vs. "a SQL"

[Geoff Winkless]

On Thu, 10 Jun 2021, 15:35 Alvaro Herrera,  wrote:

> src/backend/libpq/auth.c:847:* has.  If it's an MD5 hash, we must do
> MD5 authentication, and if it's a
> src/backend/libpq/auth.c:848:* SCRAM secret, we must do SCRAM
> authentication.
>

Not sure whether you were just listing examples and you weren't suggesting
this should be changed, but surely "SCRAM" is pronounced "scram" and is
thus "a SCRAM"?

Geoff

Re: "an SQL" vs. "a SQL"

[Bruce Momjian]

On Thu, Jun 10, 2021 at 05:39:00PM -0400, Andrew Dunstan wrote:
> I suspect "an historic" is bordering on archaic even in the UK these days.

Don't trigger me on the difference between "historic" and "historical"!  ;-)

(Hey, not every day I get to trim quoted text to one line --- see recent
pgsql-general discussion of the topic.)

-- 
  Bruce Momjian  https://momjian.us
  EDB  https://enterprisedb.com

  If only the physical world exists, free will is an illusion.

Re: "an SQL" vs. "a SQL"

[David Rowley]

On Fri, 11 Jun 2021 at 04:04, Tom Lane  wrote:
> However, I'm also
> unlikely to worry about this point when copy-editing docs.

I'm sorry to hear that.  Maybe keeping this consistent will be one of
those endless jobs like keeping the source code pgindented. We still
try to keep that in order despite the audience for the source code
being much smaller than the audience for our documents.

Anyway, I'll set an alarm for this time next year so I can check on
how many inconsistencies have crept back in over the development
cycle.

In the meantime, I've pushed the fixes to master.

David

Re: "an SQL" vs. "a SQL"

[David Rowley]

On Fri, 11 Jun 2021 at 09:39, Andrew Dunstan  wrote:
> I suspect "an historic" is bordering on archaic even in the UK these days.

Yeah, that's a weird one. Maybe
https://en.wikipedia.org/wiki/H-dropping is to blame.

David

Re: "an SQL" vs. "a SQL"

[David Rowley]

On Fri, 11 Jun 2021 at 02:48, Isaac Morland  wrote:
>
> On Thu, 10 Jun 2021 at 10:43, David Rowley  wrote:
>>
>> -   requires an MIT Kerberos installation and opens TCP/IP listen 
>> sockets.
>> +   requires a MIT Kerberos installation and opens TCP/IP listen sockets.
>>
>> I think all of these should use "a" rather than "an".
>
>
> “A MIT …”? As far as I know it is pronounced M - I - T, which would imply 
> that it should use “an”. The following page seems believable and is pretty 
> unequivocal on the issue:
>
> https://mitadmissions.org/blogs/entry/como_se_dice/

Opps. I'm not sure what I was thinking there.  I'd just been listening
to something in German, so maybe I'd had the German word in mind
instead.

David

Re: "an SQL" vs. "a SQL"

[Andrew Dunstan]

On 6/10/21 5:32 PM, Tom Lane wrote:
> Gavin Flower  writes:
>> On 11/06/21 8:17 am, Isaac Morland wrote:
>>> ... But then there is "an historic occasion" so go figure.
>> The 'h' in 'historic' is silent, at least it used to be -- I think now 
>> it is almost silent.  So using 'an historic occasion' is correct.
> It's silent according to the Brits, I believe.  In America, the
> pronunciation varies.
>
>   


I suspect "an historic" is bordering on archaic even in the UK these days.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Re: "an SQL" vs. "a SQL"

[Tom Lane]

Gavin Flower  writes:
> On 11/06/21 8:17 am, Isaac Morland wrote:
>> ... But then there is "an historic occasion" so go figure.

> The 'h' in 'historic' is silent, at least it used to be -- I think now 
> it is almost silent.  So using 'an historic occasion' is correct.

It's silent according to the Brits, I believe.  In America, the
pronunciation varies.

regards, tom lane

Re: "an SQL" vs. "a SQL"

[Gavin Flower]

On 11/06/21 8:17 am, Isaac Morland wrote:
On Thu, 10 Jun 2021 at 16:11, Gavin Flower 
mailto:gavinflo...@archidevsys.co.nz>> 
wrote:


On 11/06/21 2:48 am, Isaac Morland wrote:

> “A MIT …”? As far as I know it is pronounced M - I - T, which would
> imply that it should use “an”. The following page seems
believable and
> is pretty unequivocal on the issue:
>
> https://mitadmissions.org/blogs/entry/como_se_dice/

> >
>
The rule is, in English, is that if the word sounds like it starts
with
a vowel then use 'an' rather than 'a'.  Though some people think that
the rule only applies to words beginning with a vowel, which is a
misunderstanding.

So 'an SQL' and 'an MIT'  are correct.   IMHO


Right, spelling is irrelevant, it's about whether the word begins with 
a vowel *sound*. Or so I've always understood and I'm pretty sure if 
you listen to what people actually say that's what you'll generally 
hear. So "A uranium mine" not "An uranium mine" since "uranium" begins 
with a "y-" sound just like "yesterday". The fact that "u" is a vowel 
is irrelevant. But then there is "an historic occasion" so go figure.


The 'h' in 'historic' is silent, at least it used to be -- I think now 
it is almost silent.  So using 'an historic occasion' is correct.

Re: "an SQL" vs. "a SQL"

[Isaac Morland]

On Thu, 10 Jun 2021 at 16:11, Gavin Flower 
wrote:

> On 11/06/21 2:48 am, Isaac Morland wrote:
>


> > “A MIT …”? As far as I know it is pronounced M - I - T, which would
> > imply that it should use “an”. The following page seems believable and
> > is pretty unequivocal on the issue:
> >
> > https://mitadmissions.org/blogs/entry/como_se_dice/
> > 
> >
> The rule is, in English, is that if the word sounds like it starts with
> a vowel then use 'an' rather than 'a'.  Though some people think that
> the rule only applies to words beginning with a vowel, which is a
> misunderstanding.
>
> So 'an SQL' and 'an MIT'  are correct.   IMHO
>

Right, spelling is irrelevant, it's about whether the word begins with a
vowel *sound*. Or so I've always understood and I'm pretty sure if you
listen to what people actually say that's what you'll generally hear. So "A
uranium mine" not "An uranium mine" since "uranium" begins with a "y-"
sound just like "yesterday". The fact that "u" is a vowel is irrelevant.
But then there is "an historic occasion" so go figure.

Re: "an SQL" vs. "a SQL"

[Gavin Flower]

On 11/06/21 2:48 am, Isaac Morland wrote:
On Thu, 10 Jun 2021 at 10:43, David Rowley > wrote:


-      requires an MIT Kerberos installation and opens TCP/IP
listen sockets.
+       requires a MIT Kerberos installation and opens TCP/IP
listen sockets.

I think all of these should use "a" rather than "an".


“A MIT …”? As far as I know it is pronounced M - I - T, which would 
imply that it should use “an”. The following page seems believable and 
is pretty unequivocal on the issue:


https://mitadmissions.org/blogs/entry/como_se_dice/ 



The rule is, in English, is that if the word sounds like it starts with 
a vowel then use 'an' rather than 'a'.  Though some people think that 
the rule only applies to words beginning with a vowel, which is a 
misunderstanding.


So 'an SQL' and 'an MIT'  are correct.   IMHO


Cheers,
Gavin

Re: "an SQL" vs. "a SQL"

[Tom Lane]

David Rowley  writes:
> If you really feel that strongly about not changing this then I can
> drop this. However, I'll likely growl every time I see "a SQL" in the
> docs from now on.

[ shrug... ]  I'm not going to stand in your way.  However, I'm also
unlikely to worry about this point when copy-editing docs.

regards, tom lane

Re: "an SQL" vs. "a SQL"

[David Rowley]

On Fri, 11 Jun 2021 at 03:24, Tom Lane  wrote:
> If there were some semblance of an overall consensus on the spelling,
> I'd be fine with weeding out the stragglers.  But when the existing
> usages are only about 2-to-1 in one direction or the other, I feel
> quite confident in predicting that incoming patches are often going
> to get this wrong.

I'm pretty sure you're right and we will get some inconsistencies
creeping back in. I'm not really sure why you think that will be hard
to fix though.  If we catch them soon enough then we won't need to
worry about causing future backpatching pain.

> Especially so if the convention you want to
> establish in the docs is contrary to the majority usage in the code
> comments --- how is that not going to confuse people?

Why would someone go and gawk at code comments to clear up their
confusion about what they should write in the docs?  I think any sane
person that's looking for inspiration would look at the docs first.

I really think it's worth the trouble here to be consistent in our
public-facing documents.  When I read [1] earlier and the blog started
talking about Oracle documentation using sequel consistently before
going on to talk about MySQL's documentation, I started to get a bit
worried that the author might mention something about our lack of
consistency. I was glad to see they missed us out of that.  However,
maybe that's because we are inconsistent.

If you really feel that strongly about not changing this then I can
drop this. However, I'll likely growl every time I see "a SQL" in the
docs from now on.

David

[1] http://patorjk.com/blog/2012/01/26/pronouncing-sql-s-q-l-or-sequel/

Re: "an SQL" vs. "a SQL"

[Tom Lane]

David Rowley  writes:
> On Fri, 11 Jun 2021 at 02:53, Tom Lane  wrote:
>> Indeed.  I think this is entirely pointless; there's zero hope that
>> any consistency you might establish right now will persist very long.

> hmm.  Yet we do have other standards which we do manage to maintain.

If there were some semblance of an overall consensus on the spelling,
I'd be fine with weeding out the stragglers.  But when the existing
usages are only about 2-to-1 in one direction or the other, I feel
quite confident in predicting that incoming patches are often going
to get this wrong.  Especially so if the convention you want to
establish in the docs is contrary to the majority usage in the code
comments --- how is that not going to confuse people?

regards, tom lane

Re: "an SQL" vs. "a SQL"

[David Rowley]

On Fri, 11 Jun 2021 at 02:53, Tom Lane  wrote:
> Indeed.  I think this is entirely pointless; there's zero hope that
> any consistency you might establish right now will persist very long.
> The largest effect of this proposed patch will be to create
> back-patching headaches.

hmm.  Yet we do have other standards which we do manage to maintain.

I did limit the scope to just the docs and error messages. My thoughts
were that someone fudging a backpatch on the docs seems less likely to
cause a nuclear meltdown than someone doing the same in .c code.

David

Re: "an SQL" vs. "a SQL"

[Tom Lane]

Alvaro Herrera  writes:
> On 2021-Jun-10, David Rowley wrote:
>> It seems we have no standard as to if we say "a SQL" or "an SQL".

> I was just reading the standard a couple of days ago and happened to
> notice that the standard itself in some places uses "a SQL" and in other
> places "an SQL".  I didn't stop to make an analysis of that, so I don't
> know how prevalent each form is -- I just giggled and moved on.

Indeed.  I think this is entirely pointless; there's zero hope that
any consistency you might establish right now will persist very long.
The largest effect of this proposed patch will be to create
back-patching headaches.

regards, tom lane

Re: "an SQL" vs. "a SQL"

[David Rowley]

On Fri, 11 Jun 2021 at 02:35, Alvaro Herrera  wrote:
>
> On 2021-Jun-10, David Rowley wrote:
> > My regex foo is not strong enough to think how I might find multiline 
> > instances.
>
> This catches some of these:
>
> ag "\sa[\s*]*\n[\s*]*(A|E|F|H|I|L|M|N|O|S|X)[A-Z]{2,5}\s"

Thanks. I ended up using -C 1 and manually checking the previous line.

> You get a bunch of "a NULL" or "a NOT" and so on, but here's a few valid ones:
>
> contrib/tablefunc/tablefunc.c:316: * crosstab - create a crosstab of rowids 
> and values columns from a
> contrib/tablefunc/tablefunc.c:317: * SQL statement returning one rowid 
> column, one category column,
>
> contrib/tablefunc/tablefunc.c:607: * crosstab - create a crosstab of rowids 
> and values columns from a
> contrib/tablefunc/tablefunc.c:608: * SQL statement returning one rowid 
> column, one category column,
>
> doc/src/sgml/plpgsql.sgml
> 1127: The result of a
> 1128: SQL command yielding a single row (possibly of multiple
>
> src/backend/catalog/pg_subscription.c:438:   * 
> translator: first %s is a SQL ALTER command and second %s is a
> src/backend/catalog/pg_subscription.c:439:   * SQL DROP 
> command
>
> src/backend/replication/logical/logical.c:126:   * 1) We need to be able to 
> correctly and quickly identify the timeline a
> src/backend/replication/logical/logical.c:127:   *LSN belongs to
>
> src/backend/libpq/auth.c:847:* has.  If it's an MD5 hash, we must do MD5 
> authentication, and if it's a
> src/backend/libpq/auth.c:848:* SCRAM secret, we must do SCRAM 
> authentication.

Thanks. I've left all the .c file comments alone for no and looks like
I got the doc/src/sgml/plpgsql.sgml one already.

David

Re: "an SQL" vs. "a SQL"

[Isaac Morland]

On Thu, 10 Jun 2021 at 10:43, David Rowley  wrote:

> -   requires an MIT Kerberos installation and opens TCP/IP listen
> sockets.
> +   requires a MIT Kerberos installation and opens TCP/IP listen
> sockets.
>
> I think all of these should use "a" rather than "an".
>

“A MIT …”? As far as I know it is pronounced M - I - T, which would imply
that it should use “an”. The following page seems believable and is pretty
unequivocal on the issue:

https://mitadmissions.org/blogs/entry/como_se_dice/

Re: "an SQL" vs. "a SQL"

[David Rowley]

On Fri, 11 Jun 2021 at 02:04, David Rowley  wrote:
> I came up with the attached patch.

Further searching using:

git grep -E "\s(an|An)\s(F|H|L|M|N|S|X)[A-Z]{2,5}"

(i.e vowel sounding, but not actually starting with a vowel then
manually looking for pronounceable ones.)

-  by a response from client in an SASLResponse message. The particulars of
+  by a response from client in a SASLResponse message. The particulars of

- An SHA1 hash of the random prefix and data is appended.
+ A SHA1 hash of the random prefix and data is appended.

-   requires an MIT Kerberos installation and opens TCP/IP listen sockets.
+   requires a MIT Kerberos installation and opens TCP/IP listen sockets.

I think all of these should use "a" rather than "an".

David

Re: "an SQL" vs. "a SQL"

[Alvaro Herrera]

On 2021-Jun-10, David Rowley wrote:

> I thought it might be worth having this conversation before we branch for v15.
> 
> It seems we have no standard as to if we say "a SQL" or "an SQL".

I was just reading the standard a couple of days ago and happened to
notice that the standard itself in some places uses "a SQL" and in other
places "an SQL".  I didn't stop to make an analysis of that, so I don't
know how prevalent each form is -- I just giggled and moved on.

> My regex foo is not strong enough to think how I might find multiline 
> instances.

This catches some of these:

ag "\sa[\s*]*\n[\s*]*(A|E|F|H|I|L|M|N|O|S|X)[A-Z]{2,5}\s"

You get a bunch of "a NULL" or "a NOT" and so on, but here's a few valid ones:

contrib/tablefunc/tablefunc.c:316: * crosstab - create a crosstab of rowids and 
values columns from a
contrib/tablefunc/tablefunc.c:317: * SQL statement returning one rowid column, 
one category column,

contrib/tablefunc/tablefunc.c:607: * crosstab - create a crosstab of rowids and 
values columns from a
contrib/tablefunc/tablefunc.c:608: * SQL statement returning one rowid column, 
one category column,

doc/src/sgml/plpgsql.sgml
1127: The result of a
1128: SQL command yielding a single row (possibly of multiple

src/backend/catalog/pg_subscription.c:438:   * translator: 
first %s is a SQL ALTER command and second %s is a
src/backend/catalog/pg_subscription.c:439:   * SQL DROP 
command

src/backend/replication/logical/logical.c:126:   * 1) We need to be able to 
correctly and quickly identify the timeline a
src/backend/replication/logical/logical.c:127:   *LSN belongs to

src/backend/libpq/auth.c:847:* has.  If it's an MD5 hash, we must do MD5 
authentication, and if it's a
src/backend/libpq/auth.c:848:* SCRAM secret, we must do SCRAM 
authentication.

-- 
Álvaro Herrera   Valdivia, Chile

Re: "an SQL" vs. "a SQL"

[Roberto Mello]

On Thu, Jun 10, 2021 at 1:27 AM David Rowley  wrote:

>
> I think we should change all 55 instances of "a SQL" in the docs to
> use "an SQL" and leave the 800 other instances of "a SQL" alone.


+1

Consistency is good.

Roberto

Re: "an SQL" vs. "a SQL"

[David Rowley]

On Thu, 10 Jun 2021 at 20:58, Daniel Gustafsson  wrote:
>
> > On 10 Jun 2021, at 10:54, Dave Page  wrote:
>
> > .. I would perhaps suggest extending to any user-visible messages in the 
> > code.
>
> I agree, consistent language between docs and user-facing messages is
> important.

Yeah, agreed.

I came up with the attached patch.

The only additional abbreviation that I found to be incorrect that I'd
previously not mentioned was "SRF".  I changed that to use "an".

I only found 4 error messages that needed to be updated.  There's some
incorrect stuff remaining in a few README files which I couldn't
decide if I should update or not.

Most of the offenders away from the docs are the translator hint
comments and within the .po files themselves.

$ git grep -E "translator:.*(a|A)\sSQL" | wc -l
690

Only 816 instances of "a SQL" remain, so only 126 are not related to
translator hints or .po files.

Does anyone have any thoughts if the READMEs should be fixed up?

David


use_correct_article_with_vowel_sounding_abbreviations.patch
Description: Binary data

Re: "an SQL" vs. "a SQL"

[Daniel Gustafsson]

> On 10 Jun 2021, at 10:54, Dave Page  wrote:

> .. I would perhaps suggest extending to any user-visible messages in the code.

I agree, consistent language between docs and user-facing messages is
important.

--
Daniel Gustafsson   https://vmware.com/

Re: "an SQL" vs. "a SQL"

[Dave Page]

On Thu, Jun 10, 2021 at 9:31 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:

> On 10.06.21 09:26, David Rowley wrote:
> > It seems we have no standard as to if we say "a SQL" or "an SQL".
>
> The SQL standard uses "an SQL-something".
>

I use both commonly, but the argument for "an S-Q-L ..." is strong I think
- and I definitely think consistency is good.


>
> > However, we mostly use "an SQL"  in the docs.
> >
> > ~/pg_src$ cd doc/
> > ~/pg_src/doc$ git grep -E "\s(a|A)\sSQL\s" | wc -l
> > 55
> > ~/pg_src/doc$ git grep -E "\s(an|An)\sSQL\s" | wc -l
> > 94
> >
> > I think we should change all 55 instances of "a SQL" in the docs to
> > use "an SQL" and leave the 800 other instances of "a SQL" alone.
> > Changing those does not seem worthwhile as it could cause
> > back-patching pain.
>
> agreed
>

+1 in general, though I would perhaps suggest extending to any user-visible
messages in the code. I don't think there's any point in messing with
comments etc. I'm not sure what that would do to the numbers though.


>
> > Further, there might be a few more in the docs that we might want to
> > consider changing:
> >
> > git grep -E "\sa\s(A|E|F|H|I|L|M|N|O|S|X)[A-Z]{2,5}\s"
> >
> > I see "a FSM", "a FIFO", "a SSPI", "a SASL", "a MCV", "a SHA", "a SQLDA"
> >
> > My regex foo is not strong enough to think how I might find multiline
> instances.
>
> Um, of those, I pronounce FIFO, SASL, and SHA as words, with an "a"
> article.
>

Same here. I've never heard anyone try to pronounce SSPI, so I would expect
that to be "an SSPI ...". The other remaining ones (FSM, MCV & SQLDA) I
would also argue aren't pronounceable, so should use the "an" article.

-- 
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

Re: "an SQL" vs. "a SQL"

[Peter Eisentraut]

On 10.06.21 09:26, David Rowley wrote:

It seems we have no standard as to if we say "a SQL" or "an SQL".


The SQL standard uses "an SQL-something".


However, we mostly use "an SQL"  in the docs.

~/pg_src$ cd doc/
~/pg_src/doc$ git grep -E "\s(a|A)\sSQL\s" | wc -l
55
~/pg_src/doc$ git grep -E "\s(an|An)\sSQL\s" | wc -l
94

I think we should change all 55 instances of "a SQL" in the docs to
use "an SQL" and leave the 800 other instances of "a SQL" alone.
Changing those does not seem worthwhile as it could cause
back-patching pain.


agreed


Further, there might be a few more in the docs that we might want to
consider changing:

git grep -E "\sa\s(A|E|F|H|I|L|M|N|O|S|X)[A-Z]{2,5}\s"

I see "a FSM", "a FIFO", "a SSPI", "a SASL", "a MCV", "a SHA", "a SQLDA"

My regex foo is not strong enough to think how I might find multiline instances.


Um, of those, I pronounce FIFO, SASL, and SHA as words, with an "a" article.

"an SQL" vs. "a SQL"

[David Rowley]

I thought it might be worth having this conversation before we branch for v15.

It seems we have no standard as to if we say "a SQL" or "an SQL".

Personally, I pronounce the language as es-que-ell, so I'd write "an
SQL".  If you say "sequel", then you'll think differently. The reason
I do this is that the language was only briefly named sequel but was
renamed to SQL. For me calling it sequel seems wrong or out-dated. End
of personal opinion.

Let this thread not become the place where you tell me why I'm wrong.
Let's just get some consensus on something, make a change then move
on.

Overall we seem to mostly write "a SQL".

~/pg_src$ git grep -E "\s(a|A)\sSQL\s" | wc -l
855
~/pg_src$ git grep -E "\s(an|An)\sSQL\s" | wc -l
295

However, we mostly use "an SQL"  in the docs.

~/pg_src$ cd doc/
~/pg_src/doc$ git grep -E "\s(a|A)\sSQL\s" | wc -l
55
~/pg_src/doc$ git grep -E "\s(an|An)\sSQL\s" | wc -l
94

I think we should change all 55 instances of "a SQL" in the docs to
use "an SQL" and leave the 800 other instances of "a SQL" alone.
Changing those does not seem worthwhile as it could cause
back-patching pain.

I mostly think that because of the fact that my personal opinion
agrees with the majority of instances in the docs. Makes more sense to
change 55 places than 94 places.

Interesting reading:
http://patorjk.com/blog/2012/01/26/pronouncing-sql-s-q-l-or-sequel/

Further, there might be a few more in the docs that we might want to
consider changing:

git grep -E "\sa\s(A|E|F|H|I|L|M|N|O|S|X)[A-Z]{2,5}\s"

I see "a FSM", "a FIFO", "a SSPI", "a SASL", "a MCV", "a SHA", "a SQLDA"

My regex foo is not strong enough to think how I might find multiline instances.

David