>>> 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,
> 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.
> Al
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 (lik
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 ti
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
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.
.. 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 m
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
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 impleme
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
> 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
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 ... :)
--
Just my two cents on this (rapidly degenerating) thread.
On 1/13/08, Sean Utt <[EMAIL PROTECTED]> wrote:
> Good to see 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 i
> ... 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 alienat
> ... 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 dif
15 matches
Mail list logo
