Re: [HACKERS] proposal: ANSI SQL 2011 syntax for named parameters

Hello 2013/1/2 Robert Haas : > On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule > 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

Re: [HACKERS] multiple CREATE FUNCTION AS items for PLs

On Fri, Dec 28, 2012 at 12:24 AM, Pavel Stehule wrote: > 2012/12/28 Peter Eisentraut : >> 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 compatibility issue is to invent some

Re: [HACKERS] Problematic dependency in plpython Makefile [Windows]

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 e

Re: [HACKERS] Problematic dependency in plpython Makefile [Windows]

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

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

* Robert Haas 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 it were somehow >

Re: [HACKERS] Problematic dependency in plpython Makefile [Windows]

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 Cyg

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

On Wed, Jan 2, 2013 at 9:12 PM, Stephen Frost 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 wouldn't get out th

Re: [HACKERS] Problematic dependency in plpython Makefile [Windows]

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 usi

[HACKERS] Problematic dependency in plpython Makefile [Windows]

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 colo

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

* 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.

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

* 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

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

Robert Haas 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 I have no good a

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

* Robert Haas (robertmh...@gmail.com) wrote: > On Sat, Dec 29, 2012 at 10:26 AM, Andres Freund > 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, a

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

On Wed, Dec 26, 2012 at 11:13 PM, Tom Lane 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? Another interestin

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

On Sat, Dec 29, 2012 at 10:26 AM, Andres Freund 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 that shared catalog

Re: [HACKERS] dynamic SQL - possible performance regression in 9.2

Jeff Janes 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 plan is cheaper tha

Re: [HACKERS] dynamic SQL - possible performance regression in 9.2

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

PATCH: Split stats file per database WAS: [HACKERS] autovacuum stress-testing our system

Hi, attached is a version of the patch that I believe is ready for the commitfest. As the patch was discussed over a large number of messages, I've prepared a brief summary for those who did not follow the thread. Issue = The patch aims to improve the situation in deployments with many tabl

Re: [HACKERS] json api WIP patch

On 01/02/2013 04:45 PM, Robert Haas wrote: On Wed, Dec 26, 2012 at 3:33 PM, Andrew Dunstan 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, thi

Re: [HACKERS] proposal: ANSI SQL 2011 syntax for named parameters

On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule 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 that, as recen

Re: [HACKERS] multiple CREATE FUNCTION AS items for PLs

On Fri, Dec 28, 2012 at 7:09 AM, Hannu Krosing 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 things if t

Re: [HACKERS] Whats the correct way to change trigdata->tg_relation

On Fri, Dec 28, 2012 at 1:06 PM, Charles Gomes 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 modify trigdata->tg_r

Re: [HACKERS] json api WIP patch

On Wed, Dec 26, 2012 at 3:33 PM, Andrew Dunstan 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 lexer fully for use

Re: [HACKERS] Feature Request: pg_replication_master()

On Wed, Dec 26, 2012 at 3:32 PM, Josh Berkus wrote: >> There already are two ways to promote a server out of recovery. One is >> creating the trigger file. The other is "pg_ctl promote". (it uses a >> trigger file called $PGDATA/promote internally, but that's invisible to >> the user). > > Right,

Re: [HACKERS] [COMMITTERS] pgsql: Unify some tar functionality across different parts

On Wed, Jan 2, 2013 at 5:44 PM, Tom Lane wrote: > Magnus Hagander writes: >> On Wed, Jan 2, 2013 at 5:36 PM, Tom Lane 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

Re: [HACKERS] pg_basebackup from cascading standby after timeline switch

On Wed, Jan 2, 2013 at 1:55 PM, Heikki Linnakangas 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 fix, let's change

Re: [HACKERS] Review of Row Level Security

On Wed, Jan 02, 2013 at 05:31:42PM +, Simon Riggs wrote: > On 2 January 2013 17:19, David Fetter 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 process, wh

Re: [HACKERS] Review of Row Level Security

On 2 January 2013 17:19, David Fetter 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 apply this to the

Re: [HACKERS] Minor fix in 'clean' action of 'src/backend/Makefile'

On Wed, Jan 2, 2013 at 2:23 PM, Heikki Linnakangas wrote: > 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

Re: [HACKERS] Review of Row Level Security

On Wed, Jan 02, 2013 at 05:35:13PM +0100, Kohei KaiGai wrote: > 2012/12/31 Simon Riggs : > > On 23 December 2012 18:49, Simon Riggs 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

Re: [HACKERS] Big disconnect_and_exit cleanup in pg_basebackup

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 annoya

Re: [HACKERS] [COMMITTERS] pgsql: Unify some tar functionality across different parts

Magnus Hagander writes: > On Wed, Jan 2, 2013 at 5:36 PM, Tom Lane 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 globally applicable >> as, say,

Re: [HACKERS] [COMMITTERS] pgsql: Unify some tar functionality across different parts

On Wed, Jan 2, 2013 at 5:36 PM, Tom Lane wrote: > Magnus Hagander writes: >>> On Wed, Jan 2, 2013 at 4:14 AM, Andrew Dunstan 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

Re: [HACKERS] allowing multiple PQclear() calls

2013-01-02 17:22 keltezéssel, Tom Lane írta: Boszormenyi Zoltan 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 ca

Re: [HACKERS] [COMMITTERS] pgsql: Unify some tar functionality across different parts

Magnus Hagander writes: >> On Wed, Jan 2, 2013 at 4:14 AM, Andrew Dunstan 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" on all our > platforms, more

Re: [HACKERS] Review of Row Level Security

2012/12/31 Simon Riggs : > On 23 December 2012 18:49, Simon Riggs 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 actual default is not that important

Re: [HACKERS] allowing multiple PQclear() calls

2013/1/2 Heikki Linnakangas > On 02.01.2013 17:27, Marko Kreen wrote: > >> On Wed, Jan 2, 2013 at 5:11 PM, Boszormenyi Zoltan >> wrote: >> >>> 2012-12-11 16:09 keltezéssel, Simon Riggs írta: >>> >>> On 11 December 2012 12:18, Boszormenyi Zoltan wrote: Such mechanism already exist -

Re: [HACKERS] fix bgworkers in EXEC_BACKEND

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), > +

Re: [HACKERS] Minor fix in 'clean' action of 'src/backend/Makefile'

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

Re: [HACKERS] allowing multiple PQclear() calls

Boszormenyi Zoltan 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 set a

Re: [HACKERS] Minor fix in 'clean' action of 'src/backend/Makefile'

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 i

[HACKERS] Big disconnect_and_exit cleanup in pg_basebackup

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 follow

[HACKERS] Minor fix in 'clean' action of 'src/backend/Makefile'

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: http://br.linkedin.com/in/

Re: [HACKERS] allowing multiple PQclear() calls

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 Zoltan wrote: 2012-12-11 16:09 keltezéssel, Simon Riggs írta: On 11 December 2012 12:18, Boszormenyi Zoltan wrote: Such mechanism already exist - you

Re: [HACKERS] allowing multiple PQclear() calls

2013-01-02 16:27 keltezéssel, Marko Kreen írta: On Wed, Jan 2, 2013 at 5:11 PM, Boszormenyi Zoltan wrote: 2012-12-11 16:09 keltezéssel, Simon Riggs írta: On 11 December 2012 12:18, Boszormenyi Zoltan wrote: Such mechanism already exist - you just need to set your PGresult pointer to NULL a

Re: [HACKERS] allowing multiple PQclear() calls

On 02.01.2013 17:27, Marko Kreen wrote: On Wed, Jan 2, 2013 at 5:11 PM, Boszormenyi Zoltan wrote: 2012-12-11 16:09 keltezéssel, Simon Riggs írta: On 11 December 2012 12:18, Boszormenyi Zoltan wrote: Such mechanism already exist - you just need to set your PGresult pointer to NULL after eac

Re: [HACKERS] recent ALTER whatever .. SET SCHEMA refactoring

2012/12/20 Robert Haas : > 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 table foo set

Re: [HACKERS] ALTER .. OWNER TO error mislabels schema as other object type

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))

Re: [HACKERS] allowing multiple PQclear() calls

On Wed, Jan 2, 2013 at 5:11 PM, Boszormenyi Zoltan wrote: > 2012-12-11 16:09 keltezéssel, Simon Riggs írta: > >> On 11 December 2012 12:18, Boszormenyi Zoltan wrote: >> > Such mechanism already exist - you just need to set > your PGresult pointer to NULL after each PQclear(). So

Re: [HACKERS] allowing multiple PQclear() calls

2012-12-11 16:09 keltezéssel, Simon Riggs írta: On 11 December 2012 12:18, Boszormenyi Zoltan 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 ** not a *. Do y

Re: [HACKERS] default SSL compression (was: libpq compression)

On Wed, Jan 2, 2013 at 10:03 AM, Magnus Hagander 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 compression whereas I

[HACKERS] Adding rewrite rule to QueryRewrite

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:

Re: [HACKERS] default SSL compression (was: libpq compression)

On Wed, Jan 2, 2013 at 3:15 PM, Noah Misch 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 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 a

Re: [HACKERS] default SSL compression (was: libpq compression)

On Wed, Jan 02, 2013 at 02:03:20PM +0100, Magnus Hagander wrote: > On Wed, Jan 2, 2013 at 1:15 AM, Tom Lane 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 means "ALL

Re: [HACKERS] pg_basebackup from cascading standby after timeline switch

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 wrote: Yes, this should be backpatched to 9.2. I came up with the attached. In this patch, if '-X stream' is specified in pg_basebackup, the timeline his

Re: [HACKERS] default SSL compression (was: libpq compression)

On Wed, Jan 2, 2013 at 1:15 AM, Tom Lane wrote: > > Noah Misch 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 wrote: > >>> Do we want to change our ssl_ciphers default to 'DEFAULT'? Currently it > >>> is 'ALL:!AD

[HACKERS] [PATCH] Factor out pg_malloc and friends into port code

2013-01-02 10:12 keltezéssel, Magnus Hagander írta: On Wed, Jan 2, 2013 at 9:59 AM, Boszormenyi Zoltan > wrote: 2013-01-02 01:24 keltezéssel, Tom Lane írta: Boszormenyi Zoltan mailto:z...@cybertec.at>> writes: 2013-01-01 17:18 keltezéssel, Magnu

Re: [HACKERS] [PATCH] Make pg_basebackup configure and start standby [Review]

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 > wrote: 2013-01-02 01:24 keltezéssel, Tom Lane írta: Boszormenyi Zoltan mailto:z...@cybertec.at>>

Re: [HACKERS] [PATCH] Make pg_basebackup configure and start standby [Review]

2013-01-02 10:12 keltezéssel, Magnus Hagander írta: On Wed, Jan 2, 2013 at 9:59 AM, Boszormenyi Zoltan > wrote: 2013-01-02 01:24 keltezéssel, Tom Lane írta: Boszormenyi Zoltan mailto:z...@cybertec.at>> writes: 2013-01-01 17:18 keltezéssel, Magnu

Re: [HACKERS] [PATCH] Make pg_basebackup configure and start standby [Review]

On Wed, Jan 2, 2013 at 9:59 AM, Boszormenyi Zoltan wrote: > 2013-01-02 01:24 keltezéssel, Tom Lane írta: > > Boszormenyi Zoltan 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 th

Re: [HACKERS] [PATCH] Make pg_basebackup configure and start standby [Review]

2013-01-02 01:24 keltezéssel, Tom Lane írta: Boszormenyi Zoltan 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 the consistent look