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, not

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* > > beyond > > what yo

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 the server. > > OK, fair

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" 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. > > An

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 "If

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 a pita * https://www.postgresql.org/message-id

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 nevertheless the process was sit

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 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. > >

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 t

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 v

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? -- Sen

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 unintelligibl

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 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 pla

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

2015-07-03 Thread Jan de Visser
On Fri, Jul 3, 2015 at 4:47 PM, I wrote: > 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 explained seems to be runtime.sgml and that descript

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

2015-07-03 Thread Jan de Visser
it of functionality wouldn't make much sense. On Sat, Apr 25, 2015 at 10:03 AM, Jan de Visser 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 test

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 m

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 jok

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 convin

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 wrote: > >> There's one exception I, at least, have to this rule, namely when there's > >> a > >> corresponding compound if or else. I personally fi

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

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. > >

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

2015-04-21 Thread Jan de Visser
On April 21, 2015 09:34:51 PM Jan de Visser wrote: > On April 21, 2015 09:01:14 PM Jan de Visser wrote: > > On April 21, 2015 07:32:05 PM Payal Singh wrote: ... snip ... > > Urgh. It appears you are right. Will fix. > > jan Attached a new attempt. This was one from the cat

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

2015-04-21 Thread Jan de Visser
On April 21, 2015 09:01:14 PM Jan de Visser wrote: > On April 21, 2015 07:32:05 PM Payal Singh wrote: > > I'm trying to review this patch and applied > > http://www.postgresql.org/message-id/attachment/37123/Let_pg_ctl_check_the > > _r esult_of_a_postmaster_config_reloa

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

2015-04-21 Thread Jan de Visser
(Please don't top post) On April 21, 2015 07:32:05 PM Payal Singh wrote: > I'm trying to review this patch and applied > http://www.postgresql.org/message-id/attachment/37123/Let_pg_ctl_check_the_r > esult_of_a_postmaster_config_reload.patch to postgres. gmake check passed > but while starting pos

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 fixi

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

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. >

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. > > > > postm

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 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 already

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_ct

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 subscrip

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 tha

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 cas

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 postmaste

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 beforehan

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

2007-10-18 Thread Jan de Visser
wrote: > > I can write the network program. > > ... Oh my. The worst kind of top-poster: the kind that copies *your* reply from the bottom to the top and top-posts above that. Shudder... :) ja

Re: [HACKERS] 8.1.5 is out

2006-10-18 Thread Jan de Visser
--(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings -- -- Jan de Visser                     [EMAIL PROTECTED]                 Baruk Khazad! Khazad ai-men

Re: [HACKERS] Block B-Tree concept

2006-09-29 Thread Jan de Visser
re's no value X in the > index so that A < X < B". Maybe there's a better word for that. http://en.wikipedia.org/wiki/Monotonic jan -- -- Jan de Visser                     [EMAIL PROTECTED]                 Baruk Khazad! Khazad ai-menu! ---

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-

Re: [HACKERS] Proposal for GUID datatype

2006-09-09 Thread Jan de Visser
t. I am just saying 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 -- ------------

Re: [HACKERS] Proposal for GUID datatype

2006-09-08 Thread Jan de Visser
would work just fine. jan -- ---------- Jan de Visser                     [EMAIL PROTECTED]                 Baruk Khazad! Khazad ai-menu! -- ---(end of broadcast)---

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

Re: [HACKERS] Proposal for GUID datatype

2006-09-08 Thread Jan de Visser
.rmi.server.UID()); 3b732da7:10d9029b3eb:-8000 bsh % So forms that use colons instead of dashes seem appropriate. Or better still, make it configurable. jan -- ---------- Jan de Visser                     [EMAI

Re: [HACKERS] Build date for snapshots?

2006-09-06 Thread Jan de Visser
al things will muck up file timestamps by copying :) jan -- ---------- Jan de Visser                     [EMAIL PROTECTED]                 Baruk Khazad! Khazad ai-menu! -- --

Re: [HACKERS] 8.2 features status

2006-08-04 Thread Jan de Visser
cited > about writing a patch no one sees a real need for. Make that five. I'll bless the day I can get rid of my recursive plsql functions. jan -- -- Jan de Vi

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

2006-03-13 Thread Jan de Visser
the ability to test 8.0 on the same machine? We did some > extensive modifications to the signal stuff between 8.0 and 8.1, it'd be > interesting to see if that changed things. I seem to remember we made ourselves dependend on 8.1 somehow, but will check. jan -- --

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 convi

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

2006-03-13 Thread Jan de Visser
reads. So I don't think 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]    

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

2006-03-12 Thread Jan de Visser
it's > worth a try. > > (Oh, and I moved the thread over to -hackers, seems more correct at this > time) Thanks Magnus, I'll try tomorrow. Will let you know ASAP (8:30 EST I guess :). If