Re: Proposal to have INCLUDE/EXCLUDE options for altering option values
| От | Euler Taveira |
|---|---|
| Тема | Re: Proposal to have INCLUDE/EXCLUDE options for altering option values |
| Дата | |
| Msg-id | 33389809-37e7-4be3-87b3-9582aa40ec12@app.fastmail.com обсуждение исходный текст |
| Ответ на | Proposal to have INCLUDE/EXCLUDE options for altering option values (Ayush Vatsa <ayushvatsa1810@gmail.com>) |
| Ответы |
Re: Proposal to have INCLUDE/EXCLUDE options for altering option values
|
| Список | 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.htmlPFA 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.
В списке pgsql-hackers по дате отправления: