Re: [HACKERS] Re: [BUGS][PATCH] BUG #14486: Inserting and selecting interval have different constraints
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Re: [BUGS][PATCH] BUG #14486: Inserting and selecting interval have different constraints |
Дата | |
Msg-id | 15458.1483652374@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [BUGS][PATCH] BUG #14486: Inserting and selectinginterval have different constraints (Vitaly Burovoy <vitaly.burovoy@gmail.com>) |
Ответы |
Re: [HACKERS] Re: [BUGS][PATCH] BUG #14486: Inserting and selectinginterval have different constraints
|
Список | pgsql-bugs |
Vitaly Burovoy <vitaly.burovoy@gmail.com> writes: > On 1/5/17, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> My point is that ideally, any value that can physically fit into struct >> Interval ought to be considered valid. The fact that interval_out can't >> cope is a bug in interval_out, which ideally we would fix without >> artificially restricting the range of the datatype. > Am I correct that we are still limited by ECPG which is limited by the > system "tm" struct? I'm not really that concerned about whether ECPG can deal with enormous intervals. If it bothers you, and you want to go fix it, more power to you --- but I think fixing the backend is much higher priority. > Also users who use a binary protocol can also use the "tm" struct and > can not expect overflow. If they store an enormous interval value, its really up to them not to choke on it when they read it back. Not our problem. > The docs say[1] the highest value of the interval type is 178_000_000 > years which is ... irrelevant really. That's talking about the largest possible value of the "months" field, viz (2^31-1)/12. Perhaps we ought to document the other field limits, but right now there's nothing there about how large the hours field can get. regards, tom lane
В списке pgsql-bugs по дате отправления: