Re: replicating DROP commands across servers
От | Andres Freund |
---|---|
Тема | Re: replicating DROP commands across servers |
Дата | |
Msg-id | 20141224113409.GK23613@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: replicating DROP commands across servers (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: replicating DROP commands across servers
Re: replicating DROP commands across servers |
Список | pgsql-hackers |
On 2014-12-24 21:54:20 +1300, David Rowley wrote: > On 24 December 2014 at 07:41, Alvaro Herrera <alvherre@2ndquadrant.com> > wrote: > > > I have pushed patches 0001 through 0004, with some revisions. Only the > > final part is missing. > > > > > Hi Alvaro, > > Would you be able to commit the attached? It just fixes a new compiler > warning that I'm seeing on MSVC. > > src\backend\parser\parse_type.c(795): warning C4715: 'typeStringToTypeName' > : not all control paths return a value [D:\Postgres\a\postgres.vcxproj] Pushed. I really wonder if we can't make msvc reliably recognize this kind of scenario - especially this case is pretty trivial? Which of: #if defined(HAVE__BUILTIN_UNREACHABLE) && !defined(USE_ASSERT_CHECKING) #define pg_unreachable() __builtin_unreachable() #elif defined(_MSC_VER) && !defined(USE_ASSERT_CHECKING) #define pg_unreachable() __assume(0) #else #define pg_unreachable() abort() #endif does your build end up using? Does changing things around make it recognize this and similar cases? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: