Hi Simon,
On Thu, Jul 17, 2008 at 4:36 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2008-07-16 at 17:59 -0400, Neil Conway wrote:
> > On Wed, 2008-07-16 at 21:39 +0100, Simon Riggs wrote:
> > > TRUNCATE foo;
> > > TRUNCATE foo;
> > >
> > > works well.
> > >
> > > So why do we need
> > >
2008/7/17 Bruce Momjian <[EMAIL PROTECTED]>:
> Log Message:
> ---
> Add URL for:
>
> * Implement SQL:2003 window functions
>>
>> http://archives.postgresql.org/pgsql-hackers/2008-06/msg00380.php
>>
>
> Modified Files:
> --
>pgsql/doc:
>TODO (r1.2489 -> r1.2490)
>
Log Message:
---
Add to TODO:
>
> * Reduce locking requirements for creating a trigger
>
> http://archives.postgresql.org/pgsql-hackers/2008-06/msg00635.php
>
Modified Files:
--
pgsql/doc:
TODO (r1.2490 -> r1.2491)
(http://anoncvs.postgresql.org/cvsweb.
Log Message:
---
I am so ashamed to commit this patch. I created a BS function for PG < 8.3 to
prevent the (already hackish) txid code from failing to parse on a not-found
function.
The longer-term solution is probably to eval the code based on version using
plpgsql and 'execute.'
Modif
On Wed, 2008-07-16 at 17:59 -0400, Neil Conway wrote:
> On Wed, 2008-07-16 at 21:39 +0100, Simon Riggs wrote:
> > TRUNCATE foo;
> > TRUNCATE foo;
> >
> > works well.
> >
> > So why do we need
> >
> > TRUNCATE foo, foo;
>
> For the sake of completeness? Having "TRUNCATE foo, foo" fail would
On Wed, 2008-07-16 at 21:39 +0100, Simon Riggs wrote:
> TRUNCATE foo;
> TRUNCATE foo;
>
> works well.
>
> So why do we need
>
> TRUNCATE foo, foo;
For the sake of completeness? Having "TRUNCATE foo, foo" fail would be
rather inconsistent.
-Neil
--
Sent via pgsql-committers mailing list
Log Message:
---
Add URL for:
* Implement SQL:2003 window functions
>
> http://archives.postgresql.org/pgsql-hackers/2008-06/msg00380.php
>
Modified Files:
--
pgsql/doc:
TODO (r1.2489 -> r1.2490)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/TODO?
Yes,
TRUNCATE foo;
TRUNCATE foo;
works well.
So why do we need
TRUNCATE foo, foo;
---
On Wed, 2008-07-16 at 16:24 -0400, Bruce Momjian wrote:
> Logically, you should be able to truncate a table twice.
>
> ---
Logically, you should be able to truncate a table twice.
---
Simon Riggs wrote:
>
> On Wed, 2008-07-16 at 16:54 +, Bruce Momjian wrote:
> > Log Message:
> > ---
> > Allow TRUNCATE foo, foo to succeed, per report
On Wed, 2008-07-16 at 16:54 +, Bruce Momjian wrote:
> Log Message:
> ---
> Allow TRUNCATE foo, foo to succeed, per report from Nikhils.
What's the use case for this?
It's not compatibility, is it? Why would you ever do that? If you did,
why would you expect it to work? Seems more lik
Log Message:
---
Fix previous patch so that it actually works --- consider TRUNCATE foo,
public.foo
Modified Files:
--
pgsql/src/backend/commands:
tablecmds.c (r1.260 -> r1.261)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/tablecmds
On Wed, 2008-07-16 at 01:30 +, Tom Lane wrote:
> create_function.sgml (r1.78 -> r1.79)
>
> (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/ref/create_function.sgml?r1=1.78&r2=1.79)
I think CREATE FUNCTION should specifically mention that VARIADIC can
only be use
Log Message:
---
Add a "provariadic" column to pg_proc to eliminate the remarkably expensive
need to deconstruct proargmodes for each pg_proc entry inspected by
FuncnameGetCandidates(). Fixes function lookup performance regression
caused by yesterday's variadic-functions patch.
In passing
Log Message:
---
Allow TRUNCATE foo, foo to succeed, per report from Nikhils.
Modified Files:
--
pgsql/src/backend/commands:
tablecmds.c (r1.259 -> r1.260)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/tablecmds.c?r1=1.259&r2=1.260)
Log Message:
---
Add to TODO:
>
> o Add external tool to auto-tune some postgresql.conf parameters
>
> http://archives.postgresql.org/pgsql-hackers/2008-06/msg0.php
>
Modified Files:
--
pgsql/doc:
TODO (r1.2488 -> r1.2489)
(http://anonc
Log Message:
---
tag 1.2rc2
Modified Files:
--
pgbouncer:
configure.ac (r1.37 -> r1.38)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/configure.ac.diff?r1=1.37&r2=1.38)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgre
Log Message:
---
test: increase allowed conns, decrease buffer len
Modified Files:
--
pgbouncer/test:
asynctest.c (r1.10 -> r1.11)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/test/asynctest.c.diff?r1=1.10&r2=1.11)
ctest7000.ini
Log Message:
---
few doc cleanups
Modified Files:
--
pgbouncer/doc:
config.txt (r1.9 -> r1.10)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/doc/config.txt.diff?r1=1.9&r2=1.10)
usage.txt (r1.5 -> r1.6)
(http://cvs.pgfound
Log Message:
---
Further memory conservation by making state bitfield :8.
Does this need #ifdef __GCC__?
Modified Files:
--
pgbouncer/include:
bouncer.h (r1.16 -> r1.17)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/include/bouncer.h.dif
19 matches
Mail list logo
