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