Re: [GENERAL] To Postgres Devs : Wouldn't changing the select limit
Greetings, Bruce! At 18.10.2001, 02:34, you wrote: >> Isn't it much worse to not follow PostgreSQL behavior than to not follow >> MySQL behavior? BM> Another idea: because our historical Limit #,# differs from MySQL, one BM> idea is to disable LIMIT #,# completely and instead print an error BM> stating they have to use LIMIT # OFFSET #. Although that would break BM> both MySQl and old PostgreSQL queries, it would not generate incorrect BM> results. It doesn't seem like a good idea. The best solution, IMHO, would be to introduce optional "MySQL-compatibility mode" for LIMIT in 7.2 Later LIMIT #,# can be marked deprecated in favour of LIMIT #, OFFSET # But please, don't *break* things; while this change may make life easier for some people migrating from MySQL far more people would be pissed off... -- Yours, Alexey V. Borzov, Webmaster of RDW.ru ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[GENERAL] pg7.1 release date
Greetings, pgsql-general! While researching material for a certain upcoming article, I found out that online docs still claim "2001-??-??" as a release date for PostgreSQL 7.1 -- Yours, Alexey V. Borzov, Webmaster of RDW.ru ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re[2]: [GENERAL] RFC: PostgreSQL and MySQL comparison.
Greetings, Peter! At 29.08.2001, 23:32, you wrote: >> But I do think that >> the statements in >> http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html >> should NOT go unanswered. PE> Okay, I answered them: PE> http://webmail.postgresql.org/~petere/comparison.html Looks good, but it's not exactly what I've had in mind. You see it is too often considered that if someone has to justify oneself, he is automatically guilty. I want to write an article that would make MySQL's developers justify themselves... Besides, one has to read the MySQL's article *before* this just to understand what's this all about... BTW, can I use parts of your answers in my work? And, a question to SQL standard gurus: is it necessary for a DBMS to implement subqueries and views to be considered entry-level SQL92 compliant. Besides, is there any document which has all PostgreSQL's deviations from standard in one place? PE> I tried to be reasonable and biased at the same time. ;-) PE> This article does not go into the advantages of PostgreSQL, since that's PE> already done elsewhere, such as here: PE> http://www.ca.postgresql.org/features.html -- Yours, Alexey V. Borzov, Webmaster of RDW.ru ---(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[2]: [GENERAL] Pgsql-7.1RC1: SET SEED =
Greetings, Tom! At 29.03.2001, 12:52, you wrote: TL> Alexey Borzov <[EMAIL PROTECTED]> writes: >> The development docs state that one can use SET SEED to seed the >> random number generator TL> Where? I see no such claim. Right here: http://www.postgresql.org/devel-corner/docs/postgres/sql-set.html TL> If there's something that leads you TL> to think that SET SEED and not setseed() is correct, then the docs TL> need to be fixed. This something is my experience with Pgsql 7.0.3, which did accept SET SEED. I believe the whole matter was clarified enough, so now you seem to have two options: either change everything back, or update the docs (add BIG BOLD letters that SET SEED is now obsolete) ;] -- Yours, Alexey V. Borzov, Webmaster of RDW ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re[2]: [GENERAL] Re: new type proposal
Greetings, Joseph! At 07.02.2001, 13:13, you wrote: JS> I noticed that people are ignoring the time created part of my JS> proposal. How can a read only field be implemented? A trigger that JS> causes and error if that field is updated? Well, why not just do something like new.time_created_field := old.time_created_field; in a BEFORE UPDATE trigger?.. -- Yours, Alexey V. Borzov, Webmaster of RDW
Re: [GENERAL] selecting a random record
Greetings, Culley! At 06.02.2001, 13:11, you wrote: CH> Any suggestions on how to select a random record from CH> any given table? SELECT * FROM any_given_table ORDER BY random() LIMIT 1; -- Yours, Alexey V. Borzov, Webmaster of RDW
Resolved! (was: Re[8]: [GENERAL] WTF is going on with PG_VERSION?)
Well, thanks to everybody who helped! It was indeed the problem with opening files - the limit was set to 1024 with more than 100 possible backends... Well, I suppose it wouldn't hurt to change the error message in the future versions of Postgres, 'cause now it is somewhat... misleading... ;-> Greetings, The Hermit Hacker! At 21.09.2000, 13:34, you wrote: >> Well, last question then: I wasn't too specific, but the problem >> with this crash is that not ONE SINGLE backend fails, but ALL OF >> THEM AT ONCE: someone comes running to me and shouts 'our site is >> down!', when I login and type 'ps eax | grep postgres' there >> are no postgres processes in memory... Which is strange, as I >> connect to Postgres from PHP, and use `persistent` connections, so >> the backends which are in memory should have already read their >> PG_VERSIONs... >> Is it as it should be with ENFILE failure? THH> that is as it was when we were hitting it ... we are actually running a db THH> on 4 seperate ports, and we would see one db beign down and the rest THH> running happily along ... as soon as one db goes for that last slot and THH> can't find it, that one would completely shut down, as its the 'parent THH> process' that appears to be the one going for it ... -- Yours, Alexey V. Borzov
Re[6]: [GENERAL] WTF is going on with PG_VERSION?
Greetings, Tom! At 20.09.2000, 10:41, you wrote: TL> "Alexey V. Borzov" <[EMAIL PROTECTED]> writes: >> Nope, that's not the problem. I just checked and every DB has its own >> PG_VERSION. Besides, _all_ of the databases are accessed on regular >> basis (I'm speaking of a website), but the crashes occur only once in >> a while (like, once a week)... TL> I'm wondering if you could be running out of kernel filetable slots, TL> so that the open of PG_VERSION is failing with ENFILE. (This would be TL> the trouble spot just because it's the first file a new backend tries TL> to open, and being a new backend it has no possible recovery tactic TL> like closing other files. Once a backend is up and running it can TL> usually survive ENFILE open failures by closing off other files.) This MIGHT be problem. I'm not sure, as it wasn't me who compiled the kernel for the box, but I'll look into it... Well, last question then: I wasn't too specific, but the problem with this crash is that not ONE SINGLE backend fails, but ALL OF THEM AT ONCE: someone comes running to me and shouts 'our site is down!', when I login and type 'ps eax | grep postgres' there are no postgres processes in memory... Which is strange, as I connect to Postgres from PHP, and use `persistent` connections, so the backends which are in memory should have already read their PG_VERSIONs... Is it as it should be with ENFILE failure? TL> If that's it, the solution is either to alter your kernel parameters to TL> increase NFILE, or to reduce the allowed number of concurrent backends, TL> or both. Guess we should increase file slots, as reducing the number of backends is definitely NOT an option. -- Yours, Alexey V. Borzov
