|
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 ~/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 |
|
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. |
|
On Thu, Jun 10, 2021 at 9:31 AM Peter Eisentraut <
> wrote:
On 10.06.21 09:26, David Rowley wrote: I use both commonly, but the argument for "an S-Q-L ..." is strong I think - and I definitely think consistency is good.
+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.
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.
|
|
> 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/ |
|
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 |
|
In reply to
this post
by David Rowley
On Thu, Jun 10, 2021 at 1:27 AM David Rowley <
> wrote:
+1
Consistency is good.
Roberto
|
|
In reply to
this post
by David Rowley
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 |
|
In reply to
this post
by 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 |
|
On Thu, 10 Jun 2021 at 10:43, David Rowley <
> wrote:
- requires an MIT Kerberos installation and opens TCP/IP listen sockets. “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:
|
|
In reply to
this post
by Álvaro Herrera
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 |
|
In reply to
this post
by Álvaro Herrera
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 |
|
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 |
|
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 |
|
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/ |
|
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 |
|
In reply to
this post
by Isaac Morland
On 11/06/21 2:48 am, Isaac Morland wrote:
> On Thu, 10 Jun 2021 at 10:43, David Rowley < > > > - 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/ > < https://mitadmissions.org/blogs/entry/como_se_dice/ > > 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 |
|
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 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.
|
|
On 11/06/21 8:17 am, Isaac Morland wrote:
> 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/ > < https://mitadmissions.org/blogs/entry/como_se_dice/ > > > < https://mitadmissions.org/blogs/entry/como_se_dice/ > < 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. > it is almost silent. So using 'an historic occasion' is correct. |
|
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 |
|
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 |
| Free forum by Nabble | Edit this page |