Re: pg_dump getBlobs query broken for 7.3 servers
От | Tom Lane |
---|---|
Тема | Re: pg_dump getBlobs query broken for 7.3 servers |
Дата | |
Msg-id | 16360.1475862538@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_dump getBlobs query broken for 7.3 servers (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: pg_dump getBlobs query broken for 7.3 servers
Re: pg_dump getBlobs query broken for 7.3 servers |
Список | pgsql-hackers |
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > Stephen Frost wrote: >> I wasn't sure how far back it went, but if it's only to 9.1, then yes, >> farther than that. Specifically, to as far back as we wish to provide >> support for pg_dump, assuming it's reasonable to do so. > Do you really want to go back to applying patches back to 7.0? That's > brave. Branches before about 7.3 or 7.4 don't build cleanly on modern tools. In fact, they don't even build cleanly on my old HPUX 10.20 box ... I just tried, and they have problems with the bison and flex I have installed there now. As a data point, that bison executable bears a file date of Jan 31 2003. Andres reported something similar in the year-or-two-ago thread that was mentioned earlier. This doesn't even consider optional features; I wasn't trying to build SSL support for instance, but I'm pretty sure OpenSSL has been a moving target over that kind of time span. So I think trying to collect code coverage info on those branches is nuts. Maybe we could sanely do it for the later 8.x releases. Realistically though, how much would code coverage info have helped? Code coverage on a back branch would not have told you about whether it leaves blobs behind in the final regression DB state. Code coverage on HEAD might have helped you notice some aspects of this failure, but it would not have told you about the same query failing before 7.4 that worked later. regards, tom lane
В списке pgsql-hackers по дате отправления: