Re: [HACKERS] Parallel bitmap heap scan

On Fri, Jan 6, 2017 at 10:47 AM, Amit Khandekar wrote: > This looks good now. Thanks.. > > > Further points below Thanks for the review. > = nodeBItmapHeapscan.c == > > > In BitmapHeapNext(), the following code is relevant only for tbm > returned from

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On 1/5/17 12:04 AM, David Fetter wrote: +errmsg("UPDATE requires a WHERE clause when require_where.delete is set to on"), ISTM that message is no longer true. The second if could also be an else if too. -- Jim Nasby, Data Architect, Blue Treble

Re: [HACKERS] pg_hba_file_settings view patch

On Tue, Nov 29, 2016 at 9:15 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > Here's backtrace and some debugging information > Program terminated with signal 11, Segmentation fault. > #0 0x007f96cd in shm_mq_sendv (mqh=0x121e998, > iov=0x7ffc9b7b79f0, iovcnt=2, nowait=1

Re: [HACKERS] createdb warnings on OS X

On 1/8/17 6:03 PM, Tom Lane wrote: decibel@decina:[17:04]~/pgsql/HEAD (temp *$%)$uname -a Darwin decina.local 15.6.0 Darwin Kernel Version 15.6.0: Wed Nov 2 20:30:56 PDT 2016; root:xnu-3248.60.11.1.2~2/RELEASE_X86_64 x86_64 I can never remember how Darwin kernel versions map to OS X versions?

Re: [HACKERS] Increase pltcl test coverage

On 1/8/17 11:25 AM, Tom Lane wrote: But I don't understand how you got the sample output shown in the patch. Is this based on some unsubmitted changes in pltcl's error handling? AFAICT you've got everything. What I had on my end is: create function public.tcl_error_handling_test(text)

Re: [HACKERS] RustgreSQL

On 1/8/17 5:56 PM, Greg Stark wrote: On 8 January 2017 at 21:50, Jim Nasby wrote: Somewhat related to that... it would be useful if Postgres had "fenced" functions; functions that ran in a separate process and only talked to a backend via a well defined API (such as

Re: [HACKERS] merging some features from plpgsql2 project

On 1/8/17 12:03 AM, Pavel Stehule wrote: BTW, I do wish you could change the label of the scope that arguments went into, so that you could use that label to refer to function parameters. If we allowed that it'd perhaps be the best of both worlds: you'd be

Re: [HACKERS] createdb warnings on OS X

Jim Nasby writes: > I'm seeing the following warnings on a recent checkout. make check still > passes fine though... There's something screwy about your readline installation (or, if you didn't install GNU readline, about the libedit that OS X supplies). This is kind

Re: [HACKERS] RustgreSQL

On Monday, January 9, 2017 7:06:21 AM EST Craig Ringer wrote: > On 9 Jan. 2017 05:51, "Jan de Visser" wrote: > > On Sunday, January 8, 2017 6:28:17 AM EST Joel Jacobson wrote: > > I don't want to learn the complicated details of C, that's true. > > And this is where I think

Re: [HACKERS] RustgreSQL

On 8 January 2017 at 21:50, Jim Nasby wrote: > Somewhat related to that... it would be useful if Postgres had "fenced" > functions; functions that ran in a separate process and only talked to a > backend via a well defined API (such as libpq). There's two major

Re: [HACKERS] RustgreSQL

On 01/08/2017 09:19 AM, Craig Ringer wrote: On 8 Jan. 2017 17:10, "Joel Jacobson" > wrote: Is this completely unrealistic or is it carved in stone PostgreSQL will always be a C project forever and ever? Incredibly unrealistic. [lots of

Re: [HACKERS] merging some features from plpgsql2 project

On 1/7/17 11:44 PM, Pavel Stehule wrote: This is not overloading of SQL command - it is like annotations. It is smart idea, so I was not surprised if ANSI/SQL reuses it. SHas ANSI declared that they will NEVER support := in a SELECT that's not running in a stored function? Because if they

Re: [HACKERS] merging some features from plpgsql2 project

On 1/8/17 2:52 AM, Joel Jacobson wrote: And please kill all these GUCs ideas. The best thing with PostgreSQL is the natural expected behaviour of the default configuration. Contrary to MySQL where you have to enable lots and lots of configuration options just to get a behaviour you expect as a

Re: [HACKERS] RustgreSQL

On 1/8/17 5:06 PM, Craig Ringer wrote: It is very hard to write C that is generally portable, robust in the face of various edge-case inputs and environmental conditions, are free from race conditions and memory ordering problems, and rely on no undefined behaviour. BTW, if you s/memory/set/

[HACKERS] createdb warnings on OS X

I'm seeing the following warnings on a recent checkout. make check still passes fine though... ccache clang -Qunused-arguments -fcolor-diagnostics -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security

Re: [HACKERS] RustgreSQL

On 9 Jan. 2017 05:51, "Jan de Visser" wrote: On Sunday, January 8, 2017 6:28:17 AM EST Joel Jacobson wrote: > I don't want to learn the complicated details of C, that's true. And this is where I think you're wrong, and why conversion would be hard. C has very few complicated

Re: [HACKERS] RustgreSQL

On 09/01/17 11:31, Michael Paquier wrote: On Mon, Jan 9, 2017 at 6:51 AM, Jan de Visser wrote: Your fear of C in unfounded. The definitive c89 reference is a little book of about 250 pages, more than half of which is about the standard library of which you'll never use more

Re: [HACKERS] RustgreSQL

On Sun, Jan 8, 2017 at 1:51 PM, Jan de Visser wrote: > And this is where I think you're wrong, and why conversion would be hard. C > has very few complicated details. I don't think it has any, frankly. It > basically says "If you want your datastructure to outlive a function

Re: [HACKERS] RustgreSQL

On Mon, Jan 9, 2017 at 6:51 AM, Jan de Visser wrote: > Your fear of C in unfounded. The definitive c89 reference is a little book of > about 250 pages, more than half of which is about the standard library of > which you'll never use more than half. If you have some notepaper

Re: [HACKERS] RustgreSQL

On Sunday, January 8, 2017 6:28:17 AM EST Joel Jacobson wrote: > I don't want to learn the complicated details of C, that's true. And this is where I think you're wrong, and why conversion would be hard. C has very few complicated details. I don't think it has any, frankly. It basically says

Re: [HACKERS] RustgreSQL

On 1/8/17 10:28 AM, Joel Jacobson wrote: You'd have a lot more chance writing extensions in Rust though. If you can make it play OK with the exception handling in postgres and our memory management, at least. If you really wanted to push this forward... start there. Show how great it is.

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

On 1/7/17 11:14 PM, Ryan Murphy wrote: So I realized that I've never actually done `make world` before, and when I try that I get a funny error: make -C doc all make -C src all make -C sgml all ... *** ERROR: `osx' is missing on your system. ... Do you have any idea what that means? I

Re: [HACKERS] sequence data type

On 12/31/2016 01:27 AM, Peter Eisentraut wrote: Another updated patch, with quite a bit of rebasing and some minor code polishing. Patch applies cleanly and the tests pass The feature seems to work as expected. I've tried this out and it behaves as expected and desired. I also tested the

Re: [HACKERS] PATCH: recursive json_populate_record()

Nikita Glukhov writes: > [ 0001_recursive_json_populate_record_v02.patch ] > [ 0002_assign_ndims_to_record_function_result_types_v02.patch ] I do not see the point of the second one of these, and it adds no test case showing why it would be needed. The example you

Re: [HACKERS] Explicit subtransactions for PL/Tcl

Victor Wagner writes: > I'm attaching the patch which implements subtransaction command for > PL/Tcl which does almost same as PL/Python plpy.subtransction context > manager object does: executes a block of Tcl code in the context of > subtransaction, rolls subtransaction back

Re: [HACKERS] Explicit subtransactions for PL/Tcl

On Sun, 8 Jan 2017 20:57:50 +0300 Victor Wagner wrote: > Collegues! > > Recently I've found out that PL/Python have very nice feature - > explicit subtransaction object, which allows to execute block of code > in the context of subtransaction. > [skip] > > I'm attaching

[HACKERS] Explicit subtransactions for PL/Tcl

Collegues! Recently I've found out that PL/Python have very nice feature - explicit subtransaction object, which allows to execute block of code in the context of subtransaction. I've quite surprised that other PL languages, shipped with PostgreSQL do not have such useful construction. If it

Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send

On 8 January 2017 at 17:26, Greg Stark wrote: > On 5 January 2017 at 19:01, Andres Freund wrote: >> That's a bit odd - shouldn't the OS network stack take care of this in >> both cases? I mean either is too big for TCP packets (including jumbo >> frames).

Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send

On 5 January 2017 at 19:01, Andres Freund wrote: > That's a bit odd - shouldn't the OS network stack take care of this in > both cases? I mean either is too big for TCP packets (including jumbo > frames). What type of OS and network is involved here? 2x may be plausible.

Re: [HACKERS] Increase pltcl test coverage

Jim Nasby writes: > On 1/6/17 2:17 PM, Tom Lane wrote: >> This is in a format that neither patch(1) nor "git apply" recognize. >> Please resubmit in a more usual format, diff -c or diff -u perhaps. > Odd, dunno what happened there. New patch attached. This applies, but

Re: [HACKERS] RustgreSQL

Thank you Craig for explaining the current C state of the project, very interesting to learn about. On Sun, Jan 8, 2017 at 4:19 AM, Craig Ringer wrote: > If a low pain seamless conversation/adaptation like that were possible I'd > have to wonder what Rust could

Re: [HACKERS] RustgreSQL

Is this completely unrealistic or is it carved in stone PostgreSQL will always be a C project forever and ever? Another thing to look at if you want to approach this as a serious, practical effort is the atomics, memory barrier, spinlock and lwlock code. I just don't see it happening.

Re: [HACKERS] RustgreSQL

On 8 Jan. 2017 18:14, "Fabien COELHO" wrote: Is this completely unrealistic or is it carved in stone PostgreSQL will >> always be a C project forever and ever? >> > > From my very limited understanding, PostgreSQL is more likely to be > converted to C++! > ISTM that

Re: [HACKERS] RustgreSQL

On 8 Jan. 2017 17:10, "Joel Jacobson" wrote: Is this completely unrealistic or is it carved in stone PostgreSQL will always be a C project forever and ever? Incredibly unrealistic. PostgreSQL makes heavy use of variable length arrays. longjmp() is critical to its error

Re: [HACKERS] RustgreSQL

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Joel Jacobson asked: > Is anyone working on porting PostgreSQL to Rust? No; extremely unlikely. > My motivation is primarily I don't want to learn all the > over-complicated details of C Well that's going to be a show-stopper right there.

Re: [HACKERS] RustgreSQL

Is this completely unrealistic or is it carved in stone PostgreSQL will always be a C project forever and ever? From my very limited understanding, PostgreSQL is more likely to be converted to C++! ISTM that currently pg is written C89. Personnaly I think that C99 (standard from 18 years

Re: [HACKERS] RustgreSQL

On 08/01/17 22:09, Joel Jacobson wrote: Hi all, Is anyone working on porting PostgreSQL to Rust? Corrode looks a bit limited for the task, but maybe it can be a start. It doesn't support goto or switch, but maybe the gotos patterns are not too complicated. My motivation is primarily I don't

Re: [HACKERS] [PATCH] Generic type subscription

> On 4 January 2017 at 18:06, Artur Zakirov wrote: > But I'm not convinced about how to distinguish ArrayRef node with new > SubscriptingRef node. I'm not sure I understood you correctly. You're talking about having two nodes `ArrayRef` and `SubscriptingRef` at the same

Re: [HACKERS] proposal: session server side variables (fwd)

Hello Bruce, Good. So we seem to agree that GUCS are transactional? Uh, I think it is a missing feature, i.e.: https://wiki.postgresql.org/wiki/Todo#Administration Have custom variables be transaction-safe

[HACKERS] RustgreSQL

Hi all, Is anyone working on porting PostgreSQL to Rust? Corrode looks a bit limited for the task, but maybe it can be a start. It doesn't support goto or switch, but maybe the gotos patterns are not too complicated. My motivation is primarily I don't want to learn all the over-complicated

Re: [HACKERS] merging some features from plpgsql2 project

On Sat, Jan 7, 2017 at 8:56 PM, Pavel Stehule wrote: > > Jim, Marko, Joel - is there a place, features where we can find a partial > agreement? If it is, then we can move our view there. I have decided I definitively want a new language, and I'm willing to pay for it.