Re: FW: [webmaster] Comparison to MySQL - Mailing list pgsql-advocacy
From | Jan Wieck |
---|---|
Subject | Re: FW: [webmaster] Comparison to MySQL |
Date | |
Msg-id | 3FB0EFB1.8080104@Yahoo.com Whole thread Raw |
In response to | Re: FW: [webmaster] Comparison to MySQL (Josh Berkus <josh@agliodbs.com>) |
Responses |
Re: FW: [webmaster] Comparison to MySQL
|
List | pgsql-advocacy |
Josh Berkus wrote: > Shridhar, > >> OK, this was result of some efforts on advocacy, IIRC..:-) >> >> http://sql-info.de/mysql/gotchas.html > > I'm confused. This is exactly an example of what I was suggesting that we > don't want to do. Did you offer it in that sense, or some other way? > Me too, about this overly MySQL-friendly attitude. Don't get me wrong, I don't ask for unbiased bashing and such, but that gotchas page is a totally valid response as long as MySQL AB uses bad researched crap (read lies) to make PostgreSQL look bad or more incomplete than it is. Need an example? Just run their latest version of crashme. It tells PostgreSQL does not support circular foreign keys and has this evidence for it: > foreign_key_circular: > > DB > create schema crash_schema create table crash_q (a int primary key, b int, foreign key (b) references crash_q2(a))create table crash_q2(a int, b int, primary key(a), foreign key (b) references crash_q(a)) > execute error:ERROR: Relation "crash_q2" does not exist > DB > drop schema crash_schema cascade > execute error:ERROR: Schema "crash_schema" does not exist Considering how hard they test on all the other ALTER TABLE stuff, why is it that they give up so easy on this? Could it be that trying harder here would ultimately end up in "MySQL does not support DEFERRED"? And this test shows that we don't allow updates to referenced keys: > DB > create table crash_me1 (a int not null,primary key (a)) > OK > DB > create table crash_me2 (a int not null,foreign key (a) references crash_me1 (a)) > OK > DB > create index crash_me2_1 on crash_me2 (a) > OK > DB > insert into crash_me1 values (1) > OK > DB > insert into crash_me2 values (1) > OK > DB > update crash_me1 set a = 2 > execute error:ERROR: $1 referential integrity violation - key in crash_me1 still referenced from crash_me2 > DB > drop table crash_me2 > OK > DB > drop table crash_me1 > OK Yes, that is what the standard asks for. If you want to allow that, you have to specify "ON UPDATE {CASCADE|SET NULL}". People who can read (standards) have a clear advantage. The list goes on and on, it has been there in this form or worse for years. Come again Josh, what did change on the MySQL side? "He's mad that trusts in the tameness of a wolf, a horse's health, a boy's love, or a whore's oath." William Shakespeare Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
pgsql-advocacy by date: