Re: [HACKERS] Considerations for running current cvs pgsql and pgsql release on same machine?

2000-12-22 Thread Robert B. Easter
On Friday 22 December 2000 22:05, Tom Lane wrote: > I routinely run multiple versions at the same time. You need a separate > port, install directory, and data directory for each. Easiest way to do > this is to configure the non-default versions with > > ../configure --with-pgport=nnn --prefix=/

Re: [HACKERS] Considerations for running current cvs pgsql and pgsql release on same machine?

2000-12-22 Thread Tom Lane
"Robert B. Easter" <[EMAIL PROTECTED]> writes: > I'm wanting to run pgsql 7.0.3 release and pgsql current cvs on the same > machine without them conflicting (if possible). Can someone explain what I > should look out for when trying to do this? I routinely run multiple versions at the same tim

[HACKERS] Re: 7.1 on DEC/Alpha

2000-12-22 Thread Brent Verner
On 22 Dec 2000 at 21:58 (-0500), Brent Verner wrote: | On 22 Dec 2000 at 20:27 (-0500), Brent Verner wrote: | | observation: | | commenting out the queries with 'FROM person* p' causes the misc | regression test to pass. that's not what I meant to say. the misc test still FAILS, but it no

[HACKERS] Re: 7.1 on DEC/Alpha

2000-12-22 Thread Brent Verner
On 22 Dec 2000 at 20:27 (-0500), Brent Verner wrote: observation: commenting out the queries with 'FROM person* p' causes the misc regression test to pass. SELECT p.name, p.hobbies.name FROM person* p; Brent | Hi, | I saw the thread from a few days ago about Linux/Alpha and 7.1. I

[HACKERS] Considerations for running current cvs pgsql and pgsql release on same machine?

2000-12-22 Thread Robert B. Easter
I'm wanting to run pgsql 7.0.3 release and pgsql current cvs on the same machine without them conflicting (if possible). Can someone explain what I should look out for when trying to do this? I assume I'll have to configure --with-pgport=5433 (something other than 5432). How will the use of

[HACKERS] 7.1 on DEC/Alpha

2000-12-22 Thread Brent Verner
Hi, I saw the thread from a few days ago about Linux/Alpha and 7.1. I believe I'm seeing the same problems with DEC/Alpha (Tru64Unix 4.0D). I noticed the following in the postmaster.log, which occurs, as the Linux/Alpha bug report states, during the misc regression test. DEBUG: copy: line 2

Re: [HACKERS] GEQO status?

2000-12-22 Thread Tom Lane
Ed Loehr <[EMAIL PROTECTED]> writes: > You can remove the randomness by setting the Seed configuration value, True, but that's not the default setup. regards, tom lane

Re: [HACKERS] GEQO status?

2000-12-22 Thread Ed Loehr
Tom Lane wrote: > > The choices made by GEQO are intentionally random, so I would expect > variation in tuple output order even for repetitions of the identical > query. If you got a semantically different result, that would indeed > be a bug. But it would most likely be a bug in the core plann

Re: [HACKERS] GEQO status?

2000-12-22 Thread Tom Lane
Peter Eisentraut <[EMAIL PROTECTED]> writes: > I've seen a number of bug reports that would indicate to me the GEQO works > less than perfectly. I vividly recall how, while working on my own code, > mere additions of dummy clauses like '... AND 5=5' altered query results > in seemingly random way

Re: [HACKERS] Isn't init_irels() dangerous ?

2000-12-22 Thread Tom Lane
Hiroshi Inoue <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes: It seems that init_irels() should be called after InitializeTransactionSystem() was called. >> >> Can we just swap the order of the RelationCacheInitialize() and >> InitializeTrans

Re: [HACKERS] GEQO status?

2000-12-22 Thread Peter Eisentraut
Ed Loehr writes: > What is the status of the genetic algorithm query optimizer? Is this > supposed to work well on many-table joins, or has it fallen out of favor > or in disrepair? [I'm needing to optimize some large, many-table-join > queries and wondering time spent configuring/understanding

Re: [HACKERS] Unable to check out REL7_1 via cvs

2000-12-22 Thread Peter Eisentraut
Yusuf Goolamabbas writes: > Hi, I am using the following command to check out the 7.1 branch of > PostgreSQL. > cvs -d :pserver:[EMAIL PROTECTED]:/home/projects/pgsql/cvsroot co -r REL7_1 >pgsql I don't think there is a 7.1 branch yet, there being no 7.1 release yet either. -- Peter Eisentrau

Re: [HACKERS] GEQO status?

2000-12-22 Thread Tom Lane
Ed Loehr <[EMAIL PROTECTED]> writes: > is there a reason why GEQO is off by > default in the ODBC driver (postdrv.exe)? There may once have been a good reason for that, but it sounds like a mighty bad idea nowadays. AFAICT ODBC's default setting has been that way for as long as ODBC has been in

Re: [HACKERS] Unable to check out REL7_1 via cvs

2000-12-22 Thread Alfred Perlstein
* Yusuf Goolamabbas <[EMAIL PROTECTED]> [001222 15:47] wrote: > Nope, no luck with cvs -Rq also. Me thinks its some repository > permission issue. Don't know if CVSup would help either. I don't have > cvsup installed on this machine. CVSup would work, that's what I use. -- -Alfred Perlstein -

Re: [HACKERS] Unable to check out REL7_1 via cvs

2000-12-22 Thread Tom Lane
Use HEAD. REL7_1 is a tag, not a branch (and a misplaced tag at that, IMHO, since it's not the formal release or even close...) regards, tom lane

Re: [HACKERS] Unable to check out REL7_1 via cvs

2000-12-22 Thread Yusuf Goolamabbas
Nope, no luck with cvs -Rq also. Me thinks its some repository permission issue. Don't know if CVSup would help either. I don't have cvsup installed on this machine. > * Yusuf Goolamabbas <[EMAIL PROTECTED]> [001222 15:34] wrote: > > Hi, I am using the following command to check out the 7.1 bran

Re: [HACKERS] GEQO status?

2000-12-22 Thread Ed Loehr
Thomas Lockhart wrote: > > > What is the status of the genetic algorithm query optimizer? Is this > > supposed to work well on many-table joins, or has it fallen out of favor > > or in disrepair? [I'm needing to optimize some large, many-table-join > > queries and wondering time spent configuri

Re: [HACKERS] Unable to check out REL7_1 via cvs

2000-12-22 Thread Alfred Perlstein
* Yusuf Goolamabbas <[EMAIL PROTECTED]> [001222 15:34] wrote: > Hi, I am using the following command to check out the 7.1 branch of > PostgreSQL. > cvs -d :pserver:[EMAIL PROTECTED]:/home/projects/pgsql/cvsroot co -r REL7_1 >pgsql > > This is the error I am getting. > cvs [server aborted]: canno

Re: [HACKERS] GEQO status?

2000-12-22 Thread Ed Loehr
Tom Lane wrote: > > Ed Loehr <[EMAIL PROTECTED]> writes: > > What is the status of the genetic algorithm query optimizer? Is this > > supposed to work well on many-table joins, or has it fallen out of favor > > or in disrepair? > > It's supposed to work ;-). I'm not sure that the default param

[HACKERS] Unable to check out REL7_1 via cvs

2000-12-22 Thread Yusuf Goolamabbas
Hi, I am using the following command to check out the 7.1 branch of PostgreSQL. cvs -d :pserver:[EMAIL PROTECTED]:/home/projects/pgsql/cvsroot co -r REL7_1 pgsql This is the error I am getting. cvs [server aborted]: cannot write /home/projects/pgsql/cvsroot/CVSROOT/val-tags: Permission denied I

Re: [HACKERS] GEQO status?

2000-12-22 Thread Tom Lane
Ed Loehr <[EMAIL PROTECTED]> writes: > What is the status of the genetic algorithm query optimizer? Is this > supposed to work well on many-table joins, or has it fallen out of favor > or in disrepair? It's supposed to work ;-). I'm not sure that the default parameters are optimal, however. If

Re: [HACKERS] GEQO status?

2000-12-22 Thread Ed Loehr
Thomas Lockhart wrote: > > > What is the status of the genetic algorithm query optimizer? Is this > > supposed to work well on many-table joins, or has it fallen out of favor > > or in disrepair? [I'm needing to optimize some large, many-table-join > > queries and wondering time spent configuri

Re: [HACKERS] GEQO status?

2000-12-22 Thread Thomas Lockhart
> What is the status of the genetic algorithm query optimizer? Is this > supposed to work well on many-table joins, or has it fallen out of favor > or in disrepair? [I'm needing to optimize some large, many-table-join > queries and wondering time spent configuring/understanding geqo would be > f

[HACKERS] Inheritance is a security loophole!

2000-12-22 Thread Tom Lane
The lack of a permissions check for creating a child table means that in current sources, any user can inject data of his choosing into another user's tables. Example: User A: regression=> create table foo (f1 text); CREATE regression=> insert into foo values ('good data'); INSERT 271570 1 Use

Re: [HACKERS] RI problem with inherited table

2000-12-22 Thread Tom Lane
"Oliver Elphick" <[EMAIL PROTECTED]> writes: > It no longer seems to be possible to refer to a table, which is an > ancestor of any other, in a referential integrity constraint. > bray=# create table junk (id char(10) constraint junk_id_person references > person(id)); > NOTICE: CREATE TABLE wi

[HACKERS] RI problem with inherited table

2000-12-22 Thread Oliver Elphick
It no longer seems to be possible to refer to a table, which is an ancestor of any other, in a referential integrity constraint. In this example, "person" is the ancestor of several other tables: bray=# create table junk (id char(10) constraint junk_id_person references person*(id)); ERROR: p

Re: [HACKERS] Merry X-Mass

2000-12-22 Thread Partyka Robert
On Fri, 22 Dec 2000, Rod Taylor wrote: > > Little early aren't you? > I live from town (and this meen no internet access) today and when I back will be the XXI century so its last chance to wish You all mery xmass and happy new year ;) So have a good party at night 31.12.2000, dont drink to m

Re: [HACKERS] Merry X-Mass

2000-12-22 Thread Rod Taylor
Little early aren't you? select now()::date gives me 2000-12-22 Hmm.. only one digit is odd. -- Rod Taylor There are always four sides to every story: your side, their side, the truth, and what really happened. - Original Message - From: "Partyka Robert" <[EMAIL PROTECTED]> To: <[EMAIL

[HACKERS] Merry X-Mass

2000-12-22 Thread Partyka Robert
Hello, Merry Christmass and Happy New Year 2001 ;) R. "BoBsoN" Partyka

RE: [HACKERS] Status of JDBC Interface

2000-12-22 Thread Peter Mount
-- Peter Mount Enterprise Support Officer, Maidstone Borough Council Email: [EMAIL PROTECTED] WWW: http://www.maidstone.gov.uk All views expressed within this email are not the views of Maidstone Borough Council > -Original Message- > From: Peter Eisentraut [mailto:[EMAIL PROTECTED]]