New submission which put option help in alphabetical position, as
per Peter Eisentraut f0ed3a8a99b052d2d5e0b6153a8907b90c486636
This is for reference to the next commitfest.
--
Fabien.diff --git a/contrib/pgbench/pgbench.c b/contrib/pgbench/pgbench.c
index 24dab1f..450646a 100644
--- a/contrib/
New submission which put option help in alphabetical position, as
per Peter Eisentraut f0ed3a8a99b052d2d5e0b6153a8907b90c486636
This is for reference to the next commitfest.
--
Fabien.diff --git a/contrib/pgbench/pgbench.c b/contrib/pgbench/pgbench.c
index 24dab1f..a86c862 100644
--- a/contri
On Sat, May 11, 2013 at 12:27 PM, Tom Lane wrote:
> By the time you've got an expression tree, the problem is mostly solved,
> at least so far as parser extension is concerned.
Right.
> More years ago than I care to admit, I worked on systems that had
> run-time-extensible parsers at Hewlett-Pac
On Fri, May 10, 2013 at 08:03:38PM -0400, Bruce Momjian wrote:
> On Fri, May 10, 2013 at 12:36:21PM -0400, Evan D. Hoffman wrote:
> > "pg.dropped.16" INTEGER /* dummy */,
> > "pg.dropped.17" INTEGER /* dummy */,
> > "pg.dropped.18" INTEGER
On Wed, May 8, 2013 at 1:48 PM, Jim Nasby wrote:
> On 5/8/13 3:54 AM, Heikki Linnakangas wrote:
>
>> On 24.04.2013 14:31, Florian Pflug wrote:
>>
>>> On Apr23, 2013, at 23:25 , Alexander Korotkov
>>> wrote:
>>>
I've taken a brief look on the paper and implementation. As I can
see iDista
David Fetter writes:
> On Sat, May 11, 2013 at 11:17:03AM -0400, Robert Haas wrote:
>> Some kind of extendable parser would be awesome. It would need to tie
>> into the rewriter also.
>>
>> No, I don't have a clue what the design looks like.
> That's a direction several of the proprietary RDBMS
On Fri, May 10, 2013 at 9:50 AM, Peter Eisentraut wrote:
> On 8/9/12 9:08 AM, Robert Haas wrote:
>> On Wed, Aug 8, 2012 at 6:50 PM, David Fetter wrote:
I'm wondering if perhaps -- in addition to what you've done here -- we
should make "psql -1" error out if reading from a terminal.
>>>
On Sat, May 11, 2013 at 11:17:03AM -0400, Robert Haas wrote:
> On Thu, May 9, 2013 at 7:36 AM, Michael Paquier
> wrote:
>
> >> Some of this is getting solved by making PostgreSQL more pluggable in
> >> ways that isolate the proprietary stuff, i.e. make people not have to
> >> touch the PostgreSQL
Simpler version of 'pgbench --throttle' by handling throttling at the
beginning of the transaction instead of doing it at the end.
This is for reference to the next commitfest.
--
Fabien.diff --git a/contrib/pgbench/pgbench.c b/contrib/pgbench/pgbench.c
index bc01f07..13b33c7 100644
--- a/con
On Thu, May 9, 2013 at 7:36 AM, Michael Paquier
wrote:
>> Some of this is getting solved by making PostgreSQL more pluggable in
>> ways that isolate the proprietary stuff, i.e. make people not have to
>> touch the PostgreSQL core code much, if at all, in order to provide
>> whatever special featu
On 10 May 2013 23:41, Jeff Davis wrote:
> On Fri, 2013-05-10 at 18:32 +0100, Simon Riggs wrote:
>> We don't write() WAL except with an immediate sync(), so the chances
>> of what you say happening are very low to impossible.
>
> Are you sure? An XLogwrtRqst contains a write and a flush pointer, so
11 matches
Mail list logo