Re: Proposal to have INCLUDE/EXCLUDE options for altering option values - Mailing list pgsql-hackers

From Euler Taveira
Subject Re: Proposal to have INCLUDE/EXCLUDE options for altering option values
Date
Msg-id 33389809-37e7-4be3-87b3-9582aa40ec12@app.fastmail.com
Whole thread Raw
In response to Proposal to have INCLUDE/EXCLUDE options for altering option values  (Ayush Vatsa <ayushvatsa1810@gmail.com>)
Responses Re: Proposal to have INCLUDE/EXCLUDE options for altering option values
List pgsql-hackers
On Mon, Aug 26, 2024, at 1:34 PM, Ayush Vatsa wrote:
I noticed that my last commit needs rebase through cfbot - http://cfbot.cputube.org/ayush-vatsa.html
PFA the rebased patch for the same.


There is no list concept for OPTIONS. What happen if you use it in a non-list
value?

ALTER SERVER foo OPTIONS(ADD bar '1');
ALTER SERVER foo OPTIONS(REMOVE bar '1');

Error? Remove option 'bar'?

This proposal is not idempotent. It means that at the end of the SQL commands,
the final state is not predictable. That's disappointed since some tools rely on
this property to create migration scripts.

The syntax is not SQL standard. It does not mean that we cannot extend the
standard but sometimes it is a sign that it is not very useful or the current syntax
already covers all cases.

AFAICS this proposal also represents a tiny use case. The options to define a
foreign server don't generally include a list as value. And if so, it is not
common to change the foreign server options.

I also think that REMOVE is a synonym for DROP. It would be confuse to explain
that REMOVE is for list elements and DROP is for the list.

I'm not convinced that this new syntax improves the user experience.


--
Euler Taveira

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: allowing extensions to control planner behavior
Next
From: Heikki Linnakangas
Date:
Subject: Re: thread-safety: getpwuid_r()