On Thu, Apr 5, 2012 at 6:33 PM, Hannu Krosing wrote:
> I would really like the controversial parts of the recent feature creep
> to get un-creeped :)
>
> At least until 9.3 .
This argument would hold more water if I hadn't been encouraging
Dimitri to pick a less aggressive target for this feature
On Sat, Apr 7, 2012 at 5:20 PM, Tom Lane wrote:
> I wonder whether we ought to have a preset schedule for last fests
> just like the others.
It's always been my feeling that we should have that.
> There's too much temptation to commit
> patches that are not really ready, just to get them out of
Andrew Dunstan writes:
> On 04/07/2012 06:33 PM, Peter Geoghegan wrote:
>> I hope that that policy will not be applied without some degree of
>> discrimination.
> If we are to have time based releases, then I assume it won't, it will
> be pretty much a hard and fast rule.
> I admit I haven't be
On 7 April 2012 23:51, Tom Lane wrote:
> As for the steering committee, core tries hard not to make technical
> decisions for the project; it's better to let those emerge by consensus.
I don't really consider this to be an engineering problem, which is
precisely why I bring up the role of core he
On 04/07/2012 06:33 PM, Peter Geoghegan wrote:
On 7 April 2012 22:20, Tom Lane wrote:
In short, the idea of strongly calendar-driven releases looks more
and more attractive to me the more times we go through this process.
If your patch isn't ready on date X, then it's not getting into this
re
Peter Geoghegan writes:
> On 7 April 2012 22:20, Tom Lane wrote:
>> In short, the idea of strongly calendar-driven releases looks more
>> and more attractive to me the more times we go through this process.
>> If your patch isn't ready on date X, then it's not getting into this
>> release; but th
On 7 April 2012 22:20, Tom Lane wrote:
> In short, the idea of strongly calendar-driven releases looks more
> and more attractive to me the more times we go through this process.
> If your patch isn't ready on date X, then it's not getting into this
> release; but there'll be another bus coming al
On 7 April 2012 22:20, Tom Lane wrote:
> In short, the idea of strongly calendar-driven releases looks more
> and more attractive to me the more times we go through this process.
> If your patch isn't ready on date X, then it's not getting into this
> release; but there'll be another bus coming al
Robert Haas writes:
> [ among other good points ]
> ... On a related note, letting CommitFests go on for three
> months because there's insufficient reviewer activity to get them done
> in one or two is, in my opinion, not much of a solution. If there's
> even less reviewer activity next time, ar
On Fri, Apr 6, 2012 at 3:22 AM, Greg Smith wrote:
> On 04/05/2012 05:03 PM, Daniel Farina wrote:
>> To get to the point, I wonder if it makes sense for someone who has a
>> better sense a-priori what they're looking for in a committable patch
>> (i.e. a committer, or someone with a telepathic link
2012/4/7 Shigeru HANADA :
> I've updated pgsql_fdw so that it can collect statistics from foreign
> data with new FDW API.
I notice that if you restart the remote server, the connection is
broken, but the client doesn't notice this until it goes to fire off
another command. Should there be an opt
On tor, 2012-04-05 at 19:49 +0200, Jean-Baptiste Quenot wrote:
> I consider that this is an error to request metadata when the query does
> not return some. For example: "UPDATE mytable SET value = 1" does not
> return column metadata, so user is not supposed to col coltypes(). That's
> why I pro
On Sat, Apr 07, 2012 at 01:20:08PM +0200, Michael Meskes wrote:
> On Fri, Mar 30, 2012 at 12:48:07AM +0200, Boszormenyi Zoltan wrote:
> > Attached is the new core feature patch. Summary of changes:
> > ...
> > I also refreshed the second patch that drives all cursors with the new
> > ...
>
> I'm s
Peter Eisentraut writes:
> On ons, 2012-04-04 at 18:59 -0400, Tom Lane wrote:
>> Uh, no. That test is there for good and sufficient reasons, as per its
>> comment:
> I had reviewed that thread very carefully, but I'm not sure it applies.
> The issue was that we don't want aggregates with optiona
On Fri, Mar 30, 2012 at 12:48:07AM +0200, Boszormenyi Zoltan wrote:
> Attached is the new core feature patch. Summary of changes:
> ...
> I also refreshed the second patch that drives all cursors with the new
> ...
I'm slightly confused here. It seems Zoltan added a second patch *after* Noah
marke
Hi All,
I submitted a GSoc application yesterday. Please review it and let me know
if anyone needs any clarifications.
Atri
On ons, 2012-04-04 at 18:59 -0400, Tom Lane wrote:
>
> >> Why not call it string_agg?
>
> > Here is a patch to do the renaming. As it stands, it fails the
> > opr_sanity regression test, because that complains that there are now
> > two aggregate functions string_agg with different number of arg
On ons, 2012-04-04 at 19:26 -0700, Harold Giménez wrote:
> It would also be nice if the invocation of pg_ctl didn't pipe its
> output to /dev/null. I'm sure it would contain information that would
> directly point at the root cause and could've saved some debugging and
> hand waving time.
This asp
18 matches
Mail list logo
