public inbox for [email protected]  

help / color / mirror / Atom feed

From: Erik Wienhold <[email protected]>
To: David Rowley <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: Nathan Bossart <[email protected]>
Cc: Euler Taveira <[email protected]>
Cc: [email protected]
Subject: Re: Use uppercase keywords in foreign key tutorial
Date: Tue, 4 Nov 2025 01:04:38 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAApHDvraaZLdTm4XTLkgGhUwecpmNm1dOJMcEToak-Bh5742hQ@mail.gmail.com>
References: <CAApHDvoLfa2UjGfoGfVL4b=g5VbFgscrLONuC3kKE9=VZeeN=Q@mail.gmail.com>
	<[email protected]>
	<aQE29YG5pY4Cl8ym@nathan>
	<[email protected]>
	<[email protected]>
	<CAApHDvqR+_EU0mxrmS-AieE_8ovqtmnsJSOk-oq-Rdk3JzNWOg@mail.gmail.com>
	<[email protected]>
	<CAApHDvoqh_K2KTocwWYrGw5vLubnPnTzd1SvYTTonQ=vUXP7Ug@mail.gmail.com>
	<[email protected]>
	<CAApHDvraaZLdTm4XTLkgGhUwecpmNm1dOJMcEToak-Bh5742hQ@mail.gmail.com>

On 2025-11-03 23:37 +0100, David Rowley wrote:
> On Tue, 4 Nov 2025 at 09:06, Erik Wienhold <[email protected]> wrote:
> > Fixed in the attached v4.  Except for one match in dblink.sgml that
> > is the sample output of dblink_build_sql_insert which actually omits
> > the space after the table name and VALUES keyword.
> 
> I went through all these and I think it's mostly good.

Thanks.

> However...
> 
> It seems strange to me that you've made so many changes to transform
> "CREATE TABLE foo(" into "CREATE TABLE foo (", but you've done the
> opposite for CREATE FUNCTION and CREATE PROCEDURE. Did you go with the
> majority rules here?

Yes, CREATE FUNCTION with an extra space after the name is the
exception.  On master I count 29 (w/ space) vs. 249 (w/o space) matches:

$ git grep -Ei 'create(\s+or\s+replace)?\s+(function|procedure)\s+\w+(\.\w+)?\s+\(' doc | wc -l
29
$ git grep -Ei 'create(\s+or\s+replace)?\s+(function|procedure)\s+\w+(\.\w+)?\(' doc | wc -l
249

I also see similar counts for CREATE TABLE, but with the
one-space-after-table-name variant being more common:

$ git grep -Ei 'create\s+table(\s+if\s+not\+sexists)?\s+\w+(\.\w+)?\s+\(' doc | wc -l
213
$ git grep -Ei 'create\s+table(\s+if\s+not\+sexists)?\s+\w+(\.\w+)?\(' doc | wc -l
34

The attached v5 fixes a couple of more places that I missed in v4.

> It just seems a bit hard to follow what the standard is being enforced
> here and if that's hard to understand now, what hope is there of
> people following that in the future?

I follow this rule/standard/convention which also matches what I already
find in most parts of the docs:

* No extra space for function calls, e.g.
  extract(YEAR FROM now())

* Extra space for everything else, e.g.
  VALUES (1, 2);
  CREATE TABLE foo ();

> I'm starting to wonder if adjusting the spacing here is a worthwhile
> change.

I think it's worth to have that consistency.  If the patch is too broad
I can of course limit it to the listings with inconsistent keyword
casing which is more less patch v2 plus some changes from v3 and later.

Or just fix the keywords for now to get that out of the way and deal
with the spacing in a separate patch/thread.

-- 
Erik Wienhold

view thread (25+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Use uppercase keywords in foreign key tutorial
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox