Re: [HACKERS] Tackling JsonPath support

On Fri, Dec 2, 2016 at 1:32 PM, Nico Williams <n...@cryptonector.com> wrote: ... On Fri, Dec 02, 2016 at 08:53:33AM -0500, Robert Haas wrote: > > On Tue, Nov 29, 2016 at 11:50 AM, Christian Convey > > <christian.con...@gmail.com> wrote: > > > I think I can sati

Re: [HACKERS] Tackling JsonPath support

On Tue, Nov 29, 2016 at 8:18 AM, Petr Jelinek wrote: ... > Just to add to this, the SQL/JSON proposals I've seen so far, and what > Oracle, MSSQL and Teradata chose to implement already is basically > subset of jsonpath (some proposals/implementations also include >

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 10:37 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > > > 2016-11-29 7:34 GMT+01:00 Christian Convey <christian.con...@gmail.com>: > >> On Mon, Nov 28, 2016 at 9:28 PM, Pavel Stehule <pavel.steh...@gmail.com> >> wrote: &

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 9:28 PM, Pavel Stehule wrote: > We now support XPath function - JSONPath is similar to XPath - it is > better for user, because have to learn only one language. > I'm not sure I understand. Are you suggesting that we use XPath, not JSONPath, as

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 6:26 PM, Nico Williams <n...@cryptonector.com> wrote: > On Mon, Nov 28, 2016 at 05:50:40PM -0800, Christian Convey wrote: > > On Mon, Nov 28, 2016 at 11:23 AM, Nico Williams <n...@cryptonector.com> > > wrote: > > ... > > > JSON Pa

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 11:23 AM, Nico Williams wrote: ... > JSON Path is not expressive enough (last I looked) and can be mapped > onto jq if need be anyways. > ​Hi Nico, Could you please clarify what you mean by "not expressive enough"? I ask because I've been

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 9:47 AM, Pavel Stehule wrote > > > I thought by adding my first implementation to "contrib", we could make > this functionality available to end-users, even before there was a > consensus about what PG's "official" JSON-related operators should

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 9:40 AM, Pavel Stehule wrote: ​...​ > > ​Hi Pavel, > > > > Can you clarify what you meant? I *think* you're saying: > > > > * It's not important for me to match the syntax/semantics of the > json-path implementations found in MySQL / Oracle / DB2

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 5:20 AM, Pavel Stehule wrote: ... > Incremental work is great idea - I like this this style. Instead contrib, > you can use public repository on github. Minimally for first stage is > better to live outside core - you are not restricted by

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 5:20 AM, Pavel Stehule wrote: ​...​ > Con: "JSON path expression" is a recurring them in the *grammars* of >> user-facing operators in [1], [2], [3], and [4]. But it doesn't >> necessarily follow that the function implemented in Step 2 will

Re: [HACKERS] Tackling JsonPath support

>From looking at other databases' docs, it seems like the behavior of various JSON-related operators / functions are described partially in terms of a "json path expression": * In Oracle, "JSON_TABLE", "JSON_exists_column", "JSON_value_column": [1] * In MySQL: [2] * In DB2: [3] * In MS SQL

Re: [HACKERS] Tackling JsonPath support

f "JSON_VALUE", "JSON_EXISTS", etc. in terms of (a). Thanks, Christian [1] http://jtc1sc32.org/doc/N2501-2550/32N2528-WG3-Tutorial-Opening-Plenary.pdf [2] http://goessner.net/articles/JsonPath On Fri, Sep 16, 2016 at 2:28 AM, Pavel Stehule <pavel.steh...@gmail.com> wr

[HACKERS] Tackling JsonPath support

On Mon, Sep 5, 2016 at 1:44 PM, Pavel Stehule wrote: ... > I wrote XMLTABLE function, and I am thinking about JSON_TABLE function. But > there is one blocker - missing JsonPath support in our JSON implementation. > > So one idea - implement JsonPath support and related

Re: [HACKERS] [GENERAL] C++ port of Postgres

Some of your patches look useful, but unrelated to C++: 7, 8, 15, 16(?), 20. I applied that subset to 9.6 and got a clean "make check". Would it make sense to add them to the next commitfest, regardless of the C++ effort? On Wed, Aug 31, 2016 at 9:41 AM, Peter Eisentraut

Re: [HACKERS] [GENERAL] C++ port of Postgres

> P.S. I'm asking because I was planning to review that patch. But I >> can't tell if any more review by a non-committer is still required by >> the commitfest workflow. > > > I think this has gotten enough attention, for the commitfest workflow. The > workflow is flexible, depending on the

Re: [HACKERS] [GENERAL] C++ port of Postgres

t intentional? Thanks very much, Christian P.S. I'm asking because I was planning to review that patch. But I can't tell if any more review by a non-committer is still required by the commitfest workflow. Kind regards, Christian On Tue, Sep 6, 2016 at 3:15 PM, Christian Convey <christian.con...@

Re: [HACKERS] [GENERAL] C++ port of Postgres

> Thanks. It sounds like worst-case scenario, I perform an unneeded > review. I'll give it a shot. Hi guys, Apologies for more boring process-related questions, but any pointers would be greatly appreciated... I'm a bit confused about how PG's code-review process is meant to handle this C++

Re: [HACKERS] Suggestions for first contribution?

On Wed, Sep 7, 2016 at 10:44 AM, Stas Kelvich wrote: > There is also a list of projects for google summer of code: > https://wiki.postgresql.org/wiki/GSoC_2016 > > That topics expected to be doable by a newcomer during several months. It is > also slightly > outdated,

Re: [HACKERS] Suggestions for first contribution?

On Wed, Sep 7, 2016 at 10:34 AM, Yury Zhuravlev <u.zhurav...@postgrespro.ru> wrote: > Christian Convey wrote: >> >> Yury doesn't seem to need help >> with CMake > > Hello. > I am sorry that the only answer is now. > I need help but with write CMake code: &g

Re: [HACKERS] Suggestions for first contribution?

On Wed, Sep 7, 2016 at 10:14 AM, Aleksander Alekseev wrote: > Here is another idea for a contribution - refactoring. > > Currently there are a lot of procedures in PostgreSQL code that > definitely don't fit on one screen (i.e. ~50 lines). Also many files are > larger

Re: [HACKERS] [GENERAL] C++ port of Postgres

On Tue, Sep 6, 2016 at 3:12 PM, Tom Lane wrote: >> (2) It seems like there are still a few big questions about this commit: >>- Is it wanted at the moment? It didn't seem like there's a >> consensus about whether or not this enhancement should be >> merged, even

Re: [HACKERS] [GENERAL] C++ port of Postgres

On Wed, Aug 31, 2016 at 9:41 AM, Peter Eisentraut wrote: >> Joy, do you have an idea what a *minimally invasive* patch for C++ >> support would look like? That's certainly the first step here. > > I developed a minimally invasive patch for C++ support a few years

Re: [HACKERS] Suggestions for first contribution?

Thanks everyone for the suggestions. It sounds like the most useful thing I can do at the moment is perform code reviews. I assumed I'd need more experience with the PG code base, but I keep on reading that newcomers' reviews are welcome. Unless someone has a better idea, I'll start with that.

[HACKERS] Suggestions for first contribution?

Hi guys, Can anyone suggest a project for my first PG contribution? My first two ideas didn't pan out: Yury doesn't seem to need help with CMake, and the TODO list's "-Wcast-align" project (now deleted) appeared impractical. I can continue trying things from the TODO list, but if someone knows

Re: [HACKERS] Obsolete TODO item "-Wcast-align" ?

On Sun, Sep 4, 2016 at 5:56 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Christian Convey <christian.con...@gmail.com> writes: >> I chose this item from the TODO page: "[E] Remove warnings created by >> -Wcast-align". It didn't have a check-mark after th

[HACKERS] Obsolete TODO item "-Wcast-align" ?

/CALgh3eseTDT9RspDi0AfhE0j0A3e%2B5XiS3ykQyhK7Z5RgPQTLA%40mail.gmail.com#calgh3esetdt9rspdi0afhe0j0a3e+5xis3ykqyhk7z5rgpq...@mail.gmail.com I didn't find any other discussions about that line-item via Google, or by looking at the official/unofficial TODO-detail pages. Thanks very much, Christian Convey -- Sent

Re: [HACKERS] WIP: About CMake v2

Hi Yury, >> I glad to hear it. I suppose you can just try build postgres and send all >> problems to github tracker. >> https://github.com/stalkerg/postgres_cmake/issues FYI, I had success using your "postgres_cmake" repo. I tested it up through "make check" and "make install". Here are the

Re: [HACKERS] WIP: About CMake v2

Hi Yury, On Fri, Aug 19, 2016 at 9:46 AM, Yury Zhuravlev <u.zhurav...@postgrespro.ru> wrote: > Christian Convey wrote: >> >> I'm interested in helping with your CMake effort. I don't have any >> experience contributing to PG, but I do have some free time at the >

Re: [HACKERS] WIP: About CMake v2

Hi Stefan, >> I ask because I'm curious if/how someone in Yury's situation could >> predict which minimum version of CMake must be supported in order for >> his patch to be accepted. (And if he accepts my offer to pitch in, >> I'll actually need that particular detail.) > > well I personally

Re: [HACKERS] WIP: About CMake v2

> > I don't think we're interested in maintaining more build systems than we > already are. If cmake can replace the current MSVC tooling and > autoconf, all in one, my impression is that we're in. If we're > replacing two tools we've hammered pretty well over the years with two > tools that we

Re: [HACKERS] WIP: About CMake v2

Hi Tom, >> I ask because I'm curious if/how someone in Yury's situation could >> predict which minimum version of CMake must be supported in order for >> his patch to be accepted. (And if he accepts my offer to pitch in, >> I'll actually need that particular detail.) > > well I personally think

Re: [HACKERS] WIP: About CMake v2

Hi Stefan, >> Yury: Would it make sense to add a call to "cmake_minimum_required" in >> one or more of your CMakeLists.txt files? > > it would make sense nevertheless but I dont think that 2.8.11 is old > enough - looking at the release information and the feature compatibily > matrix it would

Re: [HACKERS] WIP: About CMake v2

Hi Tom, Thanks for that information. Is there some document I can read that explains which platform versions (e.g., OpenBSD 5.3) are considered strongly supported? I ask because I'm curious if/how someone in Yury's situation could predict which minimum version of CMake must be supported in

Re: [HACKERS] WIP: About CMake v2

quot; in one or more of your CMakeLists.txt files? Kind regards, Christian On Thu, Aug 18, 2016 at 3:08 PM, Stefan Kaltenbrunner <ste...@kaltenbrunner.cc> wrote: > On 08/18/2016 08:57 PM, Christian Convey wrote: >> Hi Stefan, >> >> I think I've seen similar errors when a

Re: [HACKERS] WIP: About CMake v2

Hi Stefan, I think I've seen similar errors when a project's CMake files assumed a newer version of CMake than the one being run. Which version of CMake gave you those errors? (Sorry if you provided that detail and I'm just missing it.) Kind regards, Christian On Thu, Aug 18, 2016 at 2:45 PM,

Re: [HACKERS] WIP: About CMake v2

is Mint 17.3 (i.e., Ubuntu 15.10), but I'd be happy to create additional VM's as needed. I'm also happy to look into bugs on other systems (VMS, etc.) if I can get SSH access. Kind regards, Christian Convey On Fri, Jul 1, 2016 at 5:26 AM, Dmitry Maslyuk <d.mas...@postgrespro.ru> wrote: >

Re: [HACKERS] Breaking compile-time dependency cycles of Postgres subdirs?

On Sun, Feb 9, 2014 at 8:06 PM, Robert Haas robertmh...@gmail.com wrote: On Fri, Feb 7, 2014 at 7:39 AM, Christian Convey christian.con...@gmail.com wrote: This question is mostly just curiosity... As someone very new to this code base, I think these cycles make it a little harder

Re: [HACKERS] Breaking compile-time dependency cycles of Postgres subdirs?

On Mon, Feb 10, 2014 at 10:28 AM, Tom Lane t...@sss.pgh.pa.us wrote: I think if it had been a clear, enforced goal all along, it might've been possible to build the system with such a restriction (for the most part at least). At this point though, the amount of work and code churn involved

[HACKERS] Breaking compile-time dependency cycles of Postgres subdirs?

This question is mostly just curiosity... There are build-time dependency cycles between some of Postgres' code subdirectories. For example, storage and access have such a cycle: storage/buffpage.h #includes access/xlogdefs.h access/visibilitymap.h #includes storage/block.h Has there been any

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

On Mon, Jan 27, 2014 at 7:14 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote: FDW's join pushing down is one of the valuable use-cases of this interface, but not all. As you might know, my motivation is to implement GPU acceleration feature on top of this interface, that offers alternative way

Re: [HACKERS] Changeset Extraction v7.3

It seems to me that the terms physical, logical, and binary are always relative to the perspective of the component being worked on. Physical often means one level of abstraction below mine, and upon which my work builds. Logical means my work's level of abstraction. And Binary means data which

Re: [HACKERS] alternative back-end block formats

On Tue, Jan 28, 2014 at 5:42 AM, Cédric Villemain ced...@2ndquadrant.comwrote: ... As written in the meeting notes, Tom Lane revealed an interest in pluggable storage. So it might be interesting to check that. https://wiki.postgresql.org/wiki/PgCon_2013_Developer_Meeting Thanks. I just

Re: [HACKERS] alternative back-end block formats

There are a couple of really huge issues that would have to be argued out before any progress could be made. Is this something that people want to spend time on right now? As I mentioned earlier, I'm game. But it doesn't sound like I'll get very far without adult supervision.

Re: [HACKERS] alternative back-end block formats

On Tue, Jan 28, 2014 at 12:39 PM, Tom Lane t...@sss.pgh.pa.us wrote: TBH, I'd rather we waited till the commitfest is over. This is certainly material for 9.5, if not even further out, so there's no pressing need for a debate right now; and we have plenty of stuff we do need to deal with

Re: [HACKERS] alternative back-end block formats

Hi Craig, On Sun, Jan 26, 2014 at 5:47 AM, Craig Ringer cr...@2ndquadrant.com wrote: On 01/21/2014 07:43 PM, Christian Convey wrote: Hi all, I'm playing around with Postgres, and I thought it might be fun to experiment with alternative formats for relation blocks, to see if I can get

[HACKERS] alternative back-end block formats

Hi all, I'm playing around with Postgres, and I thought it might be fun to experiment with alternative formats for relation blocks, to see if I can get smaller files and/or faster server performance. Does anyone know if this has been done before with Postgres? I would have assumed yes, but I'm

[HACKERS] Question about Lockhart's book

Hi guys, I'm starting to poke around the internals of Postgres. Does anyone know the extent to which Thomas Lockhart's book, PostgresSQL Programmer's Guide is accurate with respect to the current state of the code base? Thanks, Christian

Re: [HACKERS] Question about Lockhart's book

Dunstan and...@dunslane.netwrote: On 12/27/2013 10:55 AM, Christian Convey wrote: Hi guys, I'm starting to poke around the internals of Postgres. Does anyone know the extent to which Thomas Lockhart's book, PostgresSQL Programmer's Guide is accurate with respect to the current state

Re: [HACKERS] Question about Lockhart's book

Thanks very much Josh. Those sound like great ideas - I'll try to give them a shot. On Fri, Dec 27, 2013 at 1:52 PM, Josh Berkus j...@agliodbs.com wrote: On 12/27/2013 08:14 AM, Christian Convey wrote: Hi Andrew, Thanks for your response. Sometimes overall software architectures stay