2013-01-02 01:24 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
2013-01-01 17:18 keltezéssel, Magnus Hagander írta:
That way we can get around the whole need for changing memory allocation across
all the
frontends, no? Like the attached.
Sure it's simpler but then
On Wed, Jan 2, 2013 at 9:59 AM, Boszormenyi Zoltan z...@cybertec.at wrote:
2013-01-02 01:24 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
2013-01-01 17:18 keltezéssel, Magnus Hagander írta:
That way we can get around the whole need for changing memory
allocation
2013-01-02 10:12 keltezéssel, Magnus Hagander írta:
On Wed, Jan 2, 2013 at 9:59 AM, Boszormenyi Zoltan z...@cybertec.at
mailto:z...@cybertec.at wrote:
2013-01-02 01:24 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at mailto:z...@cybertec.at writes:
2013-01-02 10:37 keltezéssel, Boszormenyi Zoltan írta:
2013-01-02 10:12 keltezéssel, Magnus Hagander írta:
On Wed, Jan 2, 2013 at 9:59 AM, Boszormenyi Zoltan z...@cybertec.at
mailto:z...@cybertec.at wrote:
2013-01-02 01:24 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan
2013-01-02 10:12 keltezéssel, Magnus Hagander írta:
On Wed, Jan 2, 2013 at 9:59 AM, Boszormenyi Zoltan z...@cybertec.at
mailto:z...@cybertec.at wrote:
2013-01-02 01:24 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at mailto:z...@cybertec.at writes:
On Wed, Jan 2, 2013 at 1:15 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Noah Misch n...@leadboat.com writes:
On Tue, Jan 01, 2013 at 04:29:35PM +0100, Magnus Hagander wrote:
On Thu, Aug 30, 2012 at 11:41 PM, Bruce Momjian br...@momjian.us wrote:
Do we want to change our ssl_ciphers default to
On 27.12.2012 12:06, Heikki Linnakangas wrote:
On 23.12.2012 15:33, Fujii Masao wrote:
On Fri, Dec 21, 2012 at 9:54 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Yes, this should be backpatched to 9.2. I came up with the attached.
In this patch, if '-X stream' is specified in
On Wed, Jan 02, 2013 at 02:03:20PM +0100, Magnus Hagander wrote:
On Wed, Jan 2, 2013 at 1:15 AM, Tom Lane t...@sss.pgh.pa.us wrote:
So +1 for changing it to DEFAULT from me, too. There's no reason to
think we know more about this than the OpenSSL authors.
The DEFAULT value in OpenSSL 1.0
On Wed, Jan 2, 2013 at 3:15 PM, Noah Misch n...@leadboat.com wrote:
On Wed, Jan 02, 2013 at 02:03:20PM +0100, Magnus Hagander wrote:
On Wed, Jan 2, 2013 at 1:15 AM, Tom Lane t...@sss.pgh.pa.us wrote:
So +1 for changing it to DEFAULT from me, too. There's no reason to
think we know more
Hi,
we are trying to integrate GMDA algorithm into postgresql. The operater
decouples grouping from
aggregation and we came up with the following syntax:
SELECT d, u, COUNT(*b.u = r.u*) AS ccu, COUNT(*b.d = r.d*) AS ccd
FROM b *GMDJOIN* r
GROUP BY d, u
This select query should be rewritten to:
On Wed, Jan 2, 2013 at 10:03 AM, Magnus Hagander mag...@hagander.net wrote:
Finally we deny MD5 - I have no idea why we do that.
Because it's broken, same motivation as in the thread for implementing
ZK authentication.
Also, I seem to have missed something because the thread subject
mentions
2012-12-11 16:09 keltezéssel, Simon Riggs írta:
On 11 December 2012 12:18, Boszormenyi Zoltan z...@cybertec.at wrote:
Such mechanism already exist - you just need to set
your PGresult pointer to NULL after each PQclear().
So why doesn't PQclear() do that?
Because then PQclear() would need a
On Wed, Jan 2, 2013 at 5:11 PM, Boszormenyi Zoltan z...@cybertec.at wrote:
2012-12-11 16:09 keltezéssel, Simon Riggs írta:
On 11 December 2012 12:18, Boszormenyi Zoltan z...@cybertec.at wrote:
Such mechanism already exist - you just need to set
your PGresult pointer to NULL after each
Sorry, I oversight this report.
The reason of this confusing error message is originated by incorrect
aclkind being delivered to aclcheck_error() at AlterObjectOwner_internal().
/* New owner must have CREATE privilege on namespace */
if (OidIsValid(namespaceId))
2012/12/20 Robert Haas robertmh...@gmail.com:
The recent SET SCHEMA refactoring has changed the error message that
you get when trying to move a function into the schema that already
contains it.
For a table, as ever, you get:
rhaas=# create table foo (a int);
CREATE TABLE
rhaas=# alter
On 02.01.2013 17:27, Marko Kreen wrote:
On Wed, Jan 2, 2013 at 5:11 PM, Boszormenyi Zoltanz...@cybertec.at wrote:
2012-12-11 16:09 keltezéssel, Simon Riggs írta:
On 11 December 2012 12:18, Boszormenyi Zoltanz...@cybertec.at wrote:
Such mechanism already exist - you just need to set
your
2013-01-02 16:27 keltezéssel, Marko Kreen írta:
On Wed, Jan 2, 2013 at 5:11 PM, Boszormenyi Zoltan z...@cybertec.at wrote:
2012-12-11 16:09 keltezéssel, Simon Riggs írta:
On 11 December 2012 12:18, Boszormenyi Zoltan z...@cybertec.at wrote:
Such mechanism already exist - you just need to
2013-01-02 16:52 keltezéssel, Heikki Linnakangas írta:
On 02.01.2013 17:27, Marko Kreen wrote:
On Wed, Jan 2, 2013 at 5:11 PM, Boszormenyi Zoltanz...@cybertec.at wrote:
2012-12-11 16:09 keltezéssel, Simon Riggs írta:
On 11 December 2012 12:18, Boszormenyi Zoltanz...@cybertec.at wrote:
Hi all,
When we execute 'make clean' the file 'src/backend/replication/repl_gram.h'
is not removed.
The attached patch fix it.
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
Blog sobre TI: http://fabriziomello.blogspot.com
Perfil Linkedin:
Hi,
the previously sent factor out pg_malloc and friends patch
may call exit() in case of OOM during allocation and as a consequence,
PQfinish() won't get called, leaving an unexpected EOF from client
in the log.
Let's close this annoyance in pg_basebackup. The attached patch does
the
On 02.01.2013 18:05, Fabrízio de Royes Mello wrote:
Hi all,
When we execute 'make clean' the file 'src/backend/replication/repl_gram.h'
is not removed.
That's on purpose. repl_gram.h is generated by bison, along with
repl_gram.c. Neither is removed by make clean, because they're needed
in
Boszormenyi Zoltan z...@cybertec.at writes:
2013-01-02 16:52 keltezéssel, Heikki Linnakangas írta:
IMHO this doesn't belong into libpq, the interface is fine as it is. It's
the caller's
responsibility to set the pointer to NULL after PQclear(), same as it's the
caller's
responsibility to
On 02.01.2013 18:20, Heikki Linnakangas wrote:
Hmm, looking closer though, repl_gram.h is not actually needed for
anything, though. We could just remove the -d flag from the bison
invocation and not build it to begin with. I'll go and do that..
And looking even closer, we don't use the -d flag
I committed this with minor tweaks to avoid having to scan the
registered workers list on each registration. Opinions on this error
report are still welcome:
+ ereport(LOG,
+
(errcode(ERRCODE_CONFIGURATION_LIMIT_EXCEEDED),
+
2013/1/2 Heikki Linnakangas hlinnakan...@vmware.com
On 02.01.2013 17:27, Marko Kreen wrote:
On Wed, Jan 2, 2013 at 5:11 PM, Boszormenyi Zoltanz...@cybertec.at
wrote:
2012-12-11 16:09 keltezéssel, Simon Riggs írta:
On 11 December 2012 12:18, Boszormenyi Zoltanz...@cybertec.at wrote:
2012/12/31 Simon Riggs si...@2ndquadrant.com:
On 23 December 2012 18:49, Simon Riggs si...@2ndquadrant.com wrote:
Anyway, hope you can make call on 28th so we can discuss this and
agree a way forwards you're happy with.
Stephen, KaiGai and myself met by phone on 28th to discuss.
1. The
Magnus Hagander mag...@hagander.net writes:
On Wed, Jan 2, 2013 at 4:14 AM, Andrew Dunstan and...@dunslane.net wrote:
This seems to have broken plperl builds on Windows.
I'm not really sure what the best thing is to do here. We can either
use the fact that we know that uid_t and gid_t are int
2013-01-02 17:22 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
2013-01-02 16:52 keltezéssel, Heikki Linnakangas írta:
IMHO this doesn't belong into libpq, the interface is fine as it is. It's the
caller's
responsibility to set the pointer to NULL after PQclear(),
On Wed, Jan 2, 2013 at 5:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Wed, Jan 2, 2013 at 4:14 AM, Andrew Dunstan and...@dunslane.net wrote:
This seems to have broken plperl builds on Windows.
I'm not really sure what the best thing is to do here.
Magnus Hagander mag...@hagander.net writes:
On Wed, Jan 2, 2013 at 5:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Why are these very tar-specific functions being declared in such a
globally visible spot as port.h? That seems like a bad idea on its
face. IMO stuff in port.h ought to be about as
2013-01-02 17:17 keltezéssel, Boszormenyi Zoltan írta:
Hi,
the previously sent factor out pg_malloc and friends patch
may call exit() in case of OOM during allocation and as a consequence,
PQfinish() won't get called, leaving an unexpected EOF from client
in the log.
Let's close this annoyance
On Wed, Jan 02, 2013 at 05:35:13PM +0100, Kohei KaiGai wrote:
2012/12/31 Simon Riggs si...@2ndquadrant.com:
On 23 December 2012 18:49, Simon Riggs si...@2ndquadrant.com wrote:
Anyway, hope you can make call on 28th so we can discuss this and
agree a way forwards you're happy with.
On Wed, Jan 2, 2013 at 2:23 PM, Heikki Linnakangas
hlinnakan...@vmware.comwrote:
On 02.01.2013 18:20, Heikki Linnakangas wrote:
Hmm, looking closer though, repl_gram.h is not actually needed for
anything, though. We could just remove the -d flag from the bison
invocation and not build it to
On 2 January 2013 17:19, David Fetter da...@fetter.org wrote:
Would COPY be covered separately? How about TRUNCATE?
COPY == INSERT
TRUNCATE isn't covered at all since it doesn't look at rows. It has a
separate privilege that can be granted to those that need it.
Also, is there any way to
On Wed, Jan 02, 2013 at 05:31:42PM +, Simon Riggs wrote:
On 2 January 2013 17:19, David Fetter da...@fetter.org wrote:
Would COPY be covered separately? How about TRUNCATE?
COPY == INSERT
Makes sense. The reason I mentioned it is that COPY is supposed to be
a very fast bulk loading
On Wed, Jan 2, 2013 at 1:55 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
If you take a backup with pg_basebackup -X fetch, and the timeline
switches while the backup is taken, you currently get an error like
requested WAL segment 0001000C has already been removed.
To
On Wed, Jan 2, 2013 at 5:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Wed, Jan 2, 2013 at 5:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Why are these very tar-specific functions being declared in such a
globally visible spot as port.h? That seems like
On Wed, Dec 26, 2012 at 3:33 PM, Andrew Dunstan and...@dunslane.net wrote:
Here is a patch for the first part of the JSON API that was recently
discussed. It includes the json parser hook infrastructure and functions
for json_get and friends, plus json_keys.
As is, this exposes the json
On Fri, Dec 28, 2012 at 1:06 PM, Charles Gomes charle...@outlook.com wrote:
I'm creating a simple trigger that will be called during an insert and change
the destination table.
All values are going to be preserved, just the destination table will be
different.
From what I see I can't
On Fri, Dec 28, 2012 at 7:09 AM, Hannu Krosing ha...@krosing.net wrote:
thus
CREATE FUNCTION foo(a int,b int, c text)
would create module
plpy.modules.foo_int4_int4_text
I don't know much of anything about Python, but keep in mind that
types can be renamed. It seems like that could break
On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
I am not sure, but maybe is time to introduce ANSI SQL syntax for
functions' named parameters
It is defined in ANSI SQL 2011
CALL P (B = 1, A = 2)
instead PostgreSQL syntax CALL ( B := 1, A := 2)
Keep in mind
On 01/02/2013 04:45 PM, Robert Haas wrote:
On Wed, Dec 26, 2012 at 3:33 PM, Andrew Dunstan and...@dunslane.net wrote:
Here is a patch for the first part of the JSON API that was recently
discussed. It includes the json parser hook infrastructure and functions
for json_get and friends, plus
On Friday, December 28, 2012, Heikki Linnakangas wrote:
On 28.12.2012 23:53, Peter Eisentraut wrote:
On 12/27/12 1:07 AM, Pavel Stehule wrote:
Hello
I rechecked performance of dynamic SQL and it is significantly slower
in 9.2 than 9.1
-- 9.1
postgres=# create or replace function test()
Jeff Janes jeff.ja...@gmail.com writes:
Using a RULE-based partitioning instead with row by row insertion, the
plancache changes slowed it down by 300%, and this patch doesn't change
that. But that seems to be down to the insertion getting planned
repeatedly, because it decides the custom
On Sat, Dec 29, 2012 at 10:26 AM, Andres Freund and...@2ndquadrant.com wrote:
A shared table for event triggers sounds like it would be the far easier
solution (9.4+ that is).
The problem is that the event trigger table is a just a pointer to a
function, and there's no procedure OID to store in
On Wed, Dec 26, 2012 at 11:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This has been debated, and rejected, before.
To mention just one problem, are we going to add nonstandard,
non-backwards-compatible syntax to every single kind of CREATE to allow
pg_dump to preserve the creation dates?
* Robert Haas (robertmh...@gmail.com) wrote:
On Sat, Dec 29, 2012 at 10:26 AM, Andres Freund and...@2ndquadrant.com
wrote:
A shared table for event triggers sounds like it would be the far easier
solution (9.4+ that is).
The problem is that the event trigger table is a just a pointer to
Robert Haas robertmh...@gmail.com writes:
[ on creation timestamps ]
I know this has been discussed and rejected before, but I find that
rejection to be wrong-headed. I have repeatedly been asked, with
levels of exasperation ranging from mild to homicidal, why we don't
have this feature, and
* Robert Haas (robertmh...@gmail.com) wrote:
Well, IMHO, there is no need for any syntax change at all. CREATE
TABLE and CREATE DATABASE should just record the creation time
somewhere, and that's all. If you dump-and-reload, the creation time
changes. Deal with it, or hack your catalogs if
* Tom Lane (t...@sss.pgh.pa.us) wrote:
If I believed that it would be a hundred-line patch, and would *stay*
a hundred-line patch, I'd be fine with it. But it won't. I will
bet a very fine dinner that the feature wouldn't get out the door
before there would be demands for pg_dump support.
On Windows, src/pl/plpython/Makefile has a rule whose target line expands to
something like python33.def: C:/Windows/system32/python33.dll. When doing a
MinGW build with Cygwin's make-3.81, that line elicits an error:
Makefile:69: *** target pattern contains no `%'. Stop.
Seeing a second
On 01/03/2013 11:13 AM, Noah Misch wrote:
On Windows, src/pl/plpython/Makefile has a rule whose target line expands to
something like python33.def: C:/Windows/system32/python33.dll. When doing a
MinGW build with Cygwin's make-3.81, that line elicits an error:
Shouldn't you generally be using
On Wed, Jan 2, 2013 at 9:12 PM, Stephen Frost sfr...@snowman.net wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
If I believed that it would be a hundred-line patch, and would *stay*
a hundred-line patch, I'd be fine with it. But it won't. I will
bet a very fine dinner that the feature
On Thu, Jan 03, 2013 at 11:52:58AM +0800, Craig Ringer wrote:
On 01/03/2013 11:13 AM, Noah Misch wrote:
On Windows, src/pl/plpython/Makefile has a rule whose target line expands to
something like python33.def: C:/Windows/system32/python33.dll. When
doing a
MinGW build with Cygwin's
* Robert Haas robertmh...@gmail.com wrote:
I know this has been discussed and rejected before, but I find that
rejection to be wrong-headed. I have repeatedly been asked, with
levels of exasperation ranging from mild to homicidal, why we don't
have this feature, and I have no good answer. If
On 01/02/2013 10:13 PM, Noah Misch wrote:
On Windows, src/pl/plpython/Makefile has a rule whose target line expands to
something like python33.def: C:/Windows/system32/python33.dll. When doing a
MinGW build with Cygwin's make-3.81, that line elicits an error:
Makefile:69: *** target pattern
On 01/02/2013 11:34 PM, Andrew Dunstan wrote:
On 01/02/2013 10:13 PM, Noah Misch wrote:
On Windows, src/pl/plpython/Makefile has a rule whose target line
expands to
something like python33.def: C:/Windows/system32/python33.dll.
When doing a
MinGW build with Cygwin's make-3.81, that line
On Fri, Dec 28, 2012 at 12:24 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2012/12/28 Peter Eisentraut pete...@gmx.net:
On Mon, 2012-12-17 at 16:34 -0500, Peter Eisentraut wrote:
Yes, this would be a good solution for some applications, but the only
way I can think of to manage the
Hello
2013/1/2 Robert Haas robertmh...@gmail.com:
On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I am not sure, but maybe is time to introduce ANSI SQL syntax for
functions' named parameters
It is defined in ANSI SQL 2011
CALL P (B = 1, A = 2)
instead
59 matches
Mail list logo
