Re: [HACKERS] to_json(NULL) should to return JSON null instead NULL

2015-08-30 4:57 GMT+02:00 Andrew Dunstan : > > > On 08/29/2015 04:27 PM, Tom Lane wrote: > >> Jim Nasby writes: >> >>> On 8/29/15 12:29 PM, Pavel Stehule wrote: >>> what is correct from JSON perspective? All fields with NULL >>> ISTM that the whole purpose of to_json is to properly json

Re: [HACKERS] Minor code improvements to create_foreignscan_plan/ExecInitForeignScan

On 28 August 2015 at 22:20, Etsuro Fujita wrote: > On 2015/07/22 15:25, Etsuro Fujita wrote: > >> On 2015/07/10 21:59, David Rowley wrote: > > I just glanced at this and noticed that the method for determining if >>> there's any system columns could be made a bit nicer. >>> >> > /* Now, are any s

Re: [HACKERS] Information of pg_stat_ssl visible to all users

On Sun, Aug 30, 2015 at 5:27 AM, Bruce Momjian wrote: > I know I am coming in late here, but I know Heroku uses random user > names to allow a cluster to have per-user databases without showing > external user name details: > [...] > I can see them having problems with a user being able to see the

Re: [HACKERS] to_json(NULL) should to return JSON null instead NULL

On 08/29/2015 04:27 PM, Tom Lane wrote: Jim Nasby writes: On 8/29/15 12:29 PM, Pavel Stehule wrote: what is correct from JSON perspective? All fields with NULL ISTM that the whole purpose of to_json is to properly jsonify something, and the proper json form for "undefined" is 'null', is it

[HACKERS] Horizontal scalability/sharding

I have recently increased my public statements about the idea of adding horizontal scaling/sharding to Postgres. I wanted to share with hackers a timeline of how we got here, and where I think we are going in the short term: 2012-2013: As part of writing my scaling talk (http://momjian.us/main/pr

Re: [HACKERS] WIP: About CMake v2

On 8/28/15 10:14 AM, YUriy Zhuravlev wrote: Hello Hackers How would you react if I provided a patch which introduces a CMake build system? I would say, "Yay!". I had that on my todo list, but I won't mind if someone else does it. I've certainly "had it" with the current build system. ;-)

Re: [HACKERS] [PATCH] SQL function to report log message

Hi I am starting to work review of this patch 2015-07-13 9:54 GMT+02:00 dinesh kumar : > Hi All, > > Greetings for the day. > > Would like to discuss on below feature here. > > Feature: > Having an SQL function, to write messages to log destination. > > Justification: > As of now, we don

Re: [HACKERS] buffer README is out of date

On Sat, Aug 29, 2015 at 1:27 PM, Jim Nasby wrote: > On 8/29/15 2:21 PM, Jeff Janes wrote: > >> The buffer/README section on buffer clean up locks never got updated >> for the creation of Heap Only Tuples and their associated compaction >> logic. >> >> I've attached a patch to chan

Re: [HACKERS] to_json(NULL) should to return JSON null instead NULL

On Sat, Aug 29, 2015 at 4:27 PM, Tom Lane wrote: > Jim Nasby writes: > > On 8/29/15 12:29 PM, Pavel Stehule wrote: > >> what is correct from JSON perspective? All fields with NULL > > > ISTM that the whole purpose of to_json is to properly jsonify something, > > and the proper json form for "und

Re: [HACKERS] WIP: About CMake v2

Tom Lane wrote: > Andres Freund writes: > > On 2015-08-29 17:53:26 -0300, Alvaro Herrera wrote: > >> Therefore, either we will not find any portability problems, or fixing > >> upstream those we do find will not be terribly difficult. > > > Well, the difference to know is that we can't resolve th

Re: [HACKERS] WIP: About CMake v2

Andres Freund writes: > On 2015-08-29 17:53:26 -0300, Alvaro Herrera wrote: >> Therefore, either we will not find any portability problems, or fixing >> upstream those we do find will not be terribly difficult. > Well, the difference to know is that we can't resolve that relatively > quickly ours

Re: [HACKERS] WIP: About CMake v2

On 2015-08-29 17:53:26 -0300, Alvaro Herrera wrote: > Therefore, either we will not find any portability problems, or fixing > upstream those we do find will not be terribly difficult. Well, the difference to know is that we can't resolve that relatively quickly ourselves, but that it'd rather req

Re: [HACKERS] WIP: About CMake v2

YUriy Zhuravlev wrote: > On Friday 28 August 2015 13:51:30 you wrote: > > It's broadly interesting, but since it bakes in a build dependency on > > CMake, there is some risk that the dependencies become an insurmountable > > problem. > > > > (Does CMake run on a VAX 11/780?? :-)) > > http://publ

Re: [HACKERS] 9.4 broken on alpha

Christoph Berg writes: > It'd be nice if the patch could get applied to 9.4 and earlier. I've pushed that patch into 9.4. Barring somebody stepping forward with an offer of a buildfarm member and any other necessary developer support, I do not think there will be any further consideration of rev

Re: [HACKERS] to_json(NULL) should to return JSON null instead NULL

On 8/29/15 3:27 PM, Tom Lane wrote: Jim Nasby writes: On 8/29/15 12:29 PM, Pavel Stehule wrote: what is correct from JSON perspective? All fields with NULL ISTM that the whole purpose of to_json is to properly jsonify something, and the proper json form for "undefined" is 'null', is it not?

Re: [HACKERS] Information of pg_stat_ssl visible to all users

On Tue, Jul 7, 2015 at 12:57:58PM -0400, Tom Lane wrote: > Andres Freund writes: > > On 2015-07-07 12:03:36 -0400, Peter Eisentraut wrote: > >> I think the DN is analogous to the remote user name, which we don't > >> expose for any of the other authentication methods. > > > Huh? > > Peter's exa

Re: [HACKERS] buffer README is out of date

On 8/29/15 2:21 PM, Jeff Janes wrote: The buffer/README section on buffer clean up locks never got updated for the creation of Heap Only Tuples and their associated compaction logic. I've attached a patch to change the explanation. I'm sure someone can word it better than I

Re: [HACKERS] to_json(NULL) should to return JSON null instead NULL

Jim Nasby writes: > On 8/29/15 12:29 PM, Pavel Stehule wrote: >> what is correct from JSON perspective? All fields with NULL > ISTM that the whole purpose of to_json is to properly jsonify something, > and the proper json form for "undefined" is 'null', is it not? What's not entirely clear is w

Re: [HACKERS] to_json(NULL) should to return JSON null instead NULL

2015-08-29 22:06 GMT+02:00 Jim Nasby : > On 8/29/15 12:29 PM, Pavel Stehule wrote: > >> Note that all the to_json functions are strict. In this sense it's >> quite consistent. If we change it to being called on null input, >> what should we return if a null non-scalar is passed in? >>

Re: [HACKERS] to_json(NULL) should to return JSON null instead NULL

On 8/29/15 12:29 PM, Pavel Stehule wrote: Note that all the to_json functions are strict. In this sense it's quite consistent. If we change it to being called on null input, what should we return if a null non-scalar is passed in? what is correct from JSON perspective? All fields wi

Re: [HACKERS] Fwd: Core dump with nested CREATE TEMP TABLE

On 8/29/15 11:31 AM, Andres Freund wrote: Hi, On 2015-08-29 11:06:05 -0500, Jim Nasby wrote: Stack trace below. Relevant assert: What exact revision is this on? Either there's some aggressive inlining going on, or these lines don't entirely match up with HEAD. Oops, that was 9.4.1. Trace fr

Re: [HACKERS] buffer README is out of date

On Sat, Aug 29, 2015 at 11:45 AM, Jeff Janes wrote: > The buffer/README section on buffer clean up locks never got updated for > the creation of Heap Only Tuples and their associated compaction logic. > > I've attached a patch to change the explanation. I'm sure someone can > word it better than

[HACKERS] buffer README is out of date

The buffer/README section on buffer clean up locks never got updated for the creation of Heap Only Tuples and their associated compaction logic. I've attached a patch to change the explanation. I'm sure someone can word it better than I have. Cheers, Jeff

Re: [HACKERS] Pg_upgrade remote copy

On Fri, Aug 28, 2015 at 10:34:38PM -0700, AI Rumman wrote: > Hi, > > In pg_upgrade, how about adding a feature to copy data directory over network. > That is, we can run pg_upgrade from our new host, where old host will be a > remote machine. > We can add two parameters - oldhost and if it is used

Re: [HACKERS] On-demand running query plans using auto_explain and signals

2015-08-29 18:36 GMT+02:00 Andres Freund : > On 2015-08-29 18:27:59 +0200, Pavel Stehule wrote: > > 2015-08-29 18:25 GMT+02:00 Shulgin, Oleksandr < > oleksandr.shul...@zalando.de> > > > Good point. There's still hope to set a flag and process it later on. > > > Will have to check if it's possible

Re: [HACKERS] to_json(NULL) should to return JSON null instead NULL

2015-08-29 19:11 GMT+02:00 Andrew Dunstan : > > > On 08/29/2015 12:02 PM, Pavel Stehule wrote: > >> >> >> 2015-08-29 15:43 GMT+02:00 Shulgin, Oleksandr < >> oleksandr.shul...@zalando.de >: >> >> On Sat, Aug 29, 2015 at 3:39 PM, Tom Lane >

Re: [HACKERS] to_json(NULL) should to return JSON null instead NULL

On 08/29/2015 12:02 PM, Pavel Stehule wrote: 2015-08-29 15:43 GMT+02:00 Shulgin, Oleksandr mailto:oleksandr.shul...@zalando.de>>: On Sat, Aug 29, 2015 at 3:39 PM, Tom Lane mailto:t...@sss.pgh.pa.us>> wrote: Andrew Dunstan mailto:and...@dunslane.net>> writes: > On 08/29

Re: [HACKERS] WIP: About CMake v2

On Friday 28 August 2015 13:51:30 you wrote: > It's broadly interesting, but since it bakes in a build dependency on > CMake, there is some risk that the dependencies become an insurmountable > problem. > > (Does CMake run on a VAX 11/780?? :-)) http://public.kitware.com/Bug/view.php?id=13605 yo

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On 2015-08-29 18:27:59 +0200, Pavel Stehule wrote: > 2015-08-29 18:25 GMT+02:00 Shulgin, Oleksandr > > Good point. There's still hope to set a flag and process it later on. > > Will have to check if it's possible to stay in the scope of a loaded module > > though. > I had a workable prototype -

Re: [HACKERS] Fwd: Core dump with nested CREATE TEMP TABLE

Hi, On 2015-08-29 11:06:05 -0500, Jim Nasby wrote: > Stack trace below. Relevant assert: What exact revision is this on? Either there's some aggressive inlining going on, or these lines don't entirely match up with HEAD. That's compiled with optimization, isn't it? Could you compile with -O0? C

Re: [HACKERS] On-demand running query plans using auto_explain and signals

2015-08-29 18:25 GMT+02:00 Shulgin, Oleksandr : > On Sat, Aug 29, 2015 at 5:44 PM, Andres Freund wrote: > >> On 2015-08-29 17:33:22 +0200, Shulgin, Oleksandr wrote: >> > Probably using SIGUSR2 would be more appropriate, but I'm not sure if >> there >> > are other extensions out there that might

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Sat, Aug 29, 2015 at 5:44 PM, Andres Freund wrote: > On 2015-08-29 17:33:22 +0200, Shulgin, Oleksandr wrote: > > Probably using SIGUSR2 would be more appropriate, but I'm not sure if > there > > are other extensions out there that might be already using it for some > > other reason (well, I do

Re: [HACKERS] to_json(NULL) should to return JSON null instead NULL

On 8/29/15 11:02 AM, Pavel Stehule wrote: It is bug - and it should be fixed. I agree, so this change is too strong for fixing in minor version - but we can change it in unreleased major versions - 9.5 and master. +1 -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Ana

Re: [HACKERS] psql - better support pipe line

On 8/29/15 8:10 AM, Shulgin, Oleksandr wrote: The other issue is there's no way to capture \conninfo inside of psql and do something with it. If instead this was exposed as a variable, you could handle it in SQL if you wanted to. Yeah, I forgot about the variable proposal, that woul

Re: [HACKERS] Fwd: Core dump with nested CREATE TEMP TABLE

On 8/29/15 8:04 AM, Tom Lane wrote: Michael Paquier writes: Ah, OK, you meant this file... Yes I was able to receive it as well in your original email. I'll try to investigate further later, but Tom may beat me first. He usually does. Jim had indicated the bug wasn't reproducible on the stren

Re: [HACKERS] to_json(NULL) should to return JSON null instead NULL

2015-08-29 15:43 GMT+02:00 Shulgin, Oleksandr : > On Sat, Aug 29, 2015 at 3:39 PM, Tom Lane wrote: > >> Andrew Dunstan writes: >> > On 08/29/2015 08:47 AM, Shulgin, Oleksandr wrote: >> >> Given there were no loud complaints about this, the current behavior >> >> is appropriate for most users, t

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On 2015-08-29 17:33:22 +0200, Shulgin, Oleksandr wrote: > Probably using SIGUSR2 would be more appropriate, but I'm not sure if there > are other extensions out there that might be already using it for some > other reason (well, I do not know that for SIGUSR1 either). Looking at the > current stat

Re: [HACKERS] 9.4 broken on alpha

On 2015-08-29 08:32:29 -0700, David Fetter wrote: > and I could make a pretty good > case for the idea that we can relegate 32-bit platforms to the ash > heap of history, at least on the server side. Don't see the point, it doesn't cost us very much. > Then, there's the question of rotating media

[HACKERS] On-demand running query plans using auto_explain and signals

Hello, The other day I've rediscovered the exciting idea of using signals to dump a backend's currently executed query plan, which, it turns out, was already proposed by Pavel and Simon in these threads: http://www.postgresql.org/message-id/flat/cafj8pra-duzkmdtu52ciugb0p7tvri_b8ltjmjfwcnr1lpt...

Re: [HACKERS] 9.4 broken on alpha

On Wed, Aug 26, 2015 at 09:19:09PM -0400, Noah Misch wrote: > As it is, we've implicitly prepared to ship Alpha-supporting > PostgreSQL 9.4 until 2019, by which time the newest Alpha hardware > will be 15 years old. Computer museums would be our only audience > for continued support. I do have a

Re: [HACKERS] to_json(NULL) should to return JSON null instead NULL

On Sat, Aug 29, 2015 at 3:39 PM, Tom Lane wrote: > Andrew Dunstan writes: > > On 08/29/2015 08:47 AM, Shulgin, Oleksandr wrote: > >> Given there were no loud complaints about this, the current behavior > >> is appropriate for most users, the rest can still work around using > >> coalesce(to_json

Re: [HACKERS] to_json(NULL) should to return JSON null instead NULL

Andrew Dunstan writes: > On 08/29/2015 08:47 AM, Shulgin, Oleksandr wrote: >> Given there were no loud complaints about this, the current behavior >> is appropriate for most users, the rest can still work around using >> coalesce(to_json(...), json 'null'). > I don't think it's necessarily more

Re: [HACKERS] 9.4 broken on alpha

Re: Andrew Dunstan 2015-08-25 <55dc5f9e.60...@dunslane.net> > >gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement > >-Wendif-labels -Wmissing-format-attribute -Wformat-security > >-fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -g -O2 -Wformat > >-Werror=for

Re: [HACKERS] to_json(NULL) should to return JSON null instead NULL

On 08/29/2015 08:47 AM, Shulgin, Oleksandr wrote: On Sat, Aug 29, 2015 at 8:39 AM, Pavel Stehule mailto:pavel.steh...@gmail.com>> wrote: Hi currently JSON support NULL value - but we doesn't convert NULL to JSON correctly postgres=# select to_json(NULL::text) IS NULL; ┌─

Re: [HACKERS] Proposal: Implement failover on libpq connect level.

On Fri, Aug 28, 2015 at 6:10 PM, Teodor Sigaev wrote: > +1 for bringing the jdbc driver URI syntax into libpq, so that all >> interfaces >> can be optionally specified this way. This doesn't preclude the use of >> ipfailover, in fact it might be work well together. If you don't like it, >> don't

Re: [HACKERS] psql - better support pipe line

On Fri, Aug 28, 2015 at 9:52 PM, Jim Nasby wrote: > On 8/28/15 3:58 AM, Shulgin, Oleksandr wrote: > >> It occurs to me the most flexible thing that could be done here >> would be providing a libpq function that spits out JSON connection >> parameters and have psql turn that into a var

Re: [HACKERS] [BUGS] Compile fails on AIX 6.1

Noah Misch writes: > I tested a gcc 64-bit build. Consistent with your followup, "b .+12" doesn't > build, but "b $+12" builds and passes "make check". I am attaching the exact > diff I tested. > On GNU/Linux ppc, I get the same opcodes before and after the change. Thanks for checking! I have

Re: [HACKERS] Fwd: Core dump with nested CREATE TEMP TABLE

Michael Paquier writes: > Ah, OK, you meant this file... Yes I was able to receive it as well in your > original email. I'll try to investigate further later, but Tom may beat me > first. He usually does. Jim had indicated the bug wasn't reproducible on the strength of that info, so I was waiting

Re: [HACKERS] to_json(NULL) should to return JSON null instead NULL

On Sat, Aug 29, 2015 at 8:39 AM, Pavel Stehule wrote: > Hi > > currently JSON support NULL value - but we doesn't convert NULL to JSON > correctly > > postgres=# select to_json(NULL::text) IS NULL; > ┌──┐ > │ ?column? │ > ╞══╡ > │ t│ > └──┘ > (1 row) > > probably s