Re: Proposal to have INCLUDE/EXCLUDE options for altering option values

From: "Euler Taveira" <euler(at)eulerto(dot)com>
To: "Ayush Vatsa" <ayushvatsa1810(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal to have INCLUDE/EXCLUDE options for altering option values
Date: 2024-08-26 17:47:43
Message-ID: 33389809-37e7-4be3-87b3-9582aa40ec12@app.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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
EDB https://www.enterprisedb.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2024-08-26 17:54:13 Re: thread-safety: getpwuid_r()
Previous Message Peter Eisentraut 2024-08-26 17:38:59 Re: thread-safety: getpwuid_r()