Re: [HACKERS] Rewriting backup.sgml (patch attached)

Hello Joshua, My 0.02 €: Alright, per previous discussions I went through the backup.sgml page. I have gone thoroughly through: sql dump pg_dump pg_restore handling large databases I removed file based backups I strongly disagree: The section is interesting at least for the arguments tha

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Tue, May 19, 2015 at 10:43 PM, Petr Jelinek wrote: > I am of strong opinion that concat should be shallow by default. Again it's > how jquery works by default, it's how python's dict.update works and you can > find this behavior in other languages as well when dealing with nested > hashes. It's

Re: [HACKERS] Minor ON CONFLICT related fixes

On Tue, May 19, 2015 at 2:23 PM, Andres Freund wrote: > Pushed. I eyeballed the commit, and realized that I made a trivial error. New patch attached fixing that. Sorry for not getting this fix completely right first time around. Don't know how I missed it. -- Peter Geoghegan diff --git a/src/ba

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 20/05/15 01:38, Jim Nasby wrote: On 5/18/15 3:15 PM, Marko Tiikkaja wrote: On 2015-05-18 22:10, Josh Berkus wrote: On 05/18/2015 01:04 PM, Ryan Pedela wrote: In the context of splitting shallow and deep merge into two operators, I think + is better for shallow and || better for deep. The re

Re: [HACKERS] Change pg_cancel_*() to ignore current backend

On 5/19/15 9:19 PM, Fabrízio de Royes Mello wrote: We could add a second parameter to the current functions: allow_own_pid DEFAULT false. To me that seems better than an entirely separate set of functions. +1 to add a second parameter to current functions. Instead of allow_own_pid

Re: [HACKERS] CTE optimization fence on the todo list?

I need this feature a lot. Can anyone point me to a place in the code where I can hack together a quick-and-dirty, compatibility-breaking implementation? Thanks! On Sun, May 3, 2015 at 10:03 PM, Jim Nasby wrote: > On 5/3/15 11:59 AM, Andrew Dunstan wrote: > >> >> On 05/03/2015 11:49 AM, Tom La

[HACKERS] small typo

Hi, Attached is a small typo. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento diff --git a/contrib/pg_buffercache/pg_buffercache_pages.c b/contrib/pg_buffercache/pg_buffercache_pages.c index 98016

Re: [HACKERS] Back-branch update releases planned for next week

I wrote: > In view of the multixactid wraparound issues that have gotten fixed over > the last week or two, it's time to put out some minor releases. After > some discussion among core and the packagers list, we concluded that we > should do it next week (before the Memorial Day holiday). As per

Re: [HACKERS] Change pg_cancel_*() to ignore current backend

Em terça-feira, 19 de maio de 2015, Jim Nasby escreveu: > On 5/19/15 6:30 PM, David G. Johnston wrote: > >> On Tue, May 19, 2015 at 4:23 PM, Marko Tiikkaja > >wrote: >> >> On 2015-05-20 00:59, Jim Nasby wrote: >> >> I find it annoying to have to specifically exclu

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

* Simon Riggs (si...@2ndquadrant.com) wrote: > On 19 May 2015 at 16:49, Robert Haas wrote: > > > On Tue, May 19, 2015 at 3:00 PM, Simon Riggs > > wrote: > > > As long as the cookie is randomly generated for each use, then I don't > > see a > > > practical problem with that approach. > > > > If t

Re: [HACKERS] upper planner path-ification

At Tue, 19 May 2015 09:04:00 -0400, Robert Haas wrote in > On Tue, May 19, 2015 at 7:19 AM, Andrew Gierth > wrote: > >> "Tom" == Tom Lane writes: > > Tom> Hm. That's a hangover from when query_planner also gave back a > > Tom> Plan (singular) rather than a set of Paths. I don't see any

Re: [HACKERS] Change pg_cancel_*() to ignore current backend

On 5/19/15 6:30 PM, David G. Johnston wrote: On Tue, May 19, 2015 at 4:23 PM, Marko Tiikkaja mailto:ma...@joh.to>>wrote: On 2015-05-20 00:59, Jim Nasby wrote: I find it annoying to have to specifically exclude pg_backend_pid() from pg_stat_activity if I'm trying to k

Re: [HACKERS] INSERT ... ON CONFLICT DO UPDATE with _any_ constraint

