[HACKERS] Developer vServer going down for maintenance ...

2005-11-26 Thread Marc G. Fournier
On Sunday evening, at approximately 8pm AST, the main developer vServer will be going down in order to do several upgrades. We anticipate the maintenance to take several hours, and will post an announcement as soon as everything is back up and running ... Marc G. Fournier Hub

Re: [HACKERS] SHOW ALL output too wide

2005-11-26 Thread Tom Lane
Bruce Momjian writes: > Dennis Bjorklund wrote: >> My motivation is only for the good of postgresql. If the majority want >> something else then that's what should happen (of course). I'm just >> stating my view, nothing less and nothing more. > I am surprised we have not gotten more comments ab

Re: [HACKERS] gprof SELECT COUNT(*) results

2005-11-26 Thread Tom Lane
Simon Riggs <[EMAIL PROTECTED]> writes: >>> ...and for emphasis: this optimization of SeqScans is not possible with >>> any other database system, so its a big win for PostgreSQL. > Why is it spin to call it a big win? I didn't say it wasn't a big win; it was the first part of the sentence that b

[HACKERS] Windows installation notes

2005-11-26 Thread Greg Sabino Mullane
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Not sure if this is the right place, but win32-hackers seems to be dead. I recently had a chance to install PostgreSQL on Windows, and wanted to share my comments on the experience in the hope of making things better. Overall I was very impressed -

Re: [HACKERS] gprof SELECT COUNT(*) results

2005-11-26 Thread Luke Lonergan
Title: Re: [HACKERS] gprof SELECT COUNT(*) results Nice job Qingqing and Tom! The improved executor / agg performance will likely help BI / data warehouse customers a lot.  I’ll get some DBT-3 results to substantiate as soon as we can. - Luke On 11/26/05 12:13 AM, "Qingqing Zhou" <[EMAIL PRO

Re: [HACKERS] PL/php in pg_pltemplate

2005-11-26 Thread Andrew Dunstan
Peter Eisentraut said: > Andrew Dunstan wrote: >> I'll be curious to see how we are going to have to manage a build >> system like this with buildfarm - it sounds like it will make life >> more complicated, but maybe it will work. Certainly it will make us >> have to use more conditional logic. > >

Re: [HACKERS] PL/php in pg_pltemplate

2005-11-26 Thread Joshua D. Drake
Peter Eisentraut wrote: Joshua D. Drake wrote: Not only that, plphp does not require the building of php. It can link directly to the .so file :) Where do you get that from without having php built first? From all the OS distributors.. On linux: yum/apt install php php-devel :) Joshua D.

Re: [HACKERS] SHOW ALL output too wide

2005-11-26 Thread Bruce Momjian
Dennis Bjorklund wrote: > My motivation is only for the good of postgresql. If the majority want > something else then that's what should happen (of course). I'm just > stating my view, nothing less and nothing more. I am surprised we have not gotten more comments about it. I personally like the

Re: [HACKERS] PL/php in pg_pltemplate

2005-11-26 Thread Alvaro Herrera
Peter Eisentraut wrote: > I'm more concerned about operating system builders, who will, in one > way or another, have to build everything from scratch in a > deterministic order. This is not a problem with the PL/php I'm working on. (It appears to be with the original PL/php -- I haven't checked

Re: [HACKERS] gprof SELECT COUNT(*) results

2005-11-26 Thread Simon Riggs
On Sat, 2005-11-26 at 11:53 -0500, Tom Lane wrote: > Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: > >> ...and for emphasis: this optimization of SeqScans is not possible with > >> any other database system, so its a big win for PostgreSQL. > > > With any other db system? That's a big call.

Re: [HACKERS] gprof SELECT COUNT(*) results

2005-11-26 Thread Tom Lane
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: >> ...and for emphasis: this optimization of SeqScans is not possible with >> any other database system, so its a big win for PostgreSQL. > With any other db system? That's a big call. Why? One could equally well spin it negatively, as "this o

Re: [HACKERS] SHOW ALL output too wide

2005-11-26 Thread Dennis Bjorklund
On Sat, 26 Nov 2005, Bruce Momjian wrote: > See the discussion or really solo request by me for more feedback when > this change was made for 8.1: > > http://archives.postgresql.org/pgsql-patches/2005-06/msg00295.php > > Where were you when I asked? I do not work with postgresql like you

Re: [HACKERS] gprof SELECT COUNT(*) results

2005-11-26 Thread Christopher Kings-Lynne
...and for emphasis: this optimization of SeqScans is not possible with any other database system, so its a big win for PostgreSQL. With any other db system? That's a big call. Why? Not even other MVCC systems? Chris ---(end of broadcast)---

Re: [HACKERS] PL/php in pg_pltemplate

2005-11-26 Thread Peter Eisentraut
Andrew Dunstan wrote: > I'll be curious to see how we are going to have to manage a build > system like this with buildfarm - it sounds like it will make life > more complicated, but maybe it will work. Certainly it will make us > have to use more conditional logic. This should not affect the buil

Re: [HACKERS] SHOW ALL output too wide

2005-11-26 Thread Greg Sabino Mullane
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Well, that's hardly a reason to add something to the client that is > already in the backend. A much more general solution would be to either > add a flag to SHOW ALL to supress the extra column (or one to add it), An even more general solution i

Re: [HACKERS] PL/php in pg_pltemplate

2005-11-26 Thread Alvaro Herrera
Andrew Dunstan wrote: > Joshua D. Drake said: > > > >> The build order would be: > >> > >> 1. postgresql > >> 2. php > >> 3. plphp > >> > >> There is not circular build dependency there. > > > > Not only that, plphp does not require the building of php. It can link > > directly to the .so file :) >

Re: [HACKERS] PL/php in pg_pltemplate

2005-11-26 Thread Alvaro Herrera
Matteo Beccati wrote: > >The only sore point of the PL/php build is that it needs the Apache2 > >module, so it needs to know the path to it. I haven't found a way to do > >this automatically without requiring APXS which I certainly don't want > >to do ... > > Maybe I didn't get the point, but th

Re: [HACKERS] PL/php in pg_pltemplate

2005-11-26 Thread Andrew Dunstan
Joshua D. Drake said: > >> The build order would be: >> >> 1. postgresql >> 2. php >> 3. plphp >> >> There is not circular build dependency there. > > Not only that, plphp does not require the building of php. It can link > directly to the .so file :) > This makes no sense. Where do you get the .

Re: [HACKERS] SHOW ALL output too wide

2005-11-26 Thread Bruce Momjian
Dennis Bjorklund wrote: > On Fri, 25 Nov 2005, Bruce Momjian wrote: > > > > > Is there any use for SHOW except in interactive psql sessions? > > > > There certainly is. Imagine querying for timezone. Also remember that > > pgadmin is a client application that is _not_ psql. > > I should have w

Re: [HACKERS] [WIN32] Quiet install and changing defaults

2005-11-26 Thread Chris Gow
Magnus Hagander wrote: I am attempting to override the default installation directory that the postgres MSI uses. I'm not familiar with MSI, but from what I've read I can specify properties on the command line to change properties in the installer? I've tried a variety of properties

Re: [HACKERS] [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to

2005-11-26 Thread John R Pierce
Bruce Momjian wrote: If someone wants to create a separate web page to track fixes related to CVE number, that is fine. My guess is that most people reading the release notes don't care about the CVE numbers themselves (just that each release has all known security bugs fixed), and most bugs tha

Re: [HACKERS] gprof SELECT COUNT(*) results

2005-11-26 Thread Simon Riggs
On Sat, 2005-11-26 at 03:13 -0500, Qingqing Zhou wrote: > "Tom Lane" <[EMAIL PROTECTED]> wrote > > > > I plan to take a look at it soon. > > > > "Stand corrected"[Merlin]! In-memory "SELECT COUNT(*)" doubles the > performance due to my test. > > - before - > 1.56 s > > - now - > 0.72 s > ...a

Re: [HACKERS] plpython and bytea

2005-11-26 Thread Hannu Krosing
On Mon, 2005-11-21 at 02:11 +0200, Hannu Krosing wrote: > Hi > > It seems that plpython is unable to return bytea string when it contains > NUL bytes: > > hannu=# CREATE OR REPLACE FUNCTION get_bytea_with_nul() RETURNS bytea AS > ' > return ''aa\\0bb'' > ' LANGUAGE plpythonu SECURITY DEFINER; >

Re: [HACKERS] SHOW ALL output too wide

2005-11-26 Thread Martijn van Oosterhout
On Fri, Nov 25, 2005 at 08:25:55PM -0300, Alvaro Herrera wrote: > (I just noticed that Martijn's patch is not about auto-wrapping but > about displaying \n correctly, which is quite different. So while there > may be some common code it certainly is not the same thing.) Auto-wrapping has been con

Re: [HACKERS] PL/php in pg_pltemplate

2005-11-26 Thread Matteo Beccati
Hi, The only sore point of the PL/php build is that it needs the Apache2 module, so it needs to know the path to it. I haven't found a way to do this automatically without requiring APXS which I certainly don't want to do ... Maybe I didn't get the point, but this could be as simple as writin

Re: [HACKERS] PL/php in pg_pltemplate

2005-11-26 Thread Peter Eisentraut
Joshua D. Drake wrote: > Not only that, plphp does not require the building of php. It can > link directly to the .so file :) Where do you get that from without having php built first? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)

Re: [HACKERS] gprof SELECT COUNT(*) results

2005-11-26 Thread Qingqing Zhou
"Tom Lane" <[EMAIL PROTECTED]> wrote > > I plan to take a look at it soon. > "Stand corrected"[Merlin]! In-memory "SELECT COUNT(*)" doubles the performance due to my test. - before - 1.56 s - now - 0.72 s Regards, Qingqing ---(end of broadcast)-