Re: replicating DROP commands across servers - Mailing list pgsql-hackers

From Andres Freund
Subject Re: replicating DROP commands across servers
Date
Msg-id 20141224113409.GK23613@alap3.anarazel.de
Whole thread Raw
In response to Re: replicating DROP commands across servers  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: replicating DROP commands across servers  (David Rowley <dgrowley@gmail.com>)
Re: replicating DROP commands across servers  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Dilip kumar
Date:
Subject: Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]
Next
From: Fujii Masao
Date:
Subject: Re: [REVIEW] Re: Compression of full-page-writes