On Tue, May 19, 2015 at 5:03 PM, Tom Lane wrote: > Peter Geoghegan writes: >> I think I agree with you, though: We should change things so that the >> relcache gives indexes in something like the ordering that you >> outline, rather than in the current arbitrary (though consistent) OID >> order.

Re: [HACKERS] INSERT ... ON CONFLICT DO UPDATE with _any_ constraint

Peter Geoghegan writes: > I think I agree with you, though: We should change things so that the > relcache gives indexes in something like the ordering that you > outline, rather than in the current arbitrary (though consistent) OID > order. I'm fairly sure that there are aspects of the code that

Re: [HACKERS] INSERT ... ON CONFLICT DO UPDATE with _any_ constraint

On Tue, May 19, 2015 at 2:28 PM, Simon Riggs wrote: > On 19 May 2015 at 17:10, Peter Geoghegan wrote: >> >> On Tue, May 19, 2015 at 1:57 PM, Simon Riggs >> wrote: >> > We should allow DO UPDATE to exclude a constraint and apply a >> > deterministic >> > order to the constraints. 1. PK if it exis

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 5/18/15 3:15 PM, Marko Tiikkaja wrote: On 2015-05-18 22:10, Josh Berkus wrote: On 05/18/2015 01:04 PM, Ryan Pedela wrote: In the context of splitting shallow and deep merge into two operators, I think + is better for shallow and || better for deep. The reason for + is because many programmin

Re: [HACKERS] Change pg_cancel_*() to ignore current backend

On Tue, May 19, 2015 at 4:23 PM, Marko Tiikkaja wrote: > On 2015-05-20 00:59, Jim Nasby wrote: > >> I find it annoying to have to specifically exclude pg_backend_pid() from >> pg_stat_activity if I'm trying to kill a bunch of backends at once, and >> I can't think of any reason why you'd ever wan

Re: [HACKERS] Change pg_cancel_*() to ignore current backend

On 2015-05-20 00:59, Jim Nasby wrote: I find it annoying to have to specifically exclude pg_backend_pid() from pg_stat_activity if I'm trying to kill a bunch of backends at once, and I can't think of any reason why you'd ever want to call a pg_cancel_* function with your own PID. That's a rathe

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

On May 19, 2015 09:31:32 PM Greg Sabino Mullane wrote: > Jan de Visser wrote: > >> Well, one could argue that it *is* their problem, as they should be using > >> the standard Postgres way for placeholders, which is $1, $2, $3... > > > > Shirley you are joking: Many products use JDBC as an abstract

Re: [HACKERS] Making the regression tests halt to attach a debugger

On 5/18/15 12:15 PM, Andrew Dunstan wrote: On 05/18/2015 01:05 PM, Tom Lane wrote: Meh. You could also add "select pg_backend_pid()" or some such. But really, the way I generally do this is to run gdb via a script that auto-attaches to the right postgres process if at all possible. Removes the

Re: [HACKERS] Bug in jsonb minus operator

On 05/18/2015 10:52 PM, Peter Geoghegan wrote: On Mon, May 18, 2015 at 7:11 AM, Andrew Dunstan wrote: Here's an patch along those lines. It seems to do the trick, at least for your test case, and it has the merit of being very small, so small I'd like to backpatch it - accepting jbvBinary as i

[HACKERS] Change pg_cancel_*() to ignore current backend

I find it annoying to have to specifically exclude pg_backend_pid() from pg_stat_activity if I'm trying to kill a bunch of backends at once, and I can't think of any reason why you'd ever want to call a pg_cancel_* function with your own PID. Any objections to modifying those functions so they

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

On Tue, May 19, 2015 at 2:34 PM, Bruno Harbulot wrote: > > While I can imagine a Java PostgreSQL driver that would use the libpq > syntax, I can't see it being able to have any useful sort of > half-compatibility with JDBC, whether it mimics its interfaces or not. I'm > not sure it would be very

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

On Tue, May 19, 2015 at 9:50 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > On Tue, May 19, 2015 at 1:36 PM, Kevin Grittner wrote: > > Gavin Flower wrote: >> >> > I prefer the $1 approach, others can't use that, and there are >> > situations where I could not either. >> > >> > So,

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Jan de Visser wrote: >> Well, one could argue that it *is* their problem, as they should be using >> the standard Postgres way for placeholders, which is $1, $2, $3... > Shirley you are joking: Many products use JDBC as an abstraction layer >

[HACKERS] Rewriting backup.sgml (patch attached)

Hello, Alright, per previous discussions I went through the backup.sgml page. I have gone thoroughly through: sql dump pg_dump pg_restore handling large databases I removed file based backups I didn't really touch the red headed step child that is pg_dumpall (although a word smithed it a li

Re: [HACKERS] INSERT ... ON CONFLICT DO UPDATE with _any_ constraint

On 19 May 2015 at 17:10, Peter Geoghegan wrote: > On Tue, May 19, 2015 at 1:57 PM, Simon Riggs > wrote: > > We should allow DO UPDATE to exclude a constraint and apply a > deterministic > > order to the constraints. 1. PK if it exists. 2. Replica Identity, when > not > > PK, 3. UNIQUE constraint

Re: [HACKERS] Minor ON CONFLICT related fixes

On 2015-05-18 19:09:27 -0700, Peter Geoghegan wrote: > On Mon, May 18, 2015 at 2:09 PM, Peter Geoghegan wrote: > > You pointed out that the reason for this trivial bug on Jabber, but > > here's the obvious fix, including an EXPLAIN regression test. > > Also, I attach a patch adding ruleutils.c de

Re: [HACKERS] INSERT ... ON CONFLICT DO UPDATE with _any_ constraint

On Tue, May 19, 2015 at 1:57 PM, Simon Riggs wrote: > We should allow DO UPDATE to exclude a constraint and apply a deterministic > order to the constraints. 1. PK if it exists. 2. Replica Identity, when not > PK, 3. UNIQUE constraints in name order, like triggers, so users can define > a default

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

On 19 May 2015 at 16:49, Robert Haas wrote: > On Tue, May 19, 2015 at 3:00 PM, Simon Riggs > wrote: > > As long as the cookie is randomly generated for each use, then I don't > see a > > practical problem with that approach. > > If the client sets the cookie via an SQL command, that command woul

Re: [HACKERS] INSERT ... ON CONFLICT DO UPDATE with _any_ constraint

On 19 May 2015 at 16:36, Geoff Winkless wrote: > On 19 May 2015 at 21:12, Peter Geoghegan wrote: > >> It's trivial to modify Postgres to not require that a specific unique >> index be inferred, so that you can omit the inference specification >> for DO UPDATE just as you can for DO NOTHING. That

Re: [HACKERS] a few thoughts on the schedule

On Tue, May 19, 2015 at 1:35 PM, Andres Freund wrote: >> The vary earliest time frame that would make sense to me is to branch >> July 1st and start a CF on July 15th. > > I'm wondering why the CF has to start after branching? Or is that just > two independent dates? The first week or so of the fi

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

On 19 May 2015 at 16:36, Kevin Grittner wrote: > Gavin Flower wrote: > > > I prefer the $1 approach, others can't use that, and there are > > situations where I could not either. > > > > So, how about defaulting to the '?' approach, but have a method > > to explicitly set the mode - to switch to

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

On Tue, May 19, 2015 at 1:36 PM, Kevin Grittner wrote: > Gavin Flower wrote: > > > I prefer the $1 approach, others can't use that, and there are > > situations where I could not either. > > > > So, how about defaulting to the '?' approach, but have a method > > to explicitly set the mode - to s

Re: [HACKERS] INSERT ... ON CONFLICT DO UPDATE with _any_ constraint

On Tue, May 19, 2015 at 1:36 PM, Geoff Winkless wrote: > On 19 May 2015 at 21:12, Peter Geoghegan wrote: >> >> It's trivial to modify Postgres to not require that a specific unique >> index be inferred, so that you can omit the inference specification >> for DO UPDATE just as you can for DO NOTHI

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

On Tue, May 19, 2015 at 3:00 PM, Simon Riggs wrote: > As long as the cookie is randomly generated for each use, then I don't see a > practical problem with that approach. If the client sets the cookie via an SQL command, that command would be written to the log, and displayed in pg_stat_activity.

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

On Tue, May 19, 2015 at 2:46 PM, Andres Freund wrote: > On 2015-05-19 14:41:06 -0400, Robert Haas wrote: >> On Tue, May 19, 2015 at 12:29 PM, Andres Freund wrote: >> > On 2015-05-19 10:53:10 -0400, Robert Haas wrote: >> >> That seems like a kludge to me. If the cookie leaks out somhow, which >>

Re: [HACKERS] INSERT ... ON CONFLICT DO UPDATE with _any_ constraint

On 19 May 2015 at 21:12, Peter Geoghegan wrote: > It's trivial to modify Postgres to not require that a specific unique > index be inferred, so that you can omit the inference specification > for DO UPDATE just as you can for DO NOTHING. That would make it work > in a similar way to MySQL; whatev

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

Gavin Flower wrote: > I prefer the $1 approach, others can't use that, and there are > situations where I could not either. > > So, how about defaulting to the '?' approach, but have a method > to explicitly set the mode - to switch to using '$'? Are you suggesting that we implement something ot

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

On 05/19/2015 09:00 PM, Simon Riggs wrote: [snip] I think the idea of having SET SESSION AUTH pass a cookie, and only let RESET SESSION AUTH work when the same cookie is supplied, is pretty reasonable. As long as the cookie is randomly generated for each use, then I don't see

Re: [HACKERS] Per row status during INSERT .. ON CONFLICT UPDATE?

On Tue, May 19, 2015 at 1:20 PM, Peter Geoghegan wrote: > On Tue, May 19, 2015 at 1:07 PM, Robins Tharakan wrote: >> My use-case is to create an extra row for all UPDATEd rows (only), which is >> implemented in MSSQL by enveloping the MERGE with an INSERT (MERGE ... >> OUTPUT $action) WHERE $acti

Re: [HACKERS] Per row status during INSERT .. ON CONFLICT UPDATE?

On Tue, May 19, 2015 at 1:07 PM, Robins Tharakan wrote: > My use-case is to create an extra row for all UPDATEd rows (only), which is > implemented in MSSQL by enveloping the MERGE with an INSERT (MERGE ... > OUTPUT $action) WHERE $action = 'UPDATE'. That could make sense. You can achieve somethi

Re: [HACKERS] INSERT ... ON CONFLICT DO UPDATE with _any_ constraint

On Tue, May 19, 2015 at 12:57 PM, Geoff Winkless wrote: > Well http://www.postgresql.org/docs/devel/static/sql-insert.html explains > that a conflict_target clause is required but doesn't explain why. Yes, for ON CONFLICT DO UPDATE, it is mandatory. > It _does_ make clear that multiple UPDATEs t

Re: [HACKERS] Per row status during INSERT .. ON CONFLICT UPDATE?

On 19 May 2015 at 23:24, Peter Geoghegan wrote: > That's certainly something we talked about. It could probably be done > with some kind of magical expression. I have to wonder how many of the > people that are sure that they need this really do, though. Is it > really natural to care about this

Re: [HACKERS] INSERT ... ON CONFLICT DO UPDATE with _any_ constraint

On 19 May 2015 at 20:11, Simon Riggs wrote: > I'm sure we'll be asked these questions many times. > > Can you comment on whether the docs are sufficiently detailed to explain > this answer? > ​ Well http://www.postgresql.org/docs/devel/static/sql-insert.html explains that a conflict_target clause

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

On 20/05/15 07:37, Jan de Visser wrote: On May 19, 2015 07:04:56 PM Greg Sabino Mullane wrote: Bruno Harbulot asked for a devil's advocate by saying: My main point was that this is not specific to JDBC. Considering that even PostgreSQL's own ECPG is affected, the issue goes probably deeper than

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

On May 19, 2015 07:04:56 PM Greg Sabino Mullane wrote: > Bruno Harbulot asked for a devil's advocate by saying: > > My main point was that this is not specific to JDBC. Considering that even > > PostgreSQL's own ECPG is affected, the issue goes probably deeper than it > > seems. I'm just not convin

Re: [HACKERS] a few thoughts on the schedule

On 18 May 2015 at 23:34, Robert Haas wrote: > On May 18, 2015, at 10:41 PM, Andres Freund wrote: > >> On 2015-05-19 11:34:49 +0900, Michael Paquier wrote: > >> +1 for moving it at least 1 month. > > > > 2015-06-15 also collides with pgcon, which probably isn't the best > > idea. I do think we sh

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

