Re: Triggers, Stored Procedures, PHP. was: Re: PostgreSQL - Mailing list pgsql-general

From Jan Wieck
Subject Re: Triggers, Stored Procedures, PHP. was: Re: PostgreSQL
Date
Msg-id 3FCF4533.8030102@Yahoo.com
Whole thread Raw
In response to Re: Triggers, Stored Procedures, PHP. was: Re: PostgreSQL  ("scott.marlowe" <scott.marlowe@ihs.com>)
Responses Re: Triggers, Stored Procedures, PHP. was: Re: PostgreSQL
List pgsql-general
scott.marlowe wrote:
> On Tue, 2 Dec 2003, Jan Wieck wrote:
>
>> scott.marlowe wrote:
>>
>> > On Mon, 1 Dec 2003, Jan Wieck wrote:
>> >
>> >> Jason Tesser wrote:
>> >>
>> >> > Quoted as gospel by various people:
>> >> >>> MySQL cannot even handle sub-queries yet.
>> >> >
>> >> >> BTW, is that really still true?  I thought they had at least some
>> >> >> support for subqueries by now.
>> >> >
>> >> > yes sub queries in 4.1 which is still alpha
>> >>
>> >> "yes sub queries" is IMHO as precise as "yes foreign keys" ... look,
>> >> they have foreign key support, but do they have DEFERRED, ON DELETE SET
>> >> NULL, ON UPDATE CASCADE, all the stuff that makes it complete?
>> >
>> > They're working on those things, but as usual, MySQL got the big things
>> > mostly right, and the little things horribly wrong.  If you create a
>> > table with type=innodb on a database server that isn't compiled to support
>> > innodb tables, it will silently fail, and silenly allow you to build
>> > non-existent foreign keys.
>>
>> Wasn't able to find any of their plans for match-types or deferrability.
>
> Sorry, I wasn't disagreeing with you, I was adding to your point.  I.e.
> besides not being deferrable or cascading, mysql lets you declare fks
> relations that aren't actually there and throws no error.  I have read on
> their mailing lists though that they are "working the problem," but MySQL
> tends to be developed not in public, near as I can tell.

You don't have to disagree with me, I can have arguments with myself
over nothing.

They seem to have cascading, with some limitations. If one for example
has a self reference (like in a tree structure the reference to the
parent node in the same table), their manual says that ON UPDATE CASCADE
is treated as RESTRICT at some point to prevent infinite loops ... don't
know if this is caused by the same nonsense implementation that prevents
them from supporting INSERT INTO tab SELECT * FROM tab;

My conclusion still is that they add those features more for buzzword
marketing than for usability. Otherwise they would do them right.


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-general by date:

Previous
From: "Alistair Hopkins"
Date:
Subject: Re: postgresql locks the whole table!
Next
From: Lamar Owen
Date:
Subject: Re: [Fedora Core 1] yum repositories with 7.4?