Re: [HACKERS] Commitfest Code Sprint with PUGs
The CommitFest is scheduled to start 9/15, so doing this on 9/8 might be a bit too soon. I wouldn't object to doing it a few days before the start of the CommitFest to flush out any patches with obvious problems, but I think a week ahead of time is too much. Yeah, I meant Tues 9/15. Also, I don't think anything is going to committed as a result of this - the goal is to post reviewers to pgsql-hackers. Sounds good. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commitfest Code Sprint with PUGs
Hi Josh et al, I believe we are all still interested (Selena? Gabrielle?) How about this: 6:00 Tuesday evening (Pacific), the three of us (and anybody else) agree to be around a table with laptops on, cellphones ready, listening at an IRC channel. Could you assign us good patches before then (like 10)? And then we commit, commit, commit. I think we should think of this as a dry run where we iron out the details, and then maybe the following saturday do it again on a larger scale? -W On Thu, Sep 3, 2009 at 10:23 AM, Josh Berkusj...@agliodbs.com wrote: Webb, Selena, Gabrielle, September 15th is coming up soon. Will PDXPUG be interested in doing a CommitFest Sprint? When can you do it? Let me know, because we'll want to have the sprinters claim patches early. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commitfest Code Sprint with PUGs
How about this: 6:00 Tuesday evening (Pacific), the three of us (and anybody else) agree to be around a table with laptops on, cellphones ready, listening at an IRC channel. Could you assign us good patches before then (like 10)? And then we commit, commit, commit. Sounds good, already have at least someone else from #pdxpug interested too. :) Just need to pick a location. Anybody have a quiet house? I can probably finagle a room here at PSU, though I would love it if someone would volunteer a house. I think we should think of this as a dry run where we iron out the details, and then maybe the following saturday do it again on a larger scale? Practice run was my expectation as well. Making both dates might be problematic for some people (:ahem: me) but we should have enough attendee overlap to deal with that. OK, let's play followups by ear, but consider Tues Sept 15 as the date? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commitfest Code Sprint with PUGs
So if the general commitfest begins on Sept 1, I recommend that we hold our sprint the weekend following (saturday 5, say 10am to 4pm Pacific Standard?). Thoughts? If we set a date, then people can converge on it. Pardon me if I am replying without enough context -- I have enough compelling time sinks in my life without the various PostgreSQL lists these days. Gabrielle -- have you started a wiki page/ topic somewhere? w -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Website request -- developer docs along with release docs
Could I request that a link to the developer docs be posted along with the release docs on http://www.postgresql.org/docs/manuals/ ? First -- it is interesting. Second, if one is running CVS HEAD for testing (always a service to the community, if not your data), they are the appropriate docs. Finally, it gives users a chance to see why they might want to upgrade (for example by browsing the awesome windowing capabilities, etc). And yes, I could write a patch,... Tx On Mon, Oct 27, 2008 at 8:50 AM, Eric Haszlakiewicz [EMAIL PROTECTED] wrote: On Sun, Oct 19, 2008 at 11:21:09PM -0400, Tom Lane wrote: Eric Haszlakiewicz [EMAIL PROTECTED] writes: On Sun, Oct 19, 2008 at 10:15:22PM -0400, Tom Lane wrote: What platform is this, anyway? I'm running on NetBSD 4. Well, it seems that something doesn't work right with the try the next key code when the userid are the same. I'm not really sure what I should try here. I read the code and the shmget spec a bit more. It looks to me like the issue may be about the ordering of error checks in the kernel. The Single Unix Spec quoth ...snip... If you are starting the two servers with different shmem sizing parameters then it is possible that the second reason for giving EINVAL applies. Now our code is expecting to get EEXIST if there's a shmem ...snip... So the first question for you is did you give the two servers different shmem sizing parameters? If so, does the behavior change if you start them in the opposite order? If the answer to both is yes then I think you ought to file a bug against NetBSD kernel. They're returning an error code that is uselessly confusing and out of step with other implementations. Yes, and yes. The error checking order in NetBSD put the EEXIST return last so the different size check was taking precedence. I fixed that, and now starting two pg servers, even in different chroot's, behaves as expected. Thanks for the suggestion of where to look! eric -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Website request -- developer docs along with release docs
Thanks to all for the link.\ they are already referenced in the development section of the website: They are actually a little difficult to find for those of us that don't use that section frequently, or at least finding a navigation page to that section. I'm not sure we actively should put them on the same page as the release docs - I could imagine people getting confused about that. How about a vote? I don't think postgres admins are that, ahem, unsophisticated. We could put them in blink if we had to ;) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Plugin system like Firefox
.. an OS-agnostic way of installing packages. Uh.. I don't think such a thing exists. Seems to in Firefox. And Perl's CPAN repository and installation module. Don't forget the command line installation of packages for the R programming language. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: new function array_init
On Mon, Jun 2, 2008 at 9:46 AM, Tom Lane [EMAIL PROTECTED] wrote: Pavel Stehule [EMAIL PROTECTED] writes: There was more time questions about array's initialisation. I propose function array_init. As one of the questioners, I will give some short thoughts below. CREATE OR REPLACE FUNCTION array_init(sizes int[], v anyelement) RETURNS anyarray; +1. +0 for Pavel's proposed syntax, because it feels better, but also it scales to N dimensions (we should throw an error obviously if the input is too big, but we can probably source that size through an include), I hate functions with more than four arguments, and having six slightly overloaded functions in the system catalogs seems annoying. * We can handle a null fill value now, but what about nulls in the dimensions? The alternatives seem to be to return a null array (not an array of nulls) or throw error. I would throw an error, unless there is something that one can do with a null array (perhaps there is?). We also might want to consider a resize function, and some other utilities as long as we are bothering with this. I am sorry that I can't offer to write these, but I don't have the time to learn the Postgresql infrastructure to do it. Thanks for the attention Pavel! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Ideas input sought for this year's SOC page
On Wed, Mar 12, 2008 at 2:44 PM, Peter Eisentraut [EMAIL PROTECTED] wrote: Josh Berkus wrote: We need to update the SoC page: http://www.postgresql.org/developer/summerofcode ... with new ideas and projects appropriate for PostgreSQL 8.4/8.5. Can we add a project to implement advanced and matrix mathematics in PG, with transparency between arrays and matrices/vectors? A GSL, BLAS, LAPACK set of hooks, with operators? I realize there is the excellent plr project, but to be honest I hate the R programming language and I think we could really use something simpler and implemented more directly. (If I were a real programmer, I would take it on, but I can't see being able to follow through on it.) Many of these items could be suitable: http://wiki.postgresql.org/wiki/XML_Todo -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] creating new aggregate function
This probably belongs on General, but On Fri, Feb 29, 2008 at 9:11 AM, Justin [EMAIL PROTECTED] wrote: Need help and direction creating new aggregate functions. We need to add more average functions for both scientific and finical purposes RMS for electrical measurement purposes Mode for both electrical and finical Weighted Average finical purposes Generalized mean for electrical measurement purposes Geometric mean for electrical measurement purposes Harmonic mean for electrical measurement purposes what would be the best way to create these new functions?? Have you already read the documentation on creating aggregates? Have you tried something and it didn't work, or are you interested in design ideas? I would just knock together something in plpgsql. If you have trouble, send the specific questions to the list. best ? C is fastest, etc -- what kind of tradeoffs do you need to satisfy? One thing worth thinking about is using arrays to carry state from one function call to the next in an aggregate; this is how the function used in the average aggregate keeps track of both the running total and the number of rows. The Stdev uses a three item array similarly. ---(end of broadcast)--- TIP 6: explain analyze is your friend ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Postgresql Materialized views
Just my two cents on this (rapidly degenerating) thread. On 1/13/08, Sean Utt [EMAIL PROTECTED] wrote: sarcasmGood to see/sarcasm things haven't changed, and requests for features and improvements on the pgsql-hackers list can still degenerate rapidly into a discussion about how to request features and improvements. As Joshua Drake has pointed out before, most of the core people working on PostgreSQL don't actually use it for anything themselves. I will expand a little on that and say that this means that while they are extremely good at what they do, they really don't have a clue what might be useful to someone in the wild. Sort of like automotive engineers who in the 1970's made the Cadillac's engine so large that you couldn't change the spark plugs without taking the motor mounts loose and lifting the engine. As a very satisfied Postgres customer, I take exception to the comparison. SNIP There doesn't appear to be an easy way to officially take the temperature of either the developer community, or the user community, and there certainly is no official way to clearly and easily communicate between the two in order to effect change. Huh? A politely worded feature request generally gets discussed and then put on the TODO list if there is some consensus about its usefulness. If there is no consensus, then the requester usually has to do more work, which might involve prototyping some code etc. Admittedly, some developers get grumpy sometimes, but, as the man said, Let him who is without sin throw the first stone... There was an issue with the tone of the request for material views in the beginning of this thread, but that seems to ironed out among those who are actually interested in accomplishing something. May I propose the following: (1) can we put materialized views on the TODO, perhaps as a library or as core, still subject to a lot of design work and with no particular deadline? (2) Can we discontinue this particular flame war about the responsive of the developers (who in my estimation do a huge amount of work that benefits me immensely with nary a thank you)? Sorry for the meta rant, I just couldn't take it anymore. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Postgresql Materialized views
I realize that some very important navel-gazing (^H^H^H group process) is happening, but let us remember where bona-fide feature requests should go: http://www.postgresql.org/docs/faqs.TODO.html So far, I don't see any mention of materialized views on this page, and I did refresh ... :) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Postgresql Materialized views
But did you clear your cache? :P Freud might say it takes a lifetime to clear one's cache Luckily, in therapy you don't have to wait for those darn Postgres developers ;) Joshua D. Drake ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Simplifying Text Search
... Therefore, we have to tell people to use some other API anyway. The existing tsearch2 API at least has the virtue of having been proven in the field over several years. I can only speak as a moderately sophisticated end user, but ... I think the tsearch2 API has been proven to alienate a lot of potential users, myself included. If the simple things were simple, there might be a large user base that would rebel against an API extension, but I don't think this is the case. And I think the need for a simpler, refactored interface to tsearch is desperate. Granted, one can learn tsearch2 as is, but it is somewhat painful. It isn't the sort of thing one figures out for fun and potential future use, but probably only if one is forced to. If we (well, you, really) could make tsearch2 less like C++ (or OCAML or FORTH ) and more like Python, we would get a whole lot of new users of tsearch in the process, and probably a whole of good will toward PostgreSQL. -W ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] INSERT/SELECT and excessive foreign key checks
... People keep proposing variants of the idea that the executor should optimize updates on the basis of examining the query tree to see whether columns changed or not, and they're always wrong. You don't know what else might have been done to the row by BEFORE triggers. Is there a different potential hack for marking a table read-only, turning it on and off with a function()? In a hackish vein, use a trigger to enforce this, and maybe a rule that can do the optimization? I wouldn't be the one writing this, so maybe it is ridiculous and I apologize for contributing to list-noise, but perhaps it would be useful for those tables that change so rarely. Of course, it would be a contrib package and nothing for the core. -w ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