On Tue, May 19, 2015 at 8:04 PM, Greg Sabino Mullane wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: RIPEMD160 > > Bruno Harbulot asked for a devil's advocate by saying: > > My main point was that this is not specific to JDBC. Considering that > even > > PostgreSQL's own ECPG is affected, t

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

On 19/05/15 20:46, Andres Freund wrote: On 2015-05-19 14:41:06 -0400, Robert Haas wrote: On Tue, May 19, 2015 at 12:29 PM, Andres Freund wrote: On 2015-05-19 10:53:10 -0400, Robert Haas wrote: That seems like a kludge to me. If the cookie leaks out somhow, which it will, then it'll be insecu

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > I did find some alternatives discussed a couple of years back, like > {postgres qm} and ; the later simply being to allow the > operator to be quoted inside "operator()" Yes, we (DBD::Pg) looked at using at some of the JDBC-ish alternatives

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

On 19 May 2015 at 15:02, Tom Lane wrote: > "Greg Sabino Mullane" writes: > > Dave Cramer opined: > >> It would seem that choosing ? for operators was ill advised; I'm not > >> convinced that deprecating them is a bad idea. If we start now, in 5 > years > >> they should be all but gone > > > Ha h

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

On Tue, May 19, 2015 at 7:51 PM, Greg Sabino Mullane wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: RIPEMD160 > > > Dave Cramer opined: > > It would seem that choosing ? for operators was ill advised; I'm not > > convinced that deprecating them is a bad idea. If we start now, in 5 > years

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

On 05/19/2015 02:22 PM, Tom Lane wrote: Mike Blackwell writes: See for example http://docs.oracle.com/cd/B19306_01/text.102/b14218/cqoper.htm#i997330, Table 3-1, third row, showing the precedence of '?'. Further down the page, under "Fuzzy" see "Backward Compatibility Syntax". If I'm reading

Re: [HACKERS] INSERT ... ON CONFLICT DO UPDATE with _any_ constraint

On 19 May 2015 at 11:49, Geoff Winkless wrote: > On 19 May 2015 at 16:32, I wrote: > >> In the event that the INSERT triggers a constraint that the UPDATE fails >> to resolve, it will still fail in exactly the same way that running the ON >> CONFLICT on a specific constraint would fail, so it's n

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Bruno Harbulot asked for a devil's advocate by saying: > My main point was that this is not specific to JDBC. Considering that even > PostgreSQL's own ECPG is affected, the issue goes probably deeper than it > seems. I'm just not convinced that p

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

"Greg Sabino Mullane" writes: > Dave Cramer opined: >> It would seem that choosing ? for operators was ill advised; I'm not >> convinced that deprecating them is a bad idea. If we start now, in 5 years >> they should be all but gone > Ha ha ha ha ha! That's a good one. We still have clients on Po

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

On 18 May 2015 at 12:33, Alvaro Herrera wrote: > Bruce Momjian wrote: > > On Sun, May 17, 2015 at 09:31:47PM +0200, José Luis Tallón wrote: > > > On 05/17/2015 07:39 PM, Tom Lane wrote: > > > >=?windows-1252?Q?Jos=E9_Luis_Tall=F3n?= > writes: > > > >>On the other hand, ISTM that what we all inte

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

​Ah. I see. Thanks for the clarification.​ __ *Mike Blackwell | Technical Analyst, Distribution Services/Rollout Management | RR Donnelley* 1750 Wallace Ave | St Charles, IL 60174-3401 Office: 630.313.7818 mike.black

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Dave Cramer opined: > It would seem that choosing ? for operators was ill advised; I'm not > convinced that deprecating them is a bad idea. If we start now, in 5 years > they should be all but gone Ha ha ha ha ha! That's a good one. We still ha

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

On 2015-05-19 14:41:06 -0400, Robert Haas wrote: > On Tue, May 19, 2015 at 12:29 PM, Andres Freund wrote: > > On 2015-05-19 10:53:10 -0400, Robert Haas wrote: > >> That seems like a kludge to me. If the cookie leaks out somhow, which > >> it will, then it'll be insecure. I think the way to do th

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

On Tue, May 19, 2015 at 7:22 PM, Tom Lane wrote: > Mike Blackwell writes: > > See for example > > http://docs.oracle.com/cd/B19306_01/text.102/b14218/cqoper.htm#i997330, > > Table 3-1, third row, showing the precedence of '?'. Further down the > > page, under "Fuzzy" see "Backward Compatibility

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

