Re: pg_get__*_ddl consolidation
| От | Jelte Fennema-Nio |
|---|---|
| Тема | Re: pg_get__*_ddl consolidation |
| Дата | |
| Msg-id | DHM6C7SLS4BN.1WW9Z4PRPN0VJ@jeltef.nl обсуждение исходный текст |
| Ответ на | Re: pg_get__*_ddl consolidation (Andrew Dunstan <andrew@dunslane.net>) |
| Ответы |
Re: pg_get__*_ddl consolidation
|
| Список | pgsql-hackers |
On Mon, 6 Apr 2026 at 13:55, Andrew Dunstan <andrew@dunslane.net> wrote: > There was quite a deal of discussion around this mechanism. See Euler's > review at [1] and follow-up at [2] for the original discussion of the > VARIADIC option-parsing design and the use cases it was meant to > address. I'm prepared to revisit it is there's a strong consensus on the > point. Thanks for those links. I had not seen that part of the discussion. But I only see an explanation of why these functions are configurable with optional key+value pairs in their arguments. I think that makes sense, and I totally agree that we should do that. The thing I'm questioning is whether we need a new way of providing key+value pairs as optional arguments to functions. IMO we already had a perfectly fine one. Introducing another adds complexity (both to the code and to the user) and I don't see any compelling reason to do so. Attached is a patch with roughly what I have in mind instead. By doing this we can also make the functinos STRICT, so that we don't have to worry about handling NULL values for the first argument. Afaict this named parameter approach only has benefits over the VARIADIC argument one. But if I'm wrong about that, please let me know.
Вложения
В списке pgsql-hackers по дате отправления: