Re: [pgsql-advocacy] [HACKERS] [GENERAL] Postgresql AMD x86-64

2003-07-21 Thread Peter Eisentraut
Bruce Momjian writes:

 The following patch automatically enables 64-bit mode on AMD opteron.
 We already had spinlock support for it, but I added some comments.

This sort of thing belongs into the template file, not directly in
configure.in.

-- 
Peter Eisentraut   [EMAIL PROTECTED]

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [HACKERS] dblink_ora - a first shot on Oracle ...

2003-07-21 Thread Peter Eisentraut
Bruce Momjian writes:

 Joe, I can do the configure detection of the Oracle library needed for
 /contrib.

I have a philosophical problem with putting Oracle detection code into the
PostgreSQL build system.  That way, you create a dependency that Oracle
needs to be installed before you install PostgreSQL, but of course we want
PostgreSQL to be first.  Consider where this will be going.  Soon,
configure will be full with detection code for half a dozen other database
systems.  Perhaps a plug-in architecture for dblink is a better solution.
Or make dblink a separate project.

-- 
Peter Eisentraut   [EMAIL PROTECTED]

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html


Re: [HACKERS] Reinventing the wheel...

2003-07-21 Thread Peter Galbavy
Sean Chittenden wrote:
 To prevent lib naming collisions with machines that have libevent
 installed, I plan on renaming all of the functions from event_* to
 pgevent_*.  libevent also has the appropriate autoconf goo to make
 detection of the right library pretty seamless.  It even supports the
 new Linux interface epoll.

Please don't. For those of us using an OS that has libevent as standard,
this is just pollution and perhaps you should instead look to carry the
portable code in the distribution and build/link to it if the normal
libevent is not available (configure will happily check for you).

Peter


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


[HACKERS] anoncvs problems.

2003-07-21 Thread Kurt Roeckx
When doing cvs update I get:

cvs server: Updating contrib/tsearch2
cvs server: failed to create lock directory for
`/projects/cvsroot/pgsql-server/contrib/tsearch2'
(/projects/cvsroot/pgsql-server/contrib/tsearch2/#cvs.lock):
Permission denied
cvs server: failed to obtain dir lock in repository
`/projects/cvsroot/pgsql-server/contrib/tsearch2'
cvs [server aborted]: read lock failed - giving up



Kurt


---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [HACKERS] anoncvs problems.

2003-07-21 Thread Teodor Sigaev
Mark, you don't set right umask for me, IMHO.

Kurt Roeckx wrote:
When doing cvs update I get:

cvs server: Updating contrib/tsearch2
cvs server: failed to create lock directory for
`/projects/cvsroot/pgsql-server/contrib/tsearch2'
(/projects/cvsroot/pgsql-server/contrib/tsearch2/#cvs.lock):
Permission denied
cvs server: failed to obtain dir lock in repository
`/projects/cvsroot/pgsql-server/contrib/tsearch2'
cvs [server aborted]: read lock failed - giving up


Kurt

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
--
Teodor Sigaev  E-mail: [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] anoncvs problems.

2003-07-21 Thread The Hermit Hacker

check it now, should be fine ...

On Mon, 21 Jul 2003, Kurt Roeckx wrote:

 When doing cvs update I get:

 cvs server: Updating contrib/tsearch2
 cvs server: failed to create lock directory for
 `/projects/cvsroot/pgsql-server/contrib/tsearch2'
 (/projects/cvsroot/pgsql-server/contrib/tsearch2/#cvs.lock):
 Permission denied
 cvs server: failed to obtain dir lock in repository
 `/projects/cvsroot/pgsql-server/contrib/tsearch2'
 cvs [server aborted]: read lock failed - giving up



 Kurt


 ---(end of broadcast)---
 TIP 7: don't forget to increase your free space map settings


Marc G. Fournier   ICQ#7615664   IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED]   secondary: [EMAIL PROTECTED]|postgresql}.org

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] dblink_ora - a first shot on Oracle ...

2003-07-21 Thread Bruce Momjian

Of course, PostgreSQL will still install without the Oracle libraries. 

Of course, if you want dblink to use Oracle libraries, you have to
install the Oracle libraries first, or rerun configure after you install
them and reinstall dblink.

I don't see the problem.

---

Peter Eisentraut wrote:
 Bruce Momjian writes:
 
  Joe, I can do the configure detection of the Oracle library needed for
  /contrib.
 
 I have a philosophical problem with putting Oracle detection code into the
 PostgreSQL build system.  That way, you create a dependency that Oracle
 needs to be installed before you install PostgreSQL, but of course we want
 PostgreSQL to be first.  Consider where this will be going.  Soon,
 configure will be full with detection code for half a dozen other database
 systems.  Perhaps a plug-in architecture for dblink is a better solution.
 Or make dblink a separate project.
 
 -- 
 Peter Eisentraut   [EMAIL PROTECTED]
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [HACKERS] dblink_ora - a first shot on Oracle ...

2003-07-21 Thread Rod Taylor
 I don't see the problem.

How about a (simple!) configure process in the dblink directory only
which detects the various items.


signature.asc
Description: This is a digitally signed message part


Re: [HACKERS] anoncvs problems.

2003-07-21 Thread Tom Lane
Teodor Sigaev [EMAIL PROTECTED] writes:
 Mark, you don't set right umask for me, IMHO.

There seems to be more to it than that: I can do cvs update just fine
from the master server.  So I'd guess that the issue is not with your
own permissions, but with what happens when a new directory is
propagated to the anoncvs slave server.

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] dblink_ora - a first shot on Oracle ...

2003-07-21 Thread Bruce Momjian
Rod Taylor wrote:
-- Start of PGP signed section.
  I don't see the problem.
 
 How about a (simple!) configure process in the dblink directory only
 which detects the various items.

I thought of that but configure seems so confusing that setting up
another on in a contrib directory seemed pretty hard.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [HACKERS] anoncvs problems.

2003-07-21 Thread Kurt Roeckx
On Mon, Jul 21, 2003 at 10:11:38AM -0300, The Hermit Hacker wrote:
 
 check it now, should be fine ...

Works now, thanks.


Kurt


---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [HACKERS] dblink_ora - a first shot on Oracle ...

2003-07-21 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes:
 I don't see the problem.

I tend to agree with Peter: if dblink is going to start depending on
stuff outside Postgres, it ought to be become a separate project,
if only to simplify distribution and configuration issues.

Perhaps it could be split into two parts, a PG-specific part and
a cross-DBMS part?

regards, tom lane

PS: Has anyone looked any further at the SQL-MED standard?  ISTM that's
where we ought to head in the long run.

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [HACKERS] dblink_ora - a first shot on Oracle ...

2003-07-21 Thread Joe Conway
Tom Lane wrote:
I tend to agree with Peter: if dblink is going to start depending on
stuff outside Postgres, it ought to be become a separate project,
if only to simplify distribution and configuration issues.
Perhaps it could be split into two parts, a PG-specific part and
a cross-DBMS part?
			regards, tom lane

PS: Has anyone looked any further at the SQL-MED standard?  ISTM that's
where we ought to head in the long run.
I think for that very reason (SQL-MED) we need to come to terms with 
this issue. If/when connections to external data sources is in the 
backend, you'll have those exact same dependencies. And in fact, we do 
today: consider '--with-openssl' or '--with-tcl'.

I had always assumed we would need '--with-oracle', '--with-jdbc',  etc 
(or whatever you want to call them) to support backend connections to 
external sources. And this discussion is the very reason I was hesitant 
to pursue dblink_ora or jdbclink now, because I didn't think people 
would be comfortable with configure options to support a contrib library.

Joe

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [HACKERS] dblink_ora - a first shot on Oracle ...

2003-07-21 Thread Peter Eisentraut
Joe Conway writes:

 I think for that very reason (SQL-MED) we need to come to terms with
 this issue. If/when connections to external data sources is in the
 backend, you'll have those exact same dependencies.

No, SQL-MED is a framework to plug in different connectors -- exactly what
some are suggesting for dblink.

-- 
Peter Eisentraut   [EMAIL PROTECTED]

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [HACKERS] dblink_ora - a first shot on Oracle ...

2003-07-21 Thread Bruce Momjian
Joe Conway wrote:
  PS: Has anyone looked any further at the SQL-MED standard?  ISTM that's
  where we ought to head in the long run.
 
 I think for that very reason (SQL-MED) we need to come to terms with 
 this issue. If/when connections to external data sources is in the 
 backend, you'll have those exact same dependencies. And in fact, we do 
 today: consider '--with-openssl' or '--with-tcl'.
 
 I had always assumed we would need '--with-oracle', '--with-jdbc',  etc 
 (or whatever you want to call them) to support backend connections to 
 external sources. And this discussion is the very reason I was hesitant 
 to pursue dblink_ora or jdbclink now, because I didn't think people 
 would be comfortable with configure options to support a contrib library.

I know we normally require a configure flag to look for special
capabilities, like ssl, but I thought we could skip that because it was
a /contrib and just look by default, but I now see that people don't
want to take that step.

I thought dblink was too integrated in the backend code to be a separate
project.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html


Re: [HACKERS] dblink_ora - a first shot on Oracle ...

2003-07-21 Thread Thomas Swan
On 7/21/2003 9:16 AM, Tom Lane wrote:

Bruce Momjian [EMAIL PROTECTED] writes:
  

I don't see the problem.



I tend to agree with Peter: if dblink is going to start depending on
stuff outside Postgres, it ought to be become a separate project,
if only to simplify distribution and configuration issues.

The ability to optionally link to another library does not necessitate a
functional dependency on it.

Perhaps it could be split into two parts, a PG-specific part and
a cross-DBMS part?

   regards, tom lane

PS: Has anyone looked any further at the SQL-MED standard?  ISTM that's
where we ought to head in the long run.

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
  




---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [HACKERS] Bad permissions bug in 7.3 dump (and 7.4)?

2003-07-21 Thread Bruce Momjian

Is there a TODO here?

---

Peter Eisentraut wrote:
 On Mon, 14 Jul 2003, Tom Lane wrote:
 
  Probably the only real solution is to implement DROP-CASCADE-like
  checking when a privilege is revoked.  Seems like rather a lot of
  work :-(
 
 Yes and yes.  That's why the SQL standard goes on for pages and pages
 about REVOKE.  It will be looked at eventually, just make sure someone is
 taking notes on the failure cases.
 
 -- 
 Peter Eisentraut   [EMAIL PROTECTED]
 
 ---(end of broadcast)---
 TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [HACKERS] dblink_ora - a first shot on Oracle ...

2003-07-21 Thread Bruce Momjian

Hans, I am a little confused about what you are suggesting.  Are you
suggesting flag to the make of the contrib module rather than configure
tests?

I agree this is a killer feature for many people and would like to have
it in 7.4.

---

Hans-Jürgen Schönig wrote:
  I think for that very reason (SQL-MED) we need to come to terms with 
  this issue. If/when connections to external data sources is in the 
  backend, you'll have those exact same dependencies. And in fact, we do 
  today: consider '--with-openssl' or '--with-tcl'.
  
  I had always assumed we would need '--with-oracle', '--with-jdbc',  etc 
  (or whatever you want to call them) to support backend connections to 
  external sources. And this discussion is the very reason I was hesitant 
  to pursue dblink_ora or jdbclink now, because I didn't think people 
  would be comfortable with configure options to support a contrib library.
  
  Joe
 
 If dblink was a core module I would say that adding the configure stuff 
 would be very natural. Since this is contrib stuff I was not that sure 
 about configure anymore. We will need additional flags for external data 
 sources in the (hopefully) near future so I think we should add it.
 
 Personally I tend to think about a solution like that. dblink has a 
 great future and many people simply love it (I cannot think of a 
 customer who does not like it - it is a killer feature):
 
 - implement the concepts proposed by Joe on this list yesterday (I am 
 talking about the functions dblink should provide)
 - add support to configure
 - merge dblink with dblink_ora as soon as the changes are ready
 - adapt jdbc_link and merge it with dblink
 - implement dblink_db2, dblink_csv, dblink_xml, and maybe some others
 - leave it in contrib because this way it will be shipped with the core 
 distribution and people will use it more frequently
 
 I hope that I will finish the Oracle stuff (named connections, ...) 
 within the next 3 days.
 
   Regards,
 
   Hans
 
 
 -- 
 Cybertec Geschwinde u Schoenig
 Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
 Tel: +43/2952/30706; +43/664/233 90 75
 www.cybertec.at, www.postgresql.at, kernel.cybertec.at
 
 
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] Why are triggers semi-deferred?

2003-07-21 Thread Bruce Momjian

Added to TODO:

* Have AFTER triggers execute after the appropriate SQL statement in a
  function, not at the end of the function


---

Philip Warner wrote:
 At 11:51 PM 1/06/2003 -0400, Bruce Momjian wrote:
 Does anyone have answers for these?  I read the thread and don't 100%
 understand it all.
 
 My belief is that at least ROW triggers need fixing (7.3 doesn't have 
 statement, not sure about 7.4).
 
 Currently, if you write a plpgsql procedure which calls more than one 
 insert/update/delete statements, the AFTER triggers for all of these 
 statements will not fire until after the procedure exits. They should fire 
 either just after each row is updated, or just after the most immediately 
 enclosing statement executes. I think the thread wanted the latter.
 
 So, if we have a table with two rows, and a BEFORE and AFTER trigger, and a 
 plpgsql procedure that updates all rows twice, then we should have:
 
 procedure called
procedure executes first update
  before trigger fires(row 1)
  before trigger fires(row 2)
 row 1 updated
 row 2 updated
  after trigger fires(row 1)
  after trigger fires(row 2)
procedure executes second update
  before trigger fires(row 1)
  before trigger fires(row 2)
 row 1 updated
 row 2 updated
  after trigger fires(row 1)
  after trigger fires(row 2)
 procedure exits
 
 What we have in 7.3 is:
 
 procedure called
procedure executes first update
  before trigger fires(row 1)
  before trigger fires(row 2)
 row 1 updated
 row 2 updated
procedure executes second update
  before trigger fires(row 1)
  before trigger fires(row 2)
 row 1 updated
 row 2 updated
 procedure exits
 after trigger fires(row 1)
 after trigger fires(row 2)
 after trigger fires(row 1)
 after trigger fires(row 2)
 
 IIRC, the thread did not really discuss whether do intersperse the BEFORE 
 executions with the updates, but doing them all before seems consistent.
 
 Apologies is this has been covered elsewhere...
 
 
 
 
 
 
 
 
 
 Philip Warner| __---_
 Albatross Consulting Pty. Ltd.   |/   -  \
 (A.B.N. 75 008 659 498)  |  /(@)   __---_
 Tel: (+61) 0500 83 82 81 | _  \
 Fax: (+61) 03 5330 3172  | ___ |
 Http://www.rhyme.com.au  |/   \|
   |----
 PGP key available upon request,  |  /
 and from pgp5.ai.mit.edu:11371   |/
 
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [HACKERS] php with postgres

2003-07-21 Thread Bruce Momjian

Added to TODO:

o Add PL/PHP (Joe, Jan)


---

Joe Conway wrote:
 Jan Wieck wrote:
  I had been briefly talking with Marcus Boerger (included in CC) from the 
  PHP team about it. He knows the PHP5 SAPI embed well. Can you include 
  him into the team (if not already)?
 
 Sure!
 
   From what I know about this SAPI I think the PL/Tcl implementation 
  would be a good point to start from, as it looks very similar with 
  respect to the possibilities.
 
 I was going to start from PL/R, which is a descendent of PL/Tcl -- 
 reason being, in PL/R I've already got SRF/table-function support and 
 polymorphic argument/return-type support working. Also, I've done a fair 
 amount of work to preserve arrays and composite types as they move 
 back-and-forth.
 
 My plan is to add a few missing things to PL/R over the next couple (or 
 so) weeks, and then start PL/PHP from that:
 1) Cache lookup based on function oid and argument signature ala the
 patch I recently sent in (and improved by Tom) for PL/pgSQL -- this
 is needed to properly support polymorphic arguments.
 2) Trigger support -- just haven't needed this so far, but we'll want it
 in PL/PHP, so I may as well add it to PL/R too.
 3) Re-add nested error handling -- I removed this from PL/R early on
 just to simplify life. Should be easy to drop back in.
 
 I've read some examples posted regarding the PHP embed SAPI, and it 
 looks very similar to the R interpreter also. It should be fairly easy 
 to drop the PHP embed calls in for the libR calls. The bulk of the work 
 will be in modifying the data conversion functions that map Postgres 
 composite types and arrays to similar structures in PHP.
 
 Help on the PHP side of things would be most appreciated, because that's 
 the part I'm least familiar with.
 
 Joe
 
 
 ---(end of broadcast)---
 TIP 6: Have you searched our list archives?
 
http://archives.postgresql.org
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html


Re: [HACKERS] php with postgres

2003-07-21 Thread Bruce Momjian

Glad you got in touch with the right guys.  Joe and Jan have both talked
about doing PlPHP for a while.

Marcus, would you check if PHP is using RESET ALL when passing
persistent connection to new clients?  We added that capability a few
releases ago, specifically for PHP persistent connections, but I don't
think that ever got into the PHP code.

---

Marcus B?rger wrote:
 Hello ivan,
 
 Sunday, July 13, 2003, 10:12:43 PM, you wrote:
 
 
 i what aoubt stream ?
 i in plpgsql you can just write command INSERT ... or DELETE
 i if you want sht like this in php you need to correct zend i think .
 i in php all var is declared as variant type but we need look at realy type.
 
 In php we only have a few base types (int, float, bool, string) and some more
 complex types like array and objects. The general idea is that at least the
 base types can be converted without notice. This might be a problem when
 integrating php into postgres but i guess everything can be solved the php
 way. Since i also have zend commit rights i could fix things in this manner as
 long as the language itself doesn't change in any way.
 
 i I have other view, to first write php interpreter to postgres, and then
 i write a translator, which translate plphp code to C code . I cound be only
 i a another way, to remember about speed (compiled code is always faster
 i then src ) . Php source will be to testing, and to relese will be option
 i to translate this src to C src and then compile it.
 
 The general idea should be to leave php as is. That is, it is an interpreter.
 During LT we were again able to speed it up very much. So performance
 difference from interpreter to a real php to c compiler shouldn't be a problem
 for the moment.
 Also i thing when someone consideres using php inside his database he a) does
 it because he doesn't know any other language or b) he uses very advanced
 language features. In both cases the performance problem is no issue.
 Additionally there are already tokenizers out which remove the
 compile step. So atm we only can't get rid of the interpreter overhead.
 
 Best regards,
  Marcusmailto:[EMAIL PROTECTED]
 
 
 ---(end of broadcast)---
 TIP 3: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [HACKERS] vacuumdb can't be canceled

2003-07-21 Thread Bruce Momjian

Sorry, my testing was on CVS version of PostgreSQL.

---

Kenji Sugita wrote:
 Vacuumdb command can't be canceled by Control-C and VACUUM is still running.
 When wrong database name is specified to vacuumdb, cancellation is required to
 stop VACUUM FULL which runs long.
 
 Option -c of psql forget to set signal handler for 7.3 or prior. Vacuumdb
 have no signal handler of cancellation for 7.4devel.
 
 
 Kenji Sugita  
 
 
 ---(end of broadcast)---
 TIP 5: Have you checked our extensive FAQ?
 
http://www.postgresql.org/docs/faqs/FAQ.html
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] vacuumdb can't be canceled

2003-07-21 Thread Bruce Momjian

Control-C works here.  What platform are you on?  Can you reproduce it?

I just tried:

psql -c 'select * from pg_class, pg_proc' test

and control-C terminated the query.

---

Kenji Sugita wrote:
 Vacuumdb command can't be canceled by Control-C and VACUUM is still running.
 When wrong database name is specified to vacuumdb, cancellation is required to
 stop VACUUM FULL which runs long.
 
 Option -c of psql forget to set signal handler for 7.3 or prior. Vacuumdb
 have no signal handler of cancellation for 7.4devel.
 
 
 Kenji Sugita  
 
 
 ---(end of broadcast)---
 TIP 5: Have you checked our extensive FAQ?
 
http://www.postgresql.org/docs/faqs/FAQ.html
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] php with postgres

2003-07-21 Thread Bruce Momjian
Marcus B?rger wrote:
 BM Marcus, would you check if PHP is using RESET ALL when passing
 BM persistent connection to new clients?  We added that capability a few
 BM releases ago, specifically for PHP persistent connections, but I don't
 BM think that ever got into the PHP code.
 
 Unfortunately we don't do so yet. Do i need to check for errors or can i do it
 unconditionally on conenction start? And i'd need to know how to check if it
 is available (like starting with which version).

It first appeared in PostgreSQL version 7.2.  It doesn't generate any
failures.  It just resets all SET settting to their defaults, in case
the previous client modified them.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [HACKERS] did you read my mails ?

2003-07-21 Thread Bruce Momjian

What functions are they?

---

ivan wrote:
 
 someone looked at my files function ??
 
 
 
 ---(end of broadcast)---
 TIP 7: don't forget to increase your free space map settings
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


[HACKERS] tsearch2 for 7.3.X

2003-07-21 Thread Oleg Bartunov
Hi there,

seems we'll have 7.3.4 release. Is't worth to submit new tsearch2
module for this release ? People could play with new module
without waiting 7.4 release.

Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [HACKERS] tsearch2 for 7.3.X

2003-07-21 Thread Bruce Momjian

We don't normally issue new features in minor releases, but for a
/contrib, we could consider it.

---

Oleg Bartunov wrote:
 Hi there,
 
 seems we'll have 7.3.4 release. Is't worth to submit new tsearch2
 module for this release ? People could play with new module
 without waiting 7.4 release.
 
   Regards,
   Oleg
 _
 Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
 Sternberg Astronomical Institute, Moscow University (Russia)
 Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
 phone: +007(095)939-16-83, +007(095)939-23-83
 
 ---(end of broadcast)---
 TIP 4: Don't 'kill -9' the postmaster
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [HACKERS] [GENERAL] Backwards index scan

2003-07-21 Thread Bruce Momjian

Is this a TODO?

---

Tom Lane wrote:
 [ reply redirected to a more appropriate list ]
 
 Dmitry Tkach [EMAIL PROTECTED] writes:
  I am not sure if this is really a bug, but it certainly looks like one 
  to me...
 
 It's not a bug, but I agree that _bt_first can be inefficient if there
 are lots of matching keys.
 
  This is because there are *lots* (a few million) of matches for x=10, 
  and _bt_first () scans through them *all* sequentually to get to the 
  last one.
  I understand that with the generic approach to operators in postgres it 
  is, probably, not very feasible to try and teach _bt_first () to handle 
  this situation automatically (it would need to know how to get 
  next/previous value for every indexable type)...
 
 I think what we'd want is variant versions of _bt_search and _bt_binsrch
 that locate the first entry greater than the specified target key,
 rather than the first entry greater than or equal to it.  Given such
 positioning, all the _bt_first cases that involve stepping over more
 than one entry could be improved to require no more than one step.
 
 Not sure whether it'd be better to make clone versions of these
 functions, or to add a parameter to tell them which behavior is wanted.
 
   regards, tom lane
 
 ---(end of broadcast)---
 TIP 6: Have you searched our list archives?
 
http://archives.postgresql.org
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [HACKERS] tsearch2 for 7.3.X

2003-07-21 Thread Andreas Joseph Krogh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Monday 21 July 2003 22:46, Bruce Momjian wrote:
 We don't normally issue new features in minor releases, but for a
 /contrib, we could consider it.

 ---

 Oleg Bartunov wrote:
  Hi there,
 
  seems we'll have 7.3.4 release. Is't worth to submit new tsearch2
  module for this release ? People could play with new module
  without waiting 7.4 release.

FWIW: I would very much appreciate a tsearch2 for 7.3 for testing without 
having to upgrade my db's to 7.4. One question tho, is it ready for 
production? It's the ranking support which I'm looking forward to.

- -- 
Andreas Joseph Krogh [EMAIL PROTECTED]
gpg public_key: http://dev.officenet.no/~andreak/public_key.asc

- - When there is no content, there is no crap.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/HFYtUopImDh2gfQRAvj8AJ90UoHrSfumA0C4wUhkzh7bzfEN0gCfVsri
NFWJfB/6ILRA6RsbMPUdcTQ=
=HvZQ
-END PGP SIGNATURE-

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [HACKERS] php with postgres

2003-07-21 Thread Bruce Momjian
Marcus B?rger wrote:
 Hello Bruce,
 
 Monday, July 21, 2003, 9:37:08 PM, you wrote:
 
 BM Marcus B?rger wrote:
  BM Marcus, would you check if PHP is using RESET ALL when passing
  BM persistent connection to new clients?  We added that capability a few
  BM releases ago, specifically for PHP persistent connections, but I don't
  BM think that ever got into the PHP code.
  
  Unfortunately we don't do so yet. Do i need to check for errors or can i do it
  unconditionally on conenction start? And i'd need to know how to check if it
  is available (like starting with which version).
 
 BM It first appeared in PostgreSQL version 7.2.  It doesn't generate any
 BM failures.  It just resets all SET settting to their defaults, in case
 BM the previous client modified them.
 
 
 Committed for PHP 5.0 if there is a version 4.4 or 4.5 i'll commit the patch
 for that version, too. Now we need someone with a big site to test whether it
 brings any new problems. If there aren't problems i could probably also commit

I think Theis originally complained about it, perhaps two years ago.

 to PHP 4.3.3. Btw. i don't do RESET ALL when creating the link because that
 shouldn't be necessary.

Right.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [HACKERS] duplicate define in elog.h

2003-07-21 Thread Bruce Momjian
Tom Lane wrote:
 Joe Conway [EMAIL PROTECTED] writes:
  I was looking through elog.h and noticed this at about line 36:
  #define ERROR   20  /* user error - abort transaction; return
   * to known state */
  #define ERROR   20  /* user error - abort transaction; return
   * to known state */
 
 Good catch.  Looks like it snuck in here:
 http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/utils/elog.h.diff?r1=1.41r2=1.42

Man, I am unsafe with a command prompt.  :-)

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [HACKERS] did you read my mails ?

2003-07-21 Thread ivan

functions to open,read,write etc files

On Mon, 21 Jul 2003, Bruce Momjian wrote:


 What functions are they?

 ---

 ivan wrote:
 
  someone looked at my files function ??
 
 
 
  ---(end of broadcast)---
  TIP 7: don't forget to increase your free space map settings
 

 --
   Bruce Momjian|  http://candle.pha.pa.us
   [EMAIL PROTECTED]   |  (610) 359-1001
   +  If your life is a hard drive, |  13 Roberts Road
   +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

 ---(end of broadcast)---
 TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [HACKERS] did you read my mails ?

2003-07-21 Thread Bruce Momjian

I haven't seen those myself.

---

ivan wrote:
 
 functions to open,read,write etc files
 
 On Mon, 21 Jul 2003, Bruce Momjian wrote:
 
 
  What functions are they?
 
  ---
 
  ivan wrote:
  
   someone looked at my files function ??
  
  
  
   ---(end of broadcast)---
   TIP 7: don't forget to increase your free space map settings
  
 
  --
Bruce Momjian|  http://candle.pha.pa.us
[EMAIL PROTECTED]   |  (610) 359-1001
+  If your life is a hard drive, |  13 Roberts Road
+  Christ can be your backup.|  Newtown Square, Pennsylvania 19073
 
  ---(end of broadcast)---
  TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
 
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [HACKERS] tsearch2 for 7.3.X

2003-07-21 Thread Oleg Bartunov
On Mon, 21 Jul 2003, Andreas Joseph Krogh wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On Monday 21 July 2003 22:46, Bruce Momjian wrote:
  We don't normally issue new features in minor releases, but for a
  /contrib, we could consider it.
 
  ---
 
  Oleg Bartunov wrote:
   Hi there,
  
   seems we'll have 7.3.4 release. Is't worth to submit new tsearch2
   module for this release ? People could play with new module
   without waiting 7.4 release.

 FWIW: I would very much appreciate a tsearch2 for 7.3 for testing without
 having to upgrade my db's to 7.4. One question tho, is it ready for
 production? It's the ranking support which I'm looking forward to.

I think it's production quality. Actually, we use it in our
projects with 7.3.3. You may read docs on tsearch2 home page
http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/


 - --
 Andreas Joseph Krogh [EMAIL PROTECTED]
 gpg public_key: http://dev.officenet.no/~andreak/public_key.asc

 - - When there is no content, there is no crap.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.0.7 (GNU/Linux)

 iD8DBQE/HFYtUopImDh2gfQRAvj8AJ90UoHrSfumA0C4wUhkzh7bzfEN0gCfVsri
 NFWJfB/6ILRA6RsbMPUdcTQ=
 =HvZQ
 -END PGP SIGNATURE-


Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [HACKERS] did you read my mails ?

2003-07-21 Thread Richard Hall
File IO, now that's something I would like to see. I will need that REAL SOON NOW.

RIck


Bruce Momjian wrote:

 I haven't seen those myself.

 ---

 ivan wrote:
 
  functions to open,read,write etc files
 
  On Mon, 21 Jul 2003, Bruce Momjian wrote:
 
  
   What functions are they?
  
   ---
  
   ivan wrote:
   
someone looked at my files function ??
   
   
   
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
   
  
   --
 Bruce Momjian|  http://candle.pha.pa.us
 [EMAIL PROTECTED]   |  (610) 359-1001
 +  If your life is a hard drive, |  13 Roberts Road
 +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073
  
   ---(end of broadcast)---
   TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
  
 

 --
   Bruce Momjian|  http://candle.pha.pa.us
   [EMAIL PROTECTED]   |  (610) 359-1001
   +  If your life is a hard drive, |  13 Roberts Road
   +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

 ---(end of broadcast)---
 TIP 2: you can get off all lists at once with the unregister command
 (send unregister YourEmailAddressHere to [EMAIL PROTECTED])


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html


Re: [HACKERS] Criteria for contrib/ versus gborg?

2003-07-21 Thread Bruce Momjian
[EMAIL PROTECTED] wrote:
 
  - allows us to say that PostgreSQL ships with field-tested
replication in the source tree
 
 
 We have a winner! I think this one trumps all the rest.

Can we say field-tested and Java in the same sentence?

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [HACKERS] php with postgres

2003-07-21 Thread Edin Kadribasic
 Help on the PHP side of things would be most appreciated, because that's
 the part I'm least familiar with.

SAPI/Embed in PHP is very experimental which means that it can be molded to
suit PL/PHP needs. To my knowlege its only used as a plugin for irssi (irc
client which you can script using PHP), and a very poorly implemented MySQL
module.

Anyway if you need any help with it just shout :)

Edin



---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] pgsql-server/src/backend/commands comment.c

2003-07-21 Thread Bruce Momjian

Added to TODO:

* Prevent COMMENT ON DATABASE from using a database name


---

Rod Taylor wrote:
-- Start of PGP signed section.
  For COMMENT ON DATABASE where database name is unknown or not the current
  database, emit a WARNING and do nothing, rather than raising ERROR.
  Per recent discussion in which we concluded this is the best way to deal
  with database dumps that are reloaded into a database of a new name.
 
 Please add a TODO note about allowing COMMENT ON DATABASE to function
 without providing a database name at all.
-- End of PGP section, PGP failed!

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html


Re: [HACKERS] Another TODO for PL/pgSQL -- Dynamic colums

2003-07-21 Thread Bruce Momjian

Added to TODO:

o Allow PL/pgSQL to name columns by ordinal position, e.g. rec.(3)


---

Josh Berkus wrote:
 Developers,
 
 While I realize that we already have a number of TODOs on the list for 
 PL/pgSQL which nobody is working on, I'd like to propose one more.  That way, 
 when someday somebody takes this on, they'll have a full list of feature 
 requests.
 
 This one gets requested about once per month on the SQL list:
 
 -- Allow naming of columns by ordinal position in PL/pgSQL, 
   e.g. some_rec.(3) or NEW.(3)
 
 -- 
 Josh Berkus
 Aglio Database Solutions
 San Francisco
 
 ---(end of broadcast)---
 TIP 4: Don't 'kill -9' the postmaster
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [HACKERS] SELECT FOR UPDATE NOWAIT

2003-07-21 Thread Bruce Momjian
Rod Taylor wrote:
-- Start of PGP signed section.
 On Fri, 2003-07-18 at 19:46, Paulo Scardine wrote:
  My boss is asking for something like Oracle's SELECT FOR UPDATE NOWAIT.
  
  Is there any such feature? If no, should I look forward into implementing
  this? Any advice?
 
 Lookup STATEMENT_TIMEOUT and set it to a very short time.

Some people have said they want to distinguish between a slow query
(busy system) and waiting on a lock.  I can particulary see wanting to
do a NOWAIT only on exclusive locks --- not sure how many really want
that, though.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] php with postgres

2003-07-21 Thread Jan Wieck
Bruce Momjian wrote:
Marcus B?rger wrote:
BM Marcus, would you check if PHP is using RESET ALL when passing
BM persistent connection to new clients?  We added that capability a few
BM releases ago, specifically for PHP persistent connections, but I don't
BM think that ever got into the PHP code.
Unfortunately we don't do so yet. Do i need to check for errors or can i do it
unconditionally on conenction start? And i'd need to know how to check if it
is available (like starting with which version).
It first appeared in PostgreSQL version 7.2.  It doesn't generate any
failures.  It just resets all SET settting to their defaults, in case
the previous client modified them.
It does generate the usual error if the current transaction block is in 
ABORT state. So the correct querystring to send would be something like

ROLLBACK; RESET ALL

Jan

--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.  #
#== [EMAIL PROTECTED] #
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html


Re: [HACKERS] php with postgres

2003-07-21 Thread Bruce Momjian
Jan Wieck wrote:
 Bruce Momjian wrote:
  Marcus B?rger wrote:
  BM Marcus, would you check if PHP is using RESET ALL when passing
  BM persistent connection to new clients?  We added that capability a few
  BM releases ago, specifically for PHP persistent connections, but I don't
  BM think that ever got into the PHP code.
  
  Unfortunately we don't do so yet. Do i need to check for errors or can i do it
  unconditionally on conenction start? And i'd need to know how to check if it
  is available (like starting with which version).
  
  It first appeared in PostgreSQL version 7.2.  It doesn't generate any
  failures.  It just resets all SET settting to their defaults, in case
  the previous client modified them.
  
 
 It does generate the usual error if the current transaction block is in 
 ABORT state. So the correct querystring to send would be something like
 
  ROLLBACK; RESET ALL

Oh, I remember that now as part of the persistent connection code.  As I
remember, we told them to do BEGIN;COMMIT; to clear any open transaction
state passed to the new client.  Is that in there?  If not, it has to be
added too.  ROLLBACK will generate an error if you are not in a
transaction, so it would fill the logs with errors.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [pgsql-advocacy] [HACKERS] [GENERAL] Postgresql AMD x86-64

2003-07-21 Thread Bruce Momjian
Peter Eisentraut wrote:
 Bruce Momjian writes:
 
  The following patch automatically enables 64-bit mode on AMD opteron.
  We already had spinlock support for it, but I added some comments.
 
 This sort of thing belongs into the template file, not directly in
 configure.in.

I knew you were going to say that, but which template file?  It is a
product of the cpu/compiler, not a specific OS.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


[HACKERS] [Fwd: Re: Interesting thought....]

2003-07-21 Thread Justin Clift
Hi guys,

Wasn't sure if this is a valid idea, but Bruce's response made me think it was worth forwarding here to see if anyone had/has considered it before.

As everyone is aware, I'm not up for coding it, but am mentioning it Just In Case it's deemed worthy of adding to the TODO list in case someone wants to pick up.

:-)

Regards and best wishes,

Justin Clift

 Original Message 
Subject: Re: Interesting thought
Date: Mon, 21 Jul 2003 14:13:49 -0400 (EDT)
From: Bruce Momjian [EMAIL PROTECTED]
To: Justin Clift [EMAIL PROTECTED]
This would fix all our inheritance problems, and allow sequences to span
multiple tables with an index constraint
---

Justin Clift wrote:
Hi Bruce,

Here's an interesting thought

Multi-table indexes... like multi-column, but instead of specifying columns in one table, they specify columns in several tables.

That leads into thoughts about multi-table primary and secondary keys and multi-table foreign keys too.

Wonder if it'd be useful in the real world?  I reckon so.

:-)

Regards and best wishes,

Justin Clift


--
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
 subscribe-nomail command to [EMAIL PROTECTED] so that your
 message can get through to the mailing list cleanly


Re: [HACKERS] [GENERAL] LinkServer

2003-07-21 Thread Bruce Momjian

Here is someone looking for dblink with Oracle capability.  It is not in
CVS yet, but we are trying to get it for 7.4.  You might be able to run
/contrib/dblink from CVS in a few weeks without waiting for a 7.4 release.

---

Richard Huxton wrote:
 On Tuesday 08 Jul 2003 7:58 am, Shridhar Daithankar wrote:
  On 8 Jul 2003 at 12:03, Madhavi Daroor wrote:
   Hi All,
  
   How do I link a postgres server and an Oracle server and get the data
   from an Oracle sever from a Postgres server? I'm using Postgres 7.2.3 on
   Red Hat linux 7.2
  
   Does postgres have any function to do so? And what other configuration
   changes are need to achieve this?
 
  Well no. There is nothing out of box that would help here.
 
 But I did see mention of a dblink for oracle a week or two ago. The dblink 
 package is in contrib and I'd suggest a search of the archives for dblink 
 and oracle.
 
 -- 
   Richard Huxton
 
 ---(end of broadcast)---
 TIP 8: explain analyze is your friend
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [HACKERS] php with postgres

2003-07-21 Thread Joe Conway
Edin Kadribasic wrote:
Help on the PHP side of things would be most appreciated, because that's
the part I'm least familiar with.


SAPI/Embed in PHP is very experimental which means that it can be molded to
suit PL/PHP needs. To my knowlege its only used as a plugin for irssi (irc
client which you can script using PHP), and a very poorly implemented MySQL
module.
Anyway if you need any help with it just shout :)

Great! I'm likely to take you up on that before it's over ;-)

It will probably be a few more weeks before I can get started on this, 
but it's definitely on my short list.

Joe



---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [HACKERS] tsearch2 for 7.3.X

2003-07-21 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes:
 We don't normally issue new features in minor releases, but for a
 /contrib, we could consider it.

I can't see sticking code that hasn't been through any public beta
testing into 7.3.4.  Not even as contrib material --- how embarrassed
would you be if the contrib tree then fails to build on some platform?
7.3 is long past the point where we should be adding new features to it.

If there are people out there who want to try tsearch2 with 7.3,
let them grab a separate tarball for it.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] PostgreSQL 7.3.3 and Intel C compiler

2003-07-21 Thread Hans-Jürgen Schönig
Bruce Momjian wrote:
Hans-J?rgen Sch?nig wrote:

This week I have done some performance tuning at a customer's office. We 
have beaten (demoralized) MS SQL and DB2 in serializable mode and DB2 in 
any transaction isolation level :).

By the way: In case of very simple statements SERIALIZABLE is about 3 
times faster than READ COMMITTED. I expected it to be faster but I did 
not expect this difference.


Why was SERIALIZABLE faster?  I know SERIALIZABLE doesn't have the
rollback penalty in read-only queries, but I don't understand why it
would be faster.


To be honest I don't have the slightest idea. Maybe it has to do with 
snapshotting but I don't know precisely. In case of SERIALIZABLE all 
snapshots inside a transaction are the same - maybe this makes the big 
difference. I have no other explanation for that.

There is one nifty detail which seems VERY strange to me: If 
serializable mode is set in postgresql.conf the system was 3 times 
faster (~ 7.5 sec. vs. 2.5sec). If serializable mode was set for every 
transaction (using set at the beginning of the transaction) serializable 
mode was as fast as read committed.

We have done 90% cursor work and very simple queries (mostly queries 
such as DECLARE CURSOR x FOR SELECT * FROM ... WHERE a = b).
I have no idea why PostgreSQL behaves like that but it seems to be a 
really good tweak because in this mode we beat any other database 
including SQL server on Windows 2003 (2.9sec) and IBM DB2 on Linux (12.6 
seconds).
I am sorry but I cannot provide you the tools we have used because we 
have a non disclosure agreement with the customer. I will try to verify 
this with my machines and a simple self-made benchmark.

	Regards,

		Hans



--
Cybertec Geschwinde u Schoenig
Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
Tel: +43/2952/30706; +43/664/233 90 75
www.cybertec.at, www.postgresql.at, kernel.cybertec.at


---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [HACKERS] dblink_ora - a first shot on Oracle ...

2003-07-21 Thread Hans-Jürgen Schönig
I think for that very reason (SQL-MED) we need to come to terms with 
this issue. If/when connections to external data sources is in the 
backend, you'll have those exact same dependencies. And in fact, we do 
today: consider '--with-openssl' or '--with-tcl'.

I had always assumed we would need '--with-oracle', '--with-jdbc',  etc 
(or whatever you want to call them) to support backend connections to 
external sources. And this discussion is the very reason I was hesitant 
to pursue dblink_ora or jdbclink now, because I didn't think people 
would be comfortable with configure options to support a contrib library.

Joe
If dblink was a core module I would say that adding the configure stuff 
would be very natural. Since this is contrib stuff I was not that sure 
about configure anymore. We will need additional flags for external data 
sources in the (hopefully) near future so I think we should add it.

Personally I tend to think about a solution like that. dblink has a 
great future and many people simply love it (I cannot think of a 
customer who does not like it - it is a killer feature):

- implement the concepts proposed by Joe on this list yesterday (I am 
talking about the functions dblink should provide)
- add support to configure
- merge dblink with dblink_ora as soon as the changes are ready
- adapt jdbc_link and merge it with dblink
- implement dblink_db2, dblink_csv, dblink_xml, and maybe some others
- leave it in contrib because this way it will be shipped with the core 
distribution and people will use it more frequently

I hope that I will finish the Oracle stuff (named connections, ...) 
within the next 3 days.

	Regards,

		Hans

--
Cybertec Geschwinde u Schoenig
Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
Tel: +43/2952/30706; +43/664/233 90 75
www.cybertec.at, www.postgresql.at, kernel.cybertec.at


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html


Re: [HACKERS] PostgreSQL 7.3.3 and Intel C compiler

2003-07-21 Thread Gavin Sherry
On Mon, 21 Jul 2003, [ISO-8859-1] Hans-Jürgen Schönig wrote:

  Why was SERIALIZABLE faster?  I know SERIALIZABLE doesn't have the
  rollback penalty in read-only queries, but I don't understand why it
  would be faster.
  
 
 
 To be honest I don't have the slightest idea. Maybe it has to do with 
 snapshotting but I don't know precisely. In case of SERIALIZABLE all 
 snapshots inside a transaction are the same - maybe this makes the big 
 difference. I have no other explanation for that.
 
 There is one nifty detail which seems VERY strange to me: If 
 serializable mode is set in postgresql.conf the system was 3 times 
 faster (~ 7.5 sec. vs. 2.5sec). If serializable mode was set for every 
 transaction (using set at the beginning of the transaction) serializable 
 mode was as fast as read committed.

Hmm.

 
 We have done 90% cursor work and very simple queries (mostly queries 
 such as DECLARE CURSOR x FOR SELECT * FROM ... WHERE a = b).
 I have no idea why PostgreSQL behaves like that but it seems to be a 
 really good tweak because in this mode we beat any other database 
 including SQL server on Windows 2003 (2.9sec) and IBM DB2 on Linux (12.6 
 seconds).

Are you testing the same type of cursors? Cursors do not behave
according to READ COMMITTED principles under Postgres. What are the
results for READ ONLY INSENSITIVE cursors with DB2 and MS SQL?

Thanks,

Gavin


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [HACKERS] dblink_ora - a first shot on Oracle ...

2003-07-21 Thread Hans-Jürgen Schönig
Bruce Momjian wrote:
Hans, I am a little confused about what you are suggesting.  Are you
suggesting flag to the make of the contrib module rather than configure
tests?
I agree this is a killer feature for many people and would like to have
it in 7.4.


Under these circumstances I was thinking of integrating it into the main 
configuration mechanism - not just for contrib.
We will need it for cross db suff later on anyway.

Sorry for the confusion.

	Regards,

		Hans

--
Cybertec Geschwinde u Schoenig
Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
Tel: +43/2952/30706; +43/664/233 90 75
www.cybertec.at, www.postgresql.at, kernel.cybertec.at


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] php with postgres

2003-07-21 Thread Marcus Börger
Hello Bruce,

Monday, July 21, 2003, 9:15:05 PM, you wrote:


BM Glad you got in touch with the right guys.  Joe and Jan have both talked
BM about doing PlPHP for a while.

:-)

BM Marcus, would you check if PHP is using RESET ALL when passing
BM persistent connection to new clients?  We added that capability a few
BM releases ago, specifically for PHP persistent connections, but I don't
BM think that ever got into the PHP code.

Unfortunately we don't do so yet. Do i need to check for errors or can i do it
unconditionally on conenction start? And i'd need to know how to check if it
is available (like starting with which version).


Best regards,
 Marcusmailto:[EMAIL PROTECTED]


---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [HACKERS] php with postgres

2003-07-21 Thread Marcus Börger
Hello Bruce,

Monday, July 21, 2003, 9:37:08 PM, you wrote:

BM Marcus B?rger wrote:
 BM Marcus, would you check if PHP is using RESET ALL when passing
 BM persistent connection to new clients?  We added that capability a few
 BM releases ago, specifically for PHP persistent connections, but I don't
 BM think that ever got into the PHP code.
 
 Unfortunately we don't do so yet. Do i need to check for errors or can i do it
 unconditionally on conenction start? And i'd need to know how to check if it
 is available (like starting with which version).

BM It first appeared in PostgreSQL version 7.2.  It doesn't generate any
BM failures.  It just resets all SET settting to their defaults, in case
BM the previous client modified them.


Committed for PHP 5.0 if there is a version 4.4 or 4.5 i'll commit the patch
for that version, too. Now we need someone with a big site to test whether it
brings any new problems. If there aren't problems i could probably also commit
to PHP 4.3.3. Btw. i don't do RESET ALL when creating the link because that
shouldn't be necessary.

-- 
Best regards,
 Marcusmailto:[EMAIL PROTECTED]


---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org