On Tue, May 19, 2015 at 12:29 PM, Andres Freund wrote: > On 2015-05-19 10:53:10 -0400, Robert Haas wrote: >> That seems like a kludge to me. If the cookie leaks out somhow, which >> it will, then it'll be insecure. I think the way to do this is with a >> protocol extension that poolers can enabl

Re: [HACKERS] a few thoughts on the schedule

On 05/19/2015 11:02 AM, Peter Geoghegan wrote: Hasn't every talented reviewer gotten job offers shortly afterwards in the last few years? The ones that accept don't necessarily work that much in the community, but several seem to. And I think in the case of several people the reason they don't

Re: [HACKERS] a few thoughts on the schedule

On 05/19/2015 10:44 AM, Andres Freund wrote: I don't know what the solution is but I know I like the idea of a tree freeze except for bug fixes for at least 3 weeks but I would be jumping for joy if we froze the tree except for bug fixes for 6 or 12 weeks. We've done that for pretty much ever

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

Mike Blackwell writes: > See for example > http://docs.oracle.com/cd/B19306_01/text.102/b14218/cqoper.htm#i997330, > Table 3-1, third row, showing the precedence of '?'. Further down the > page, under "Fuzzy" see "Backward Compatibility Syntax". If I'm reading that right, that isn't a SQL-level

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

See for example http://docs.oracle.com/cd/B19306_01/text.102/b14218/cqoper.htm#i997330, Table 3-1, third row, showing the precedence of '?'. Further down the page, under "Fuzzy" see "Backward Compatibility Syntax". _

Re: [HACKERS] a few thoughts on the schedule

On Tue, May 19, 2015 at 10:35 AM, Andres Freund wrote: > I'm not sure. ISTM that a painfull couple hours every now and then are > much less bad than the continuous CF we had lately. I personally also > find it frustrating to go through the CF and see a good portion of > things that I never can see

Re: [HACKERS] Per row status during INSERT .. ON CONFLICT UPDATE?

On Tue, May 19, 2015 at 10:49 AM, Andres Freund wrote: >> The RETURNING clause just allows us to return columns, but am unable to >> find a way to know 'what' happened to a given row. > > There previously has been discussion about extending RETURNING to allow > to return the before/after row. But

Re: [HACKERS] Per row status during INSERT .. ON CONFLICT UPDATE?

On 2015-05-19 17:53:09 +0530, Robins Tharakan wrote: > Is there a way to know which rows were INSERTed and UPDATEd when doing a > INSERT ... ON CONFLICT UPDATE? Probably via pseudo column indicating INSERT > / UPDATE ? No, not really. > The RETURNING clause just allows us to return columns, but a

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

On Tue, May 19, 2015 at 6:15 PM, Mike Blackwell wrote: > A Google search suggests Oracle 9.x supports a unary '?' operator (fuzzy > match), so the use of '?' in an operator name is not without precedent. > > Interesting. Do you have any specific link? I'm probably not using the right Google searc

Re: [HACKERS] a few thoughts on the schedule

On 2015-05-19 09:43:54 -0700, Joshua D. Drake wrote: > > On 05/18/2015 08:52 PM, Andres Freund wrote: > > >Maybe we should forget them and just have monthly 'judgefests' where > >some poor sod summarizes the current state and direction, and we then > >collaboratively discuss whether we see things

Re: [HACKERS] a few thoughts on the schedule

On 2015-05-19 10:25:49 -0400, Robert Haas wrote: > On Mon, May 18, 2015 at 11:52 PM, Andres Freund wrote: > > I personally think the late close of the 9.4 cycle has alone thrings far > > enough off track that we can't fairly evaluate a 5 CF schedule. > > Oh, I agree with that. Ah, ok. > The var

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On 19 May 2015 at 13:15, Mike Blackwell wrote: > A Google search suggests Oracle 9.x supports a unary '?' operator (fuzzy > match), so the use of '?' in an operator name is not without precedent. > Interesting argument. There is

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

A Google search suggests Oracle 9.x supports a unary '?' operator (fuzzy match), so the use of '?' in an operator name is not without precedent. __ *Mike Blackwell | Technical Analyst, Distribution Services/Rollout Ma

