Re: Fix for FETCH FIRST syntax problems

On 20/05/18 01:41, Tom Lane wrote: > Vik Fearing writes: >> On 20/05/18 00:57, Tom Lane wrote: >> I'm +1 for backpatching it. It may be operating as designed by PeterE >> ten years ago, but it's not operating as designed by the SQL standard. > > By that argument,

Re: Fix for FETCH FIRST syntax problems

On 20/05/18 05:25, Andrew Gierth wrote: > +select_fetch_first_value: > + c_expr > { $$ = $1; } > + | '+' I_or_F_const > + { $$ = (Node *) makeSimpleA_Expr(AEXPR_OP,

Re: Fix for FETCH FIRST syntax problems

On Sat, May 19, 2018 at 4:41 PM, Tom Lane wrote: > It may be that this fix is simple and safe enough that the risk/reward > tradeoff favors back-patching, but I think you have to argue it as a > favorable tradeoff rather than just saying "this isn't per standard". > Consider:

Re: Fix for FETCH FIRST syntax problems

On Sun, May 20, 2018 at 01:39:27AM +0100, Andrew Gierth wrote: > > "Tom" == Tom Lane writes: > > >> I'm +1 for backpatching it. It may be operating as designed by > >> PeterE ten years ago, but it's not operating as designed by the SQL > >> standard. > > Tom> By that

Re: Fix for FETCH FIRST syntax problems

On Sun, May 20, 2018 at 1:13 PM, Peter Geoghegan wrote: > There have been > cases where we chose to not back-patch an unambiguous bug fix even > though it was clear that incorrect user-visible behavior remained. > ​The risk here is significantly reduced since the existing

Re: Fix for FETCH FIRST syntax problems

"David G. Johnston" writes: > ​The risk here is significantly reduced since the existing user-visible > behavior is an error which presumably no one is relying upon. Between that > and being able to conform to the standard syntax for a long-standing > feature I would

Re: Fix for FETCH FIRST syntax problems

Greetings, * Peter Geoghegan (p...@bowt.ie) wrote: > Whether or not Andrew's patch is formally classified as a bug fix is > subjective. I'm inclined to accept it as a bug fix, but I also think > that it shouldn't matter very much. The practical implication is that > I don't think it's completely

RE: [HACKERS] Transactions involving multiple postgres foreign servers

From: Masahiko Sawada [mailto:sawada.m...@gmail.com] > Regarding to API design, should we use 2PC for a distributed > transaction if both two or more 2PC-capable foreign servers and > 2PC-non-capable foreign server are involved with it? Or should we end > up with an error? the 2PC-non-capable

Re: [HACKERS] Replication status in logical replication

On Tue, Apr 10, 2018 at 11:11 PM, David Steele wrote: > On 4/10/18 6:14 AM, Masahiko Sawada wrote: >> On Fri, Mar 30, 2018 at 5:37 AM, Fujii Masao wrote: >>> On Wed, Jan 17, 2018 at 2:16 AM, Simon Riggs wrote: On 16 January

Add necessary package list to ldap TAP's README

Hi all, The kerberos test suite mentions the package list to use on a set of distributions, which is very useful. However we don't do the same for ldap. Something like the attached would be adapted then to help setting up a test environment? I have at hand only a Debian installation, and I

Allowing printf("%m") only where it actually works

For amusement's sake, I was playing around with NetBSD-current (9-to-be) today, and tried to compile Postgres on it. It works OK --- and I can even confirm that our new code for using ARM v8 CRC instructions works there --- but I got a boatload of compile warnings like this: latch.c:1180:4:

Re: Fix for FETCH FIRST syntax problems

> "Stephen" == Stephen Frost writes: Stephen> Just to be clear, based on what I saw on IRC, this Stephen> specifically came out of someone complaining that it didn't Stephen> work and caused difficulty for them. Specifically, as I said at the start, it's from bug

Re: Odd procedure resolution

On Sat, May 19, 2018 at 12:51 AM, Robert Haas wrote: > On Thu, May 17, 2018 at 4:10 PM, Peter Eisentraut > wrote: >> I think I have made a mistake here. I was reading in between the lines >> of a competitor's documentation that they have

Re: Allowing printf("%m") only where it actually works

On Mon, May 21, 2018 at 12:30 PM, Tom Lane wrote: > For amusement's sake, I was playing around with NetBSD-current (9-to-be) > today, and tried to compile Postgres on it. It works OK --- and I can > even confirm that our new code for using ARM v8 CRC instructions works

Re: Postgres, fsync, and OSs (specifically linux)

On Sat, May 19, 2018 at 6:31 AM, Stephen Frost wrote: > Greetings, > > * Abhijit Menon-Sen (a...@2ndquadrant.com) wrote: >> At 2018-05-18 20:27:57 -0400, sfr...@snowman.net wrote: >> > >> > I don't agree with the general notion that we can't have a function >> > which handles

Re: Allowing printf("%m") only where it actually works

Thomas Munro writes: > I tried this on macOS and FreeBSD using GCC and Clang: both accept > printf("%m") without warning and then just print out "m". It'll be > interesting to see if the NetBSD patch/idea travels further or some > other solution can be found. I've

Re: Allowing printf("%m") only where it actually works

... and, while we're thinking about this, how can we prevent the reverse problem of using strerror(errno) where you should have used %m? That is evidently not academic either, cf 81256cd. I am wondering whether the elog/ereport macros can locally define some version of "errno" that would cause a

Re: Postgres, fsync, and OSs (specifically linux)

On 18 May 2018 at 00:44, Andres Freund wrote: > Hi, > > On 2018-05-10 09:50:03 +0800, Craig Ringer wrote: > > while ((src = (RewriteMappingFile *) hash_seq_search(_status)) > != NULL) > > { > > if (FileSync(src->vfd, WAIT_EVENT_LOGICAL_REWRITE_SYNC)