[HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDEDfor range partition b
От | Robert Haas |
---|---|
Тема | [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDEDfor range partition b |
Дата | |
Msg-id | CA+TgmoYKc8z25nqLc8G=VB8W-N7Z8kFKR+F5y6y8J0LF+AWEDg@mail.gmail.com обсуждение исходный текст |
Ответ на | [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDEDfor range partition b (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Ответы |
Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE insteadof UNBOUNDED for range partition b
|
Список | pgsql-hackers |
On Tue, Aug 8, 2017 at 7:33 PM, Dean Rasheed <dean.a.rasheed@gmail.com> wrote: > Well perhaps verbosity-reduction isn't sufficient justification but I > still think this is correct because logically any values in the bound > after MINVALUE/MAXVALUE are irrelevant, so it seems overly restrictive > to force all later values to be MINVALUE/MAXVALUE when the code will > just ignore those values. I just don't understand why you think there should be multiple spellings of the same bound. Generally, canonicalization is good. One of my fears here is that at least some people will get confused and think a bound from (minvalue, 0) to (maxvalue, 10) allows any value for the first column and a 0-9 value for the second column which is wrong. My other fear is that, since you've not only allowed this into the syntax but into the catalog, this will become a source of bugs for years to come. Every future patch that deals with partition bounds will now have to worry about testing unbounded-followed-by-non-unbounded. If we're not going to put back those error checks completely - and I think we should - we should at least canonicalize what actually gets stored. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: