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-01-22 19:39:10
Message-ID: 7586.1516649950@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.6.patch ]

Not surprisingly, this patch no longer applies in the wake of commit
b3f840120. Rather than rebasing the pg_dump portions, I would suggest
you just drop them. It is no longer necessary for pg_dump to worry about
this, because it won't emit COMMENT ON DATABASE or SECURITY LABEL FOR
DATABASE except in cases where it just created the target database
and so knows the DB name for sure. So, using COMMENT ON DATABASE
CURRENT_DATABASE would just create an unnecessary version dependency
in the output script. (BTW, using the source database's version to decide
what to emit is not per pg_dump policy. Also, if you did still want to
modify pg_dump to use CURRENT_DATABASE, you'd have to extend the patch
to handle ACLs and some other ALTER DATABASE commands.)

I'm not really sure how much of the use-case for this feature rested
on the pg_dump issue. It may still be worthwhile for other use cases,
or maybe we should just drop it.

I notice some other patch application failures in dbcommands.c,
objectaddress.c, and user.c, so there's more work to do besides
this ...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-01-22 19:47:36 Re: pgsql: Move handling of database properties from pg_dumpall into pg_dum
Previous Message Robert Haas 2018-01-22 19:26:06 Re: pgsql: Move handling of database properties from pg_dumpall into pg_dum