Re: dfmgr additional ABI version fields
От
Tom Lane
Тема
Re: dfmgr additional ABI version fields
Дата
Msg-id
163151.1633634122@sss.pgh.pa.us
Ответ на
Re: dfmgr additional ABI version fields (Chapman Flack)
Список
Дерево обсуждения
dfmgr additional ABI version fields Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Re: dfmgr additional ABI version fields Tom Lane <tgl@sss.pgh.pa.us>
Re: dfmgr additional ABI version fields Andres Freund <andres@anarazel.de>
Re: dfmgr additional ABI version fields Tom Lane <tgl@sss.pgh.pa.us>
Re: dfmgr additional ABI version fields Chapman Flack <chap@anastigmatix.net>
Re: dfmgr additional ABI version fields Tom Lane <tgl@sss.pgh.pa.us>
Re: dfmgr additional ABI version fields Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Re: dfmgr additional ABI version fields Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Re: dfmgr additional ABI version fields Robert Haas <robertmhaas@gmail.com>
Re: dfmgr additional ABI version fields Michael Paquier <michael@paquier.xyz>
Re: dfmgr additional ABI version fields Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Re: dfmgr additional ABI version fields Tom Lane <tgl@sss.pgh.pa.us>
Re: dfmgr additional ABI version fields Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Re: dfmgr additional ABI version fields Pavel Stehule <pavel.stehule@gmail.com>
Chapman Flack writes: > On 10/07/21 12:42, Tom Lane wrote: >> Can we make the addition be a string not a number, so that we >> could include something more useful than "1234" in the error >> message? > Just using a string like "EDB v" + something would probably rule out > collisions in practice. To be more formal about it, something like > the tag URI scheme [0] could be recommended. Hmm. Personally I'm more interested in the string being comprehensible to end users than in whether there's any formal rule guaranteeing uniqueness. I really doubt that we will have any practical problem with collisions, so I'd rather go with something like "EnterpriseDB v1.2.3" than with something like "tag:enterprisedb.com,2021:1.2.3". Conceivably we could have two strings, or a printable string and a chosen-at-random unique number (the latter not meant to be shown to users). Not sure it's worth the trouble though. regards, tom lane
В списке pgsql-hackers по дате отправления