Re: [HACKERS] further explain changes

2010-01-30 Thread Robert Haas
On Sat, Jan 30, 2010 at 12:26 PM, Jaime Casanova wrote: > On Thu, Jan 28, 2010 at 4:18 PM, Robert Haas wrote: >> On Sun, Jan 24, 2010 at 12:30 PM, Tom Lane wrote: >>> Robert Haas writes: On Sun, Jan 24, 2010 at 12:06 AM, Jaime Casanova > why not let it go in ANALYZE, just as the sort i

Re: [HACKERS] ordered aggregates using WITHIN GROUP (was Re: can somebody execute this query on Oracle 11.2g and send result?)

2010-01-30 Thread Hitoshi Harada
2010/1/30 Tom Lane : > "Jonah H. Harris" writes: >>> http://download.oracle.com/docs/cd/E11882_01/server.112/e10592/functions087.htm >>> >>> Defines: >>> >>> *LISTAGG* (measure_expr [, 'delimiter_expr']) >>> *WITHIN GROUP* (order_by_clause) [*OVER* query_partition_clause] > > Hmph.  I don't know w

Re: [HACKERS] development setup and libdir

2010-01-30 Thread Andrew Dunstan
Aidan Van Dyk wrote: * Andrew Dunstan [100130 19:55]: If I am developing, say, a new perl facility, I expect to develop and test using a private installation of perl, and not screw up my system's perl. It's the same with postgres. But, p

Re: [HACKERS] development setup and libdir

2010-01-30 Thread Aidan Van Dyk
* Andrew Dunstan [100130 19:55]: > If I am developing, say, a new > perl facility, I expect to develop and test using a private installation > of perl, and not screw up my system's perl. It's the same with postgres. But, perl was a bad example. If y

Re: [HACKERS] development setup and libdir

2010-01-30 Thread Joshua Tolley
On Sat, Jan 30, 2010 at 04:50:11PM -0700, James William Pye wrote: > That install of PG that you're using will *probably not* have debugging > information. > > Now, granted, you might not need PG with debugging for some problems, but > chances are that you'll come across one (or two or fifty or s

Re: [HACKERS] development setup and libdir

2010-01-30 Thread Ivan Sergio Borgonovo
On Sat, 30 Jan 2010 22:25:32 -0200 Euler Taveira de Oliveira wrote: > Ivan Sergio Borgonovo escreveu: > > That's pretty expensive. > > > Ugh? > > > I mean... I just would like my .so end up with the expected name > > somewhere else. > It's just two command lines [1]. Consider I'm absolutely ne

Re: [HACKERS] Package namespace and Safe init cleanup for plperl UPDATE 3 [PATCH]

2010-01-30 Thread Alex Hunsaker
On Sat, Jan 30, 2010 at 16:16, Tim Bunce wrote: > This is an update to the final plperl patch in the series from me. > > Changes in the original patch: plc_safe_ok.pl seems to loose its CVS $PostgreSQL$ keyword. > - Ensure Safe container opmask is restored even if @EvalInSafe code >  throws an e

Re: [HACKERS] development setup and libdir

2010-01-30 Thread Andrew Dunstan
Ivan Sergio Borgonovo wrote: Now my main concern is making my C code work in a reasonably decent development environment. I hope if I'll ever succeed to take this project to an end before being forced to take care of other stuff, my code or my documented experience will come useful to others.

Re: [HACKERS] development setup and libdir

2010-01-30 Thread Ivan Sergio Borgonovo
On Sat, 30 Jan 2010 18:32:58 -0500 Robert Haas wrote: > On Sat, Jan 30, 2010 at 5:36 PM, Ivan Sergio Borgonovo > wrote: > >> For development purposes you would be far better off building a > >> private version of postgres (with configure --prefix=/path) and > >> using its pgxs to build, install

Re: [HACKERS] development setup and libdir

2010-01-30 Thread Euler Taveira de Oliveira
Ivan Sergio Borgonovo escreveu: > That's pretty expensive. > Ugh? > I mean... I just would like my .so end up with the expected name > somewhere else. It's just two command lines [1]. > Wouldn't it be better if make install could install stuff where I > ask so I could put modules in different pl

Re: [HACKERS] development setup and libdir

2010-01-30 Thread James William Pye
On Jan 30, 2010, at 3:36 PM, Ivan Sergio Borgonovo wrote: >> For development purposes you would be far better off building a >> private version of postgres (with configure --prefix=/path) and >> using its pgxs to build, install and test your module. > > That's pretty expensive. eh: j...@torch[]:

Re: [HACKERS] development setup and libdir

2010-01-30 Thread Robert Haas
On Sat, Jan 30, 2010 at 5:36 PM, Ivan Sergio Borgonovo wrote: >> For development purposes you would be far better off building a >> private version of postgres (with configure --prefix=/path) and >> using its pgxs to build, install and test your module. > > That's pretty expensive. How? I rebuil

Re: [HACKERS] development setup and libdir

2010-01-30 Thread Greg Smith
Ivan Sergio Borgonovo wrote: I'm absolutely aware I can't ask features unless someone is willing to implement them or is paid for... but the easier/cheaper it is to build up a dev/test environment the more people will try to build/test something for postgres. I do all my build/test work on U

[HACKERS] Package namespace and Safe init cleanup for plperl UPDATE 3 [PATCH]

2010-01-30 Thread Tim Bunce
This is an update to the final plperl patch in the series from me. Changes in the original patch: - Moved internal functions out of main:: namespace into PostgreSQL::InServer and PostgreSQL::InServer::safe - Restructured Safe compartment setup code to generalize and separate the data fro

Re: [HACKERS] development setup and libdir

2010-01-30 Thread Ivan Sergio Borgonovo
On Sat, 30 Jan 2010 16:51:44 -0500 Andrew Dunstan wrote: > Ivan Sergio Borgonovo wrote: > > It is becoming a more serious issue than what I thought... > > Debian install everything in > > /usr/lib/postgresql/8.3/lib/ > > -rw-r--r-- 1 root root > > so definitively it would be hard to write there

Re: [HACKERS] development setup and libdir

2010-01-30 Thread Andrew Dunstan
Ivan Sergio Borgonovo wrote: On Sat, 30 Jan 2010 11:06:02 -0500 Tom Lane wrote: Ivan Sergio Borgonovo writes: ... I can't make install (provided it works as expected, I didn't try yet) since I sincerely hope that my user doesn't have write right on whatever is pointed by $libdir.

Re: [HACKERS] mailing list archiver chewing patches

2010-01-30 Thread Matteo Beccati
On 30/01/2010 17:54, Alvaro Herrera wrote: Matteo Beccati wrote: Il 19/01/2010 09:44, Magnus Hagander ha scritto: As long as the templating is separated from the code, it doesn't matter if it's a dedicated templating engine or PHP. The point being, focus on the contents and interface, porting t

Re: [HACKERS] development setup and libdir

2010-01-30 Thread Ivan Sergio Borgonovo
On Sat, 30 Jan 2010 11:06:02 -0500 Tom Lane wrote: > Ivan Sergio Borgonovo writes: > > ... I can't make install (provided it works as expected, I > > didn't try yet) since I sincerely hope that my user doesn't have > > write right on whatever is pointed by $libdir. > > Why not? In order to ins

Re: [HACKERS] mailing list archiver chewing patches

2010-01-30 Thread Joe Conway
On 01/30/2010 01:14 PM, Dimitri Fontaine wrote: > Matteo Beccati writes: >> I've been following the various suggestions. Please take a look at the >> updated archives proof of concept: >> >> http://archives.beccati.org/ > > I like the features a lot, and the only remarks I can think about are > b

Re: [HACKERS] mailing list archiver chewing patches

2010-01-30 Thread Dimitri Fontaine
Matteo Beccati writes: > I've been following the various suggestions. Please take a look at the > updated archives proof of concept: > > http://archives.beccati.org/ I like the features a lot, and the only remarks I can think about are bikeschedding, so I'll let it to the web team when they integ

Re: [HACKERS] Hot Standby and VACUUM FULL

2010-01-30 Thread Simon Riggs
On Sat, 2010-01-30 at 15:17 -0500, Tom Lane wrote: > Simon Riggs writes: > > The last item on my list before close is making VACUUM FULL and Hot > > Standby play nicely together. > > > The options to do this were and still are: > > > (1) Add WAL messages for non-transactional relcache invalidati

Re: [HACKERS] Hot Standby and VACUUM FULL

2010-01-30 Thread Tom Lane
Simon Riggs writes: > The last item on my list before close is making VACUUM FULL and Hot > Standby play nicely together. > The options to do this were and still are: > (1) Add WAL messages for non-transactional relcache invalidations > (2) Allow system relations to be cluster-ed/vacuum full-ed.

[HACKERS] Hot Standby and VACUUM FULL

2010-01-30 Thread Simon Riggs
The last item on my list before close is making VACUUM FULL and Hot Standby play nicely together. The options to do this were and still are: (1) Add WAL messages for non-transactional relcache invalidations (2) Allow system relations to be cluster-ed/vacuum full-ed. (1) was how we did it origin

Re: [HACKERS] Package namespace and Safe init cleanup for plperl [PATCH]

2010-01-30 Thread Tim Bunce
On Sat, Jan 30, 2010 at 11:08:26AM -0700, Alex Hunsaker wrote: > On Sat, Jan 30, 2010 at 07:51, Tim Bunce wrote: > > On Fri, Jan 29, 2010 at 08:07:30PM -0700, Alex Hunsaker wrote: > > > >> Other than those really quite minor questions that are arguably me > >> nitpicking...  It looks great to me.

Re: [HACKERS] Package namespace and Safe init cleanup for plperl [PATCH]

2010-01-30 Thread Alex Hunsaker
On Sat, Jan 30, 2010 at 07:51, Tim Bunce wrote: > On Fri, Jan 29, 2010 at 08:07:30PM -0700, Alex Hunsaker wrote: >> A couple of comments. *note* I have not tested this as a whole yet >> (due to rejects). >> >> in plc_perboot.pl >> +$funcsrc .= qq[ package main; undef *{'$name'}; *{'$name'} = sub {

Re: [HACKERS] further explain changes

2010-01-30 Thread Jaime Casanova
On Thu, Jan 28, 2010 at 4:18 PM, Robert Haas wrote: > On Sun, Jan 24, 2010 at 12:30 PM, Tom Lane wrote: >> Robert Haas writes: >>> On Sun, Jan 24, 2010 at 12:06 AM, Jaime Casanova why not let it go in ANALYZE, just as the sort info >> >>> It's kinda long-winded - it adds like 4 extra lines

Re: [HACKERS] mailing list archiver chewing patches

2010-01-30 Thread Alvaro Herrera
Matteo Beccati wrote: > Il 19/01/2010 09:44, Magnus Hagander ha scritto: > >As long as the templating is separated from the code, it doesn't > >matter if it's a dedicated templating engine or PHP. The point being, > >focus on the contents and interface, porting the actual > >HTML-generation is like

Re: [HACKERS] development setup and libdir

2010-01-30 Thread Ivan Sergio Borgonovo
On Sat, 30 Jan 2010 11:06:02 -0500 Tom Lane wrote: > Ivan Sergio Borgonovo writes: > > ... I can't make install (provided it works as expected, I > > didn't try yet) since I sincerely hope that my user doesn't have > > write right on whatever is pointed by $libdir. > > Why not? In order to ins

Re: [HACKERS] PG 9.0 and standard_conforming_strings

2010-01-30 Thread Tom Lane
Euler Taveira de Oliveira writes: > Peter Eisentraut escreveu: >> Maybe the next step should be to leave standard_conforming_strings off >> but make the warning an error. >> > It will break application in the same way as enabling the parameter. Besides > that the parameter should be renamed to es

Re: [HACKERS] mailing list archiver chewing patches

2010-01-30 Thread Matteo Beccati
Il 19/01/2010 09:44, Magnus Hagander ha scritto: As long as the templating is separated from the code, it doesn't matter if it's a dedicated templating engine or PHP. The point being, focus on the contents and interface, porting the actual HTML-generation is likely to be easy compared to that.

Re: [HACKERS] development setup and libdir

2010-01-30 Thread Tom Lane
Ivan Sergio Borgonovo writes: > ... I can't make install (provided it works as expected, I didn't try > yet) since I sincerely hope that my user doesn't have write right on > whatever is pointed by $libdir. Why not? In order to install a C function, you have to be superuser, which means you alre

[HACKERS] Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]

2010-01-30 Thread Tim Bunce
This is an update the fourth of the patches to be split out from the former 'plperl feature patch 1'. Changes in this patch: - Adds plperl.on_trusted_init and plperl.on_untrusted_init GUCs on_trusted_init is PGC_USERSET, on_untrusted_init is PGC_SUSET SPI functions are not available when

Re: [HACKERS] PG 9.0 and standard_conforming_strings

2010-01-30 Thread Euler Taveira de Oliveira
Peter Eisentraut escreveu: > Maybe the next step should be to leave standard_conforming_strings off > but make the warning an error. > It will break application in the same way as enabling the parameter. Besides that the parameter should be renamed to escape_string_*error* to reflect the fact that

Re: [HACKERS] Package namespace and Safe init cleanup for plperl [PATCH]

2010-01-30 Thread Tim Bunce
On Fri, Jan 29, 2010 at 08:07:30PM -0700, Alex Hunsaker wrote: > A couple of comments. *note* I have not tested this as a whole yet > (due to rejects). > > in plc_perboot.pl > +$funcsrc .= qq[ package main; undef *{'$name'}; *{'$name'} = sub { > $BEGIN $prolog $src } ]; > > Any thoughts on using

Re: [HACKERS] New VACUUM FULL

2010-01-30 Thread Heikki Linnakangas
Simon Riggs wrote: > On Wed, 2010-01-06 at 14:41 +0900, Takahiro Itagaki wrote: > >> I just applied the patch with a few additional comments. > > I just realised that this new feature *removes* any clustering that was > previously defined on a table. Hmm, that's an overstatement. If the table wa

[HACKERS] Re: Add on_perl_init and proper destruction to plperl UPDATE v3 [PATCH]

2010-01-30 Thread Tim Bunce
On Fri, Jan 29, 2010 at 09:10:48PM -0500, Andrew Dunstan wrote: > > Tim Bunce wrote: > >This is an updated version of the third of the patches to be > >split out from the former 'plperl feature patch 1'. > > > >It includes changes following discussions with Tom Lane and others. > > > >Changes in t

Re: [HACKERS] New VACUUM FULL

2010-01-30 Thread Simon Riggs
On Wed, 2010-01-06 at 14:41 +0900, Takahiro Itagaki wrote: > I just applied the patch with a few additional comments. I just realised that this new feature *removes* any clustering that was previously defined on a table. Many people would see that as a bug and would say that VACUUM FULL should re

Re: [HACKERS] PG 9.0 and standard_conforming_strings

2010-01-30 Thread Kevin Grittner
Tom Lane wrote: Cédric Villemain wrote: >> Do you mean that turning standard_conforming_string ON may lead to >> error with pg_dump, psql or something else ? > Maybe. We concluded in the April 2009 thread that > standard_conforming_strings = ON had gotten little or no field > testing, Well, we'

Re: [HACKERS] PG 9.0 and standard_conforming_strings

2010-01-30 Thread Cédric Villemain
2010/1/30 Tom Lane : > =?ISO-8859-1?Q?C=E9dric_Villemain?= > writes: >> 2010/1/29 Tom Lane : >>> We would have more than no-time-at-all to test it and fix any breakage. >>> Just to start close to home, do you really trust either psql or pg_dump >>> to be completely free of standard_conforming_str

Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution

2010-01-30 Thread Simon Riggs
On Fri, 2010-01-29 at 14:52 +, Greg Stark wrote: > Can you explain what it does in > more detail so we can understand why it's necessary for a sensible set > of features? I've slimmed down the patch to make it clearer what it does, having committed some refactoring. Problem: Currently when w

[HACKERS] development setup and libdir

2010-01-30 Thread Ivan Sergio Borgonovo
I finally put enough code together and it has some chance it could work. It's time to test it. Now I'm going to test it quite frequently. My code is written and compiled in my ~/. Then it is moved through svn to a test box where it is compiled under another version of postgres, but still it ends u

Re: NaN/Inf fix for ECPG Re: [HACKERS] out-of-scope cursor errors

2010-01-30 Thread Boszormenyi Zoltan
Boszormenyi Zoltan írta: > - different UNIX(-like) platforms write out different strings in printf() > for a double variable storing. NaN. E.g.: Linux: "nan", > Solaris: "NaN", AIX: "NaNQ" > After I sent it and reread my mail, I realized that my fix wouldn't be enough because of the above:

Re: [HACKERS] PG 9.0 and standard_conforming_strings

2010-01-30 Thread Peter Eisentraut
On fre, 2010-01-29 at 16:06 -0500, Bruce Momjian wrote: > The way the docs stand now we hold it over people's heads and issue > warnings that are meaningless if we are never going to change it. Maybe the next step should be to leave standard_conforming_strings off but make the warning an error.