Re: [HACKERS] a few thoughts on the schedule

On 05/18/2015 08:52 PM, Andres Freund wrote: Maybe we should forget them and just have monthly 'judgefests' where some poor sod summarizes the current state and direction, and we then collaboratively discuss whether we see things going anywhere and if not, what would need to happen that they do

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

On 2015-05-19 10:53:10 -0400, Robert Haas wrote: > That seems like a kludge to me. If the cookie leaks out somhow, which > it will, then it'll be insecure. I think the way to do this is with a > protocol extension that poolers can enable on request. Then they can > just refuse to forward any "re

Re: [HACKERS] errmsg() clobbers errno

John Gorman writes: > While debugging an extension I discovered that the errmsg() > function zeros out errno. So might a lot of other functions used in an ereport's arguments. > This is annoying because if the process of assembling a meaningful > error message happens to call errmsg() before cal

Re: [HACKERS] Wrong Assert in PageIndexMultiDelete?

On 05/19/2015 07:15 PM, Tom Lane wrote: Anastasia Lubennikova writes: I am trying to create new index access method. And I found strange Assert in PageIndexMultiDelete function. Assert

Re: [HACKERS] Wrong Assert in PageIndexMultiDelete?

Anastasia Lubennikova writes: > I am trying to create new index access method. > And I found strange Assert in PageIndexMultiDelete > function. > Assert > (nite

[HACKERS] errmsg() clobbers errno

Hi All While debugging an extension I discovered that the errmsg() function zeros out errno. This is annoying because if the process of assembling a meaningful error message happens to call errmsg() before calling strerror() we lose the strerror information. This is exactly the time when we want

Re: [HACKERS] INSERT ... ON CONFLICT DO UPDATE with _any_ constraint

On 19 May 2015 at 16:32, I wrote: > In the event that the INSERT triggers a constraint that the UPDATE fails > to resolve, it will still fail in exactly the same way that running the ON > CONFLICT on a specific constraint would fail, so it's not like you gain any > extra value from specifying the

[HACKERS] INSERT ... ON CONFLICT DO UPDATE with _any_ constraint

I finally got around to running some UPSERT tests on the development build, which is very exciting for me :) I'm not sure if I missed the point with this (probably...): I'm unclear on the reason why DO UPDATE requires explicitly specifying the constraint while DO NOTHING does not. If it's a featu

[HACKERS] Wrong Assert in PageIndexMultiDelete?

