Re: Buglist - Mailing list pgsql-general

On 19 Aug 2003 at 15:26, Bo Lorentsen wrote:

> On Tue, 2003-08-19 at 14:31, Shridhar Daithankar wrote:
> > Well, you could look at release notes. That contains lot of information. Of
> > course archives of pgsql-bugs and pgsql-patches are the ultimate unless you
> > plan to delve into CVS history and sources..
> Ok, I just liked to find something like bugzilla, or an explanation to
> how bugs are garantied to be visible. My boos like to compare this to
> the Mysql model found on : http://bugs.mysql.com/bugstats
>
> > Check this.. http://www.mysql.com/doc/en/ANSI_diff_Transactions.html
> Hmm, it sound like they have transactions on OmniDB tables, but these
> are really slow, and therefor they put much energy into advetising for
> the MyISAM files (non transactional). Or, am I missing something.

Pretty much true but hard to prove by evidence. I would say drop that line f
argument. Mysql has transactions. Period.

OK, if you talk about transactions across two table types, innodb not being
default, might be not being free, then it is valid.

First rule of argument. Always talk facts..

> > To me, it seems that their definition of transaction is limited to preventing
> > two guys writing to same row simaltenously, which is of course a limited view
> > of things.
> This sounds like there MyISAM tables, or ???

I haven't used mysql to be that expert.. sorry..

>
> > Few major differences I can see right here. Correct me on mysql side.
> >
> > - WAL log
> > - Transactabl DDLs
> Yes and lets add :
> - Views
> - subselects
> - plperl, plsql, plpython, plXXX

Extensible operator and type definition
Table files splitting on 1GB boundary
Rules
Inheritance
True foreign keys
Data integrity ( You should watch some mysql excertps produced on advocacy)

Here is one for your reference...
-------------
> * PROPER USAGE OF NULL
>
> mysql> select * from ai_test where id is null;
> +----+-------+
> | id | txt   |
> +----+-------+
> |  1 | hello |
> +----+-------+
> 1 row in set (0.00 sec)
>
> ;-). I digress. Off the top of my head, in no particular order:

You're not trying hard enough:

mysql> create table test3 (a date);
Query OK, 0 rows affected (0.00 sec)

mysql> insert into test3 values (-1);
Query OK, 1 row affected (0.01 sec)

mysql> insert into test3 values ('1996-02-31');
Query OK, 1 row affected (0.00 sec)

mysql> insert into test3 values ('1996-67-31');
Query OK, 1 row affected (0.00 sec)

mysql> select * from test3;
+------------+
| a          |
+------------+
| 0000-00-00 |
| 1996-02-31 |
| 0000-00-00 |
+------------+
3 rows in set (0.00 sec)
-------------

I wouldn't bet my shoe on such database..

>
> > - Nested transactions coming soon to PG
> > - PITR coming soon to PG
> Not good for argumenting with my boss about future :-)

May be right. But a decision maker needs to know roadmap as well. As I said in
another mail, there exists real world code for all of this and it is going to
happen. It's not a vapourware. If you can press it, I think talking about
future is a good idea..

> > I would love to see entire checklist but don't have any time to devote to
> > mysql.
> I do understand, and its no pleasure either :-)

Just to be clear, my unenthusiaism to study mysql has nothing to do with my
time shortage. If I need to study mysql to understand it better and project
postgresql, I would happily do that. But I seriously don't have time..

Bye
 Shridhar

--
Feel free to contact me (flames about my english and the useless of thisdriver
will be redirected to /dev/null, oh no, it's full...).(Michael Beck, describing
the PC-speaker sound device)