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
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
[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] Pgsql-7.1RC1: SET SEED = something
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[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