Hi, hackers! I am trying to create new index access method. And I found strange Assert in PageIndexMultiDelete function. Assert (nitems < MaxIndexTuplesPerPage

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

On Tue, May 19, 2015 at 3:23 PM, Kevin Grittner wrote: > David G. Johnston wrote: > > On Mon, May 18, 2015 at 3:31 PM, Bruno Harbulot < > br...@distributedmatter.net>wrote: > > >> In the discussion on the OpenJDK JDBC list two years ago > >> ( > http://mail.openjdk.java.net/pipermail/jdbc-spec-d

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

On Mon, May 18, 2015 at 12:33 PM, Alvaro Herrera wrote: > Bruce Momjian wrote: >> On Sun, May 17, 2015 at 09:31:47PM +0200, José Luis Tallón wrote: >> > On 05/17/2015 07:39 PM, Tom Lane wrote: >> > >=?windows-1252?Q?Jos=E9_Luis_Tall=F3n?= >> > >writes: >> > >>On the other hand, ISTM that what we

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

On 19 May 2015 at 10:23, Kevin Grittner wrote: > David G. Johnston wrote: > > On Mon, May 18, 2015 at 3:31 PM, Bruno Harbulot < > br...@distributedmatter.net>wrote: > > >> In the discussion on the OpenJDK JDBC list two years ago > >> ( > http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2

Re: [HACKERS] Run pgindent now?

Robert Haas writes: > On Mon, May 18, 2015 at 6:53 PM, Tom Lane wrote: >> Would it alleviate your concern any if we eased into this, like say only >> apply the back-branch pgindent run to 9.5 and later branches? Then at >> least I could foresee the end of that particular annoyance. > If we do t

Re: [HACKERS] a few thoughts on the schedule

On Mon, May 18, 2015 at 11:52 PM, Andres Freund wrote: >> > [first 9.6 CF around 2015-07-15] > >> Honestly, that seems awful soon. I would have thought maybe August 15th. > > Maybe we should just rename it to 9.6-1 for now? And then look how > things look around pgcon? I'd rather agree on a date

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

David G. Johnston wrote: > On Mon, May 18, 2015 at 3:31 PM, Bruno Harbulot > wrote: >> In the discussion on the OpenJDK JDBC list two years ago >> ( >> http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2013-February/50.html >> ), >> Lance Andersen said "There is nothing in the SQL s

Re: [HACKERS] Run pgindent now?

Andrew Dunstan writes: > Tom, if you want to get dromedary reporting on all branches, just > remove the "branches => [ 'HEAD' ]," from the config. dromedary is a pretty slow machine, so I'm going to pass on that unless there's a good reason to think it would find typedefs your machines don't. I

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

On 18 May 2015 at 18:49, David G. Johnston wrote: > On Mon, May 18, 2015 at 3:31 PM, Bruno Harbulot < > br...@distributedmatter.net> wrote: > >> On Sun, May 17, 2015 at 5:15 PM, Greg Sabino Mullane >> wrote: >> >> >>> >>> > In that case my vote is new operators. This has been a sore point for >>

Re: [HACKERS] Patch for bug #12845 (GB18030 encoding)

>> That's fine when not every code point is used, but it's different for >> GB18030 where almost all code points are used. Using a plain array >> saves space and saves a binary search. > > Well, it doesn't save any space: if we get rid of the additional linear > ranges in the lookup table, what rem

Re: [HACKERS] Run pgindent now?

On Mon, May 18, 2015 at 6:53 PM, Tom Lane wrote: >> I am personally not excited about that. I would rather leave the >> back-branches alone. > > It would be awfully nice though if we didn't have to deal with random > cross-branch indenting differences. I've lost, maybe not years off my > life, b

Re: [HACKERS] Per row status during INSERT .. ON CONFLICT UPDATE?

On 5/19/15 3:04 PM, Thom Brown wrote: If you want the delta, you'll have to resort to a CTE: e.g. # WITH newvals AS ( INSERT INTO test (name, age) VALUES ('James', 45) ON CONFLICT (name) DO UPDATE SET age = EXCLUDED.age RETURNING *) SELECT n.name, o.age as "old.age"

Re: [HACKERS] Run pgindent now?

On 05/18/2015 08:06 PM, Andrew Dunstan wrote: On 05/18/2015 07:04 PM, Bruce Momjian wrote: On Mon, May 18, 2015 at 06:53:00PM -0400, Tom Lane wrote: Robert Haas writes: On Mon, May 18, 2015 at 12:10 PM, Bruce Momjian wrote: There was talk last time of pgindent-ing head and all back branch

Re: [HACKERS] Per row status during INSERT .. ON CONFLICT UPDATE?

On 19 May 2015 at 13:23, Robins Tharakan wrote: > Hi, > > Is there a way to know which rows were INSERTed and UPDATEd when doing a > INSERT ... ON CONFLICT UPDATE? Probably via pseudo column indicating INSERT > / UPDATE ? > > The RETURNING clause just allows us to return columns, but am unable to

Re: [HACKERS] upper planner path-ification

On Tue, May 19, 2015 at 7:19 AM, Andrew Gierth wrote: >> "Tom" == Tom Lane writes: > Tom> Hm. That's a hangover from when query_planner also gave back a > Tom> Plan (singular) rather than a set of Paths. I don't see any > Tom> fundamental reason why we couldn't generalize it to be a list

Re: [HACKERS] Parallel Seq Scan

On Mon, May 11, 2015 at 3:00 AM, Robert Haas wrote: > > > I think it might be better to try to solve this problem in a more > localized way. Can we arrange for planstate->instrumentation to point > directory into the DSM, instead of copying the data over later? Yes, we can do that but I am not s

[HACKERS] Per row status during INSERT .. ON CONFLICT UPDATE?

Hi, Is there a way to know which rows were INSERTed and UPDATEd when doing a INSERT ... ON CONFLICT UPDATE? Probably via pseudo column indicating INSERT / UPDATE ? The RETURNING clause just allows us to return columns, but am unable to find a way to know 'what' happened to a given row. ​Any poin

  1   2   >