Re: [HACKERS] Support to COMMENT ON DATABASE CURRENT_DATABASE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jing Wang <jingwangian(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Surafel Temesgen <surafel3000(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>
Subject: Re: [HACKERS] Support to COMMENT ON DATABASE CURRENT_DATABASE
Date: 2018-03-01 19:09:33
Message-ID: 25550.1519931373@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jing Wang <jingwangian(at)gmail(dot)com> writes:
> [ support_CURRENT_DATABASE_keyword_v4.7.patch ]

TBH, I think we should reject this patch. While it's not huge,
it's not trivial either, and I find the grammar changes rather ugly.
The argument for using the feature to fix pg_dump issues has evaporated,
but I don't see anything in the discussion suggesting that people see
a need for it beyond that.

I particularly object to inventing a CURRENT_DATABASE parameterless
function. That's encroaching on user namespace to no purpose whatever,
as we already have a perfectly good regular function for that.

Also, from a user standpoint, turning CURRENT_DATABASE into a fully
reserved word seems like a bad idea. If nothing else, that breaks
queries that are relying on the existing current_database() function.
The parallel to CURRENT_ROLE is not very good, because there at least
we can point to the SQL spec and say it's reserved according to the
standard. CURRENT_DATABASE has no such excuse.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-03-01 19:13:39 Re: [HACKERS] path toward faster partition pruning
Previous Message Peter Geoghegan 2018-03-01 19:06:09 Re: [HACKERS] MERGE SQL Statement for PG11