Really, there's no need for such determination.
MyISAM will look at BEGIN, COMMIT and ROLLBACK statements and do the only
thing that makes sense - ignore them. No syntax error will result.
Basically, you could have all code as transaction safe and still work with
MyISAM tables. Usage of FULLTEXT-
On Thu, Aug 28, 2003 at 01:35:48PM +0200, Ilja Booij wrote:
> sorry, no transactions. I'd like for dbmail to use them, but currently
> there is MySQL ISAM table support. These ISAM tables do not support
> Transactions.
>
> Anyone have any thoughts on why we should keep support for ISAM tables
>
Hi Matthew,
Agreed, PostgreSQL's FULLTEXT search is just as funky (if not more so, I
don't have enough hands-on
experience to say) than MySQL's.
If only MySQL's FULLTEXT was external like PostgreSQL's! Then, we
wouldn't be having this MyISAM vs
InnoDB discussion.
Regards,
Chris
Matthew T.
On Thu, 2003-08-28 at 07:57, Ilja Booij wrote:
> > There is one advantage that MyISAM tables have, and that's their
> > FULLTEXT index capabilities.
> That's an important point for DBmail.. Hadn't thought of that.
PostgreSQL supports full text search through a contrib module. Works
well from all
On Thursday, Aug 28, 2003, at 13:46 Europe/Amsterdam, Chris Nolan wrote:
Hi,
ISAM and MyISAM are venerable but it looks as if even MySQL AB
themselves are relying heavily on InnoDB. The fact that we can have
foregin keys now with InnoDB is
a massive benefit (MyISAM won't get this until it's i
I'd agree for the vast, vast majority of applications. Some weird admins
I know would love the feature. I guess the only option is to shoot Nerf
weapons at them. :-)
Ilja Booij wrote:
On Thursday, Aug 28, 2003, at 13:13 Europe/Amsterdam, Chris Nolan wrote:
I have a question for the wise pe
Hi,
ISAM and MyISAM are venerable but it looks as if even MySQL AB
themselves are relying heavily on InnoDB. The fact that we can have
foregin keys now with InnoDB is
a massive benefit (MyISAM won't get this until it's implemented for all
table types, which is slated for MySQL 5.0).
There is
On Thursday, Aug 28, 2003, at 13:13 Europe/Amsterdam, Chris Nolan wrote:
I have a question for the wise people of the world who use DBMail!
OpenLDAP has an SQL backend. DBMail talks to PostgreSQL and MySQL.
Would there be any point in getting DBMail to understand the schema
OpenLDAP uses (for
On Thursday, Aug 28, 2003, at 13:09 Europe/Amsterdam, Paul J Stevens
wrote:
Ilja Booij wrote:
* Authentication
The authentication code from dbauth??sql.c has been moved to a new
auth/ directory. There are two C-files there. authsql.c which
implements "classic" SQL authentication. authldap.c im
Hi,
sorry, no transactions. I'd like for dbmail to use them, but currently
there is MySQL ISAM table support. These ISAM tables do not support
Transactions.
Anyone have any thoughts on why we should keep support for ISAM tables
in dbmail? Dropping this and going of innoDB only on MySQL seems
I have a question for the wise people of the world who use DBMail!
OpenLDAP has an SQL backend. DBMail talks to PostgreSQL and MySQL. Would
there be any point in getting DBMail to understand the schema OpenLDAP
uses (for performance mainly I'd guess).
Chris
Paul J Stevens wrote:
Ilja Boo
Ilja Booij wrote:
* Authentication
The authentication code from dbauth??sql.c has been moved to a new auth/
directory. There are two C-files there. authsql.c which implements
"classic" SQL authentication. authldap.c implements LDAP authentication
as implemented by Aaron Stone ([EMAIL PROTECTE
All hail Ilja!
I have one question though - any chance of using transactions?
Regards,
Chris
Ilja Booij wrote:
Hi all,
finally, the new database code is in CVS. It is totally untested (it
compiles), and will be tested when I'm finished with an urgent project
that has started this week. Th
13 matches
Mail list logo
