Re: [HACKERS] building libpq.a static library

2017-07-12 Thread Jan de Visser
On Wednesday, July 12, 2017 6:31:09 AM EDT Jeroen Ooms wrote: > I maintain static libraries for libpq for the R programming language > (we need static linking to ship with the binary packages). > Unfortunately currently the standard postgres makefile only generates > a shared library for libpq,

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

2017-06-22 Thread Jan de Visser
On Thursday, June 22, 2017 12:32:14 PM EDT Kang Yuzhe wrote: > Here is a sample what I did after applying the patch. > > testdb=# BEGIN; > BEGIN > testdb=# > testdb=# MERGE INTO Stock USING Buy ON Stock.item_id = Buy.item_id > testdb-# WHEN MATCHED THEN UPDATE SET balance = balance + Buy.volume

Re: [HACKERS] my open items vs. my vacation

2017-04-12 Thread Jan de Visser
On Tuesday, April 11, 2017 1:36:44 PM EDT Robert Haas wrote: > I apologize for any disruption this may cause, but I'm hopeful that it > won't be too bad. Spoken like a true American - apologizing for taking vacation :-) Enjoy your time off. You probably deserved it, and more than the week you're

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

2017-03-20 Thread Jan de Visser
On Monday, March 20, 2017 3:30:49 PM EDT Robert Haas wrote: > On Sat, Mar 18, 2017 at 4:12 PM, Magnus Hagander wrote: > > createdb, dropdb - also not clear they're about postgres, more likely to > > be > > used by mistake but not that bad. That said, do they add any *value*

Re: [HACKERS] RustgreSQL

2017-01-10 Thread Jan de Visser
On Monday, January 9, 2017 7:39:49 PM EST Joel Jacobson wrote: > On Mon, Jan 9, 2017 at 6:03 PM, Craig Ringer wrote: > > Immutable functions can and do use functionality from all over the > > server. They just don't depend on user-visible mutable _state_ > > elsewhere in

Re: [HACKERS] RustgreSQL

2017-01-08 Thread Jan de Visser
On Monday, January 9, 2017 7:06:21 AM EST Craig Ringer wrote: > On 9 Jan. 2017 05:51, "Jan de Visser" <j...@de-visser.net> 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.

Re: [HACKERS] RustgreSQL

2017-01-08 Thread Jan de Visser
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] Do we need use more meaningful variables to replace 0 in catalog head files?

2016-11-10 Thread Jan de Visser
On 2016-11-09 10:47 AM, Tom Lane wrote: Amit Langote writes: On Wed, Nov 9, 2016 at 11:47 PM, Tom Lane wrote: Hmm, that's from 2009. I thought I remembered something much more recent, like last year or so. This perhaps: * Re: Bootstrap DATA is

Re: [HACKERS] Death by regexp_replace

2016-01-15 Thread Jan de Visser
On 2016-01-15 10:25 AM, Robert Haas wrote: On Fri, Jan 15, 2016 at 10:12 AM, Benedikt Grundmann wrote: Today we discovered that we had a backend whose client had gone away, the automatic query watching process had send both pg_cancel and pg_terminate_backend but

Re: [HACKERS] Idea: closing the loop for pg_ctl reload

2015-08-25 Thread Jan de Visser
On August 25, 2015 09:31:35 PM Michael Paquier wrote: On Thu, Jul 23, 2015 at 5:06 PM, Heikki Linnakangas wrote: Other comments: [...] This patch had feedback, but there has been no update in the last month, so I am now marking it as returned with feedback. It was suggested that this

Re: [HACKERS] Idea: closing the loop for pg_ctl reload

2015-08-25 Thread Jan de Visser
On August 25, 2015 08:36:52 PM Tom Lane wrote: Jan de Visser j...@de-visser.net writes: On August 25, 2015 09:31:35 PM Michael Paquier wrote: This patch had feedback, but there has been no update in the last month, so I am now marking it as returned with feedback. It was suggested

Re: [HACKERS] Idea: closing the loop for pg_ctl reload

2015-07-06 Thread Jan de Visser
On July 6, 2015 09:23:12 AM Stephen Frost wrote: I wonder whether we should consider inventing similar views for pg_hba.conf and pg_ident.conf. Yes. That's definitely something that I'd been hoping someone would work on. There actually is a patch in the current CF that provides a view

Re: [HACKERS] Idea: closing the loop for pg_ctl reload

2015-07-03 Thread Jan de Visser
On July 3, 2015 06:21:09 PM Tom Lane wrote: Jan de Visser j...@de-visser.net writes: Attached a new patch, rebased against the current head. Errors in pg_hba.conf and pg_ident.conf are now also noticed. I checked the documentation for pg_ctl reload, and the only place where it's

Re: [HACKERS] Idea: closing the loop for pg_ctl reload

2015-07-03 Thread Jan de Visser
On July 3, 2015 06:21:09 PM Tom Lane wrote: I wonder whether we should consider inventing similar views for pg_hba.conf and pg_ident.conf. (Apologies for the flurry of emails). Was there not an attempt at a view for pg_hba.conf which ended in a lot of bikeshedding and no decisions? -- Sent

Re: [HACKERS] Idea: closing the loop for pg_ctl reload

2015-07-03 Thread Jan de Visser
On July 3, 2015 09:24:36 PM Jan de Visser wrote: On July 3, 2015 06:21:09 PM Tom Lane wrote: BTW, this version of this patch neglects to update the comments in miscadmin.h, and it makes the return convention for ProcessConfigFileInternal completely unintelligible IMO; the inaccuracy

Re: [HACKERS] Idea: closing the loop for pg_ctl reload

2015-07-03 Thread Jan de Visser
of functionality wouldn't make much sense. On Sat, Apr 25, 2015 at 10:03 AM, Jan de Visser j...@de-visser.net wrote: On April 22, 2015 06:04:42 PM Payal Singh wrote: The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature

Re: [HACKERS] Git humor

2015-06-14 Thread Jan de Visser
On June 14, 2015 02:07:16 PM Bruce Momjian wrote: If you ever had trouble understanding a git manual page, this humorous random git man page generator is full of fun: http://git-man-page-generator.lokaltog.net/ Try a few generate runs to find one that seems logical. :-) To my

Re: [HACKERS] 9.5 release notes

2015-06-13 Thread Jan de Visser
On June 13, 2015 09:30:12 PM Bruce Momjian wrote: Are there other countries where this would be appropriate? I'm pretty sure Hungarian uses the family name-given name ordering, and it's also sometimes used in French, and therefore you often see French family names spelled in all caps. --

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

2015-05-19 Thread Jan de Visser
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 abstraction layer

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

2015-05-19 Thread Jan de Visser
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 convinced

Re: [HACKERS] mogrify and indent features for jsonb

2015-04-29 Thread Jan de Visser
On April 29, 2015 03:09:51 PM Andrew Dunstan wrote: On 04/29/2015 01:19 PM, Robert Haas wrote: On Mon, Apr 27, 2015 at 6:41 PM, Andrew Dunstan and...@dunslane.net wrote: There's one exception I, at least, have to this rule, namely when there's a corresponding compound if or else. I

Re: [HACKERS] Idea: closing the loop for pg_ctl reload

2015-04-25 Thread Jan de Visser
On April 22, 2015 06:04:42 PM Payal Singh wrote: The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: tested, failed Spec compliant: not tested Documentation:tested, failed Error in

Re: [HACKERS] Improve sleep processing of pg_rewind TAP tests

2015-04-22 Thread Jan de Visser
On April 22, 2015 11:14:08 AM Heikki Linnakangas wrote: On 04/16/2015 06:51 AM, Alvaro Herrera wrote: Seems reasonable, but why are you sleeping 1s if pg_ctl -w is in use? I thought the -w would wait until promotion has taken effect, so there's no need to sleep additional time. -w is

Re: [HACKERS] Idea: closing the loop for pg_ctl reload

2015-03-04 Thread Jan de Visser
On March 4, 2015 11:08:09 PM Andres Freund wrote: Let's get the basic feature (notification of failed reloads) done first. That will be required with or without including the error message. Then we can get more fancy later, if somebody really wants to invest the time. Except for also fixing

Re: [HACKERS] Idea: closing the loop for pg_ctl reload

2015-03-03 Thread Jan de Visser
On March 3, 2015 10:29:43 AM Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2015-03-03 15:21:24 +, Greg Stark wrote: Fwiw this concerns me slightly. I'm sure a lot of people are doing things like kill -HUP `cat .../postmaster.pid` or the equivalent. postmaster.pid

Re: [HACKERS] Idea: closing the loop for pg_ctl reload

2015-03-03 Thread Jan de Visser
On March 3, 2015 11:09:29 AM Jim Nasby wrote: On 3/3/15 9:26 AM, Andres Freund wrote: On 2015-03-03 15:21:24 +, Greg Stark wrote: Fwiw this concerns me slightly. I'm sure a lot of people are doing things like kill -HUP `cat .../postmaster.pid` or the equivalent. postmaster.pid

Re: [HACKERS] Idea: closing the loop for pg_ctl reload

2015-03-03 Thread Jan de Visser
On March 3, 2015 04:57:58 PM Jim Nasby wrote: On 3/3/15 11:48 AM, Andres Freund wrote: I'm saying that you'll need a way to notice that a reload was processed or not. And that can't really be the message itself, there has to be some other field; like the timestamp Tom proposes. Ahh,

Re: [HACKERS] Idea: closing the loop for pg_ctl reload

2015-03-03 Thread Jan de Visser
On March 3, 2015 06:34:33 PM Jim Nasby wrote: On 3/3/15 5:24 PM, Jan de Visser wrote: On March 3, 2015 04:57:58 PM Jim Nasby wrote: On 3/3/15 11:48 AM, Andres Freund wrote: I'm saying that you'll need a way to notice that a reload was processed or not. And that can't really

Re: [HACKERS] Idea: closing the loop for pg_ctl reload

2015-03-03 Thread Jan de Visser
On March 2, 2015 12:56:23 AM Jan de Visser wrote: Here's my first crack at this. Notes: 1/ I haven't done the '-W' flag Tom mentions yet. 2/ Likewise haven't touched pg_reload_conf() 3/ Design details: I introduced a new struct in pg_ctl containing the parsed- out data from postmaster.pid

Re: [HACKERS] Idea: closing the loop for pg_ctl reload

2015-03-02 Thread Jan de Visser
On March 2, 2015 09:50:49 AM Tom Lane wrote: However, you could and should use pg_malloc0, which takes care of that for you... I am (using pg_malloc, that is). So, just to be sure: pg_malloc memsets the block to 0, right? My question was more along the lines if memsetting to 0 to ensure that

Re: [HACKERS] Idea: closing the loop for pg_ctl reload

2015-03-02 Thread Jan de Visser
On March 2, 2015 12:44:40 PM Tom Lane wrote: No, it doesn't, but pg_malloc0 does. Consult the code if you're confused: src/common/fe_memutils.c Doh! I read pg_malloc( ), not pg_malloc0. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Idea: closing the loop for pg_ctl reload

2015-03-01 Thread Jan de Visser
On February 19, 2015 08:26:45 PM Tom Lane wrote: Bug #12788 reminded me of a problem I think we've discussed before: if you use pg_ctl reload to trigger reload of the postmaster's config files, and there's something wrong with those files, there's no warning to you of that. The postmaster

Re: [HACKERS] Idea: closing the loop for pg_ctl reload

2015-03-01 Thread Jan de Visser
On March 2, 2015 12:56:23 AM Jan de Visser wrote: ... stuff ... I seem to have mis-clicked something in the CF app - I created two entries somehow. I think one got created when I entered the msgid of Tom's original message with the enclosing '...'. If that's the case, then that may be a bug

Re: [HACKERS] Idea: closing the loop for pg_ctl reload

2015-02-20 Thread Jan de Visser
On February 19, 2015 08:26:45 PM Tom Lane wrote: I don't have the time to pursue this idea myself, but perhaps someone looking for a not-too-complicated project could take it on. I can have a crack at this. What's the process? Do I add it to a CF once I have a patch, or do I do that

Re: [HACKERS] Can a C function(server program) be a UDP or TCP server?

2007-10-18 Thread Jan de Visser
-- -- Jan de Visser                     [EMAIL PROTECTED]                 Baruk Khazad! Khazad ai-menu! -- ---(end of broadcast

Re: [HACKERS] 8.1.5 is out

2006-10-18 Thread Jan de Visser
-- -- Jan de Visser                     [EMAIL PROTECTED]                 Baruk Khazad! Khazad ai-menu! -- ---(end of broadcast)--- TIP 3

Re: [HACKERS] Block B-Tree concept

2006-09-29 Thread Jan de Visser
de Visser                     [EMAIL PROTECTED]                 Baruk Khazad! Khazad ai-menu! -- ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http

Re: [HACKERS] Proposal for GUID datatype

2006-09-11 Thread Jan de Visser
On Monday 11 September 2006 11:05, Thomas Hallgren wrote: Jan de Visser wrote: On Friday 08 September 2006 15:18, Gevik Babakhani wrote: 2a) Three input formats are supported. example: insert into tbl (fld) values('1dfb39af-b56a-40b8-a903-b5b31567c3ce'); insert into tbl (fld) values

Re: [HACKERS] Proposal for GUID datatype

2006-09-09 Thread Jan de Visser
that you shouldn't limit yourself to any particular input formats. I understand that the example I gave is not a full GUID. As I said, I use that result as a base for a 128 bit GUID. Aargh. jan -- -- Jan de Visser

Re: [HACKERS] Proposal for GUID datatype

2006-09-08 Thread Jan de Visser
% So forms that use colons instead of dashes seem appropriate. Or better still, make it configurable. jan -- -- Jan de Visser                     [EMAIL PROTECTED]                 Baruk Khazad! Khazad ai

Re: [HACKERS] Proposal for GUID datatype

2006-09-08 Thread Jan de Visser
On Friday 08 September 2006 21:34, [EMAIL PROTECTED] wrote: On Fri, Sep 08, 2006 at 09:24:19PM -0400, Jan de Visser wrote: On Friday 08 September 2006 15:18, Gevik Babakhani wrote: 2a) Three input formats are supported. example: insert into tbl (fld) values('1dfb39af-b56a-40b8-a903

Re: [HACKERS] Proposal for GUID datatype

2006-09-08 Thread Jan de Visser
-- -- Jan de Visser                     [EMAIL PROTECTED]                 Baruk Khazad! Khazad ai-menu! -- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Build date for snapshots?

2006-09-07 Thread Jan de Visser
:) jan -- -- Jan de Visser                     [EMAIL PROTECTED]                 Baruk Khazad! Khazad ai-menu! -- ---(end of broadcast

Re: [HACKERS] 8.2 features status

2006-08-04 Thread Jan de Visser
can get rid of my recursive plsql functions. jan -- -- Jan de Visser                     [EMAIL PROTECTED]                 Baruk Khazad! Khazad ai-menu

Re: [HACKERS] [PERFORM] Hanging queries on dual CPU windows

2006-03-13 Thread Jan de Visser
this patch will actually work :-( But it's worth a try. I'm afraid you're right. Hangs again :( jan -- -- Jan de Visser                     [EMAIL PROTECTED]                 Baruk Khazad! Khazad ai-menu

Re: [HACKERS] [PERFORM] Hanging queries on dual CPU windows

2006-03-13 Thread Jan de Visser
On Monday 13 March 2006 09:26, Jan de Visser wrote: On Sunday 12 March 2006 09:40, Magnus Hagander wrote: Looking a my system while testing this it still loooked like it was hanging on that plac ein the code, even though I saw no problems. So I'm not convinced we can actually trust

Re: [HACKERS] [PERFORM] Hanging queries on dual CPU windows

2006-03-13 Thread Jan de Visser
if that changed things. I seem to remember we made ourselves dependend on 8.1 somehow, but will check. jan -- -- Jan de Visser                     [EMAIL PROTECTED]                 Baruk Khazad! Khazad ai-menu

Re: [HACKERS] [PERFORM] Hanging queries on dual CPU windows

2006-03-12 Thread Jan de Visser
-- -- Jan de Visser                     [EMAIL PROTECTED]                 Baruk Khazad! Khazad ai-menu! -- ---(end of broadcast)--- TIP 2: Don't