Re: BUG #16302: too many range table entries - when count partitiontable(65538 childs)
От
Peter Eisentraut
Тема
Re: BUG #16302: too many range table entries - when count partitiontable(65538 childs)
Дата
Msg-id
54912a3b-fec1-eb85-4971-46de1a1d0f5e@2ndquadrant.com
Ответ на
Re: BUG #16302: too many range table entries - when count partitiontable(65538 childs) (Robert Haas)
Список
Дерево обсуждения
BUG #16302: too many range table entries - when count partition table(65538 childs) PG Bug reporting form <noreply@postgresql.org>
Re: BUG #16302: too many range table entries - when count partition table(65538 childs) Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #16302: too many range table entries - when count partitiontable(65538 childs) Amit Langote <amitlangote09@gmail.com>
Re: BUG #16302: too many range table entries - when count partition table(65538 childs) Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #16302: too many range table entries - when count partitiontable(65538 childs) Robert Haas <robertmhaas@gmail.com>
Re: BUG #16302: too many range table entries - when count partition table(65538 childs) Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #16302: too many range table entries - when count partitiontable(65538 childs) Robert Haas <robertmhaas@gmail.com>
Re: BUG #16302: too many range table entries - when count partition table(65538 childs) Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #16302: too many range table entries - when count partitiontable(65538 childs) Robert Haas <robertmhaas@gmail.com>
Re: BUG #16302: too many range table entries - when count partitiontable(65538 childs) Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Re: BUG #16302: too many range table entries - when count partition table(65538 childs) Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #16302: too many range table entries - when count partitiontable(65538 childs) Robert Haas <robertmhaas@gmail.com>
On 2020-03-17 16:04, Robert Haas wrote: >>> (It doesn't seem like we're all that careful about whether we're using >>> int, which is signed, or Index, which is unsigned, and we might want >>> to go around and tighten that up. >> >> Yeah, I'd be leery of trying to use that last bit. The cost-benefit >> ratio on that is *definitely* not attractive. > > That seems clear, but trying to be consistent about the types we use > for things is a good idea on general principle, even if we have no > intention of doing anything that really relies on it any time in the > forseeable future. If nothing else, it might avoid some compiler > warnings. You could make INNER_VAR -1 and so on. Then it would probably break quite clearly if it's not signedness clean. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-bugs по дате отправления
От: Richard Guo
Дата:
От: Demarest, Jamie
Дата: