Re: Add Postgres module info
| От | Yurii Rashkovskii |
|---|---|
| Тема | Re: Add Postgres module info |
| Дата | |
| Msg-id | CAG=VW15KoiU+rSTWf4JatO57Med1-H3gqDPQxKVNV6pj8Lmqgw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Add Postgres module info (Andrei Lepikhov <lepihov@gmail.com>) |
| Список | pgsql-hackers |
On Fri, Dec 27, 2024 at 8:34 AM Andrei Lepikhov <lepihov@gmail.com> wrote:
On 12/24/24 10:42, Yurii Rashkovskii wrote:
> On Mon, Dec 16, 2024 at 12:02 PM Andrei Lepikhov <lepihov@gmail.com
> I've reviewed the patch, and it is great that you support more flexible
> versioning now. I am just wondering a bit about the case where `minfo-
> >name` can be `NULL` but `minfo->version` isn't, or where both are
> `NULL` – should we skip any of these?
Depends. I wrote code that way so as not to restrict a maintainer by
initialising all the fields; remember, it may grow in the future.
But I am open to changing that logic. Do you have any specific rule on
which fields may be empty and that must be initialised? Do you think all
fields maintainer must fill with non-zero-length constants?
After more thinking, I'll concede that not doing anything about null metadata is probably better – making the function always return the list of modules, regardless of whether any metadata was supplied. It's beneficial to be able to get the entire list of modules regardless of metadata.
The only other minor concern I have left is that some modules might have a clashing name or may change the name during the extension's lifetime (happened to some of my early work). Providing a permanent identifier and a human-digestible identifier may be worth it.
В списке pgsql-hackers по дате отправления: