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

[HACKERS] Merry X-Mass

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

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

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

[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:

[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 User

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 you

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 parameters are

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]: cannot write

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

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 branch

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 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] 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 our

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 Eisentraut

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 InitializeTransactionSystem() calls

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

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 planner,

[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

[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] 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.

[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

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

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