Ühel kenal päeval, R, 2006-05-19 kell 11:29, kirjutas Mark Woodward:
Andrew Dunstan [EMAIL PROTECTED] writes:
Mark Woodward wrote:
Again, there is so much code for MySQL, a MySQL emulation layer, MEL
for
short, could allow plug and play compatibility for open source, and
closed
On Fri, May 19, 2006 at 01:03:08PM -0700, Mischa Sandberg wrote:
On Thursday 18 May 2006 12:38, Josh Berkus wrote:
Personally, I'd go after MSSQL before I bothered with MySQL. Sure, let's
make *migration* easier for those who wake up and smell the BS, but
migration can (and probably should)
On 5/22/06, Martijn van Oosterhout kleptog@svana.org wrote:
On Mon, May 22, 2006 at 10:00:22AM -0500, Jim C. Nasby wrote:
T-SQL has statement-level triggers, and they get used a lot (some big apps
ONLY put code in triggers). Statement-level triggers are very efficient for
maintaining
On Mon, May 22, 2006 at 05:06:47PM +0200, Martijn van Oosterhout wrote:
On Mon, May 22, 2006 at 10:00:22AM -0500, Jim C. Nasby wrote:
T-SQL has statement-level triggers, and they get used a lot (some big
apps
ONLY put code in triggers). Statement-level triggers are very efficient
On Sat, May 20, 2006 at 02:29:01PM +0200, Dawid Kuroczko wrote:
On 5/20/06, Lukas Smith [EMAIL PROTECTED] wrote:
The improvements to the installer are great, but there simply needs to
be a packaged solution that adds more of the things people are very
likely to use. From my understanding
On Sat, May 20, 2006 at 02:29:01PM +0200, Dawid Kuroczko wrote:
On 5/20/06, Lukas Smith [EMAIL PROTECTED] wrote:
The improvements to the installer are great, but there simply needs to
be a packaged solution that adds more of the things people are very
likely to use. From my understanding
On Mon, May 22, 2006 at 10:41:59AM -0500, Jim C. Nasby wrote:
CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }
ON table FOR EACH STATEMENT
EXECUTE PROCEDURE funcname ( arguments )
And that doesn't give you any information on the rows that were
modified. Other RDBMSes
On 5/22/06, Mark Woodward [EMAIL PROTECTED] wrote:
Except that apt doesn't work on all platforms. Though it would certainly
make sense to look at lifting the framework for CPgAN from somewhere,
rather than coding it ourselves.
A CPgAN would be a great idea in theory, but I have reservations.
Martijn van Oosterhout wrote:
On Mon, May 22, 2006 at 10:41:59AM -0500, Jim C. Nasby wrote:
CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }
ON table FOR EACH STATEMENT
EXECUTE PROCEDURE funcname ( arguments )
And that doesn't give you any information on the rows
On Mon, May 22, 2006 at 08:56:14PM +0200, Dawid Kuroczko wrote:
Also, assuming there is a pginstall dbanme packagename interface,
a -contrib package should register all its subpackages within that
system. So, you install postgresql-contrib, and then you can type:
pg_package install mydb
On Mon, May 22, 2006 at 08:45:07PM +0200, Martijn van Oosterhout wrote:
On Mon, May 22, 2006 at 10:41:59AM -0500, Jim C. Nasby wrote:
CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }
ON table FOR EACH STATEMENT
EXECUTE PROCEDURE funcname ( arguments )
And that
On Mon, May 22, 2006 at 03:14:18PM -0400, Alvaro Herrera wrote:
Martijn van Oosterhout wrote:
On Mon, May 22, 2006 at 10:41:59AM -0500, Jim C. Nasby wrote:
CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }
ON table FOR EACH STATEMENT
EXECUTE PROCEDURE funcname (
Jim C. Nasby [EMAIL PROTECTED] writes:
If there was more information than the tuplestore could keep in memory,
then a TIDstore might be faster, but only if it resulted in reading from
the heap sequentially, or very near it.
That's easily arranged, use a bitmap indexing data structure.
I think
Andrew Dunstan [EMAIL PROTECTED] writes:
How expensive is this going to be, especially for huge numbers of rows?
Certainly cheaper than firing a per-row trigger.
Would it be done for all queries, or just those with a per statement
trigger, or only when explicitly requested?
Just when
On Thursday 18 May 2006 12:38, Josh Berkus wrote:
Personally, I'd go after MSSQL before I bothered with MySQL. Sure, let's
make *migration* easier for those who wake up and smell the BS, but
migration can (and probably should) be one-way.
Somebody earlier was mentioning, why no automatic
Mischa,
Somebody earlier was mentioning, why no automatic transformer from
Transact-SQL to PLPGSQL (maybe with a bunch of glue routines). The grammar
is not a problem, though you have to wonder at all the wired-in keywords
(T-SQL always felt like COBOL).
Actually, porting TSQL to PL/pgSQL
On Fri, May 19, 2006 at 07:04:47PM -0400, Bruce Momjian wrote:
libreadline is not a problem because you can distribute postgresql
compiled with readline and comply with all licences involved
simultaneously. It doesn't work with openssl because the licence
requires things that are
Hi,
I really think that PostgreSQL could benefit from a packaged solution
that incorporates a lot of the contrib stuff (tsearch2, maybe even some
replication setups ..). I really like the approach that PostgreSQL is a
clean yet highly extensible base from which other people can build their
On Sat, May 20, 2006 at 10:36:25AM +0200, Lukas Smith wrote:
The improvements to the installer are great, but there simply needs to
be a packaged solution that adds more of the things people are very
likely to use. From my understanding Bizgres goes in that direction? I
just think that
Martijn van Oosterhout wrote:
On Sat, May 20, 2006 at 10:36:25AM +0200, Lukas Smith wrote:
The improvements to the installer are great, but there simply needs to
be a packaged solution that adds more of the things people are very
likely to use. From my understanding Bizgres goes in that
Lukas Kahwe Smith wrote:
...
apt-get install postgresql-8.1 postgresql-contrib-8.1
Voila! Tsearch installed at your fingertips. What else were you
expecting?
I expect this to be one package and I expect this to be what is pushed
as the default package on all platforms. If someone just sat
On 5/20/06, Lukas Smith [EMAIL PROTECTED] wrote:
The improvements to the installer are great, but there simply needs to
be a packaged solution that adds more of the things people are very
likely to use. From my understanding Bizgres goes in that direction? I
just think that whatever highly
My question is whether psql using libreadline.so has to be GPL, meaning
the psql source has to be included in a binary distribution.
If I understand what I have been told by lawyers, here's what using a GPL,
and NOT LGPL, library means:
According to RMS, the definition of a derivitive work is
On Sat, May 20, 2006 at 10:36:25AM +0200, Lukas Smith wrote:
Hi,
I really think that PostgreSQL could benefit from a packaged solution
that incorporates a lot of the contrib stuff (tsearch2, maybe even some
replication setups ..). I really like the approach that PostgreSQL is a
clean yet
Then again PGfoundry is great to keep development centered, but
finding and building a new package is not really a one-liner, and
if you're unlucky you might get alpha-quality code installed. :)
Mammoth PostgreSQL was designed to fill this role. It is an FOSS project
On Fri, May 19, 2006 at 07:04:47PM -0400, Bruce Momjian wrote:
libreadline is not a problem because you can distribute postgresql
compiled with readline and comply with all licences involved
simultaneously. It doesn't work with openssl because the licence
requires things that are
Christopher Kings-Lynne wrote:
If you want to get users to swtich to your software from your
competitors, you have to eliminate barriers, and a big one for any
database is getting locked into a specific one. People aren't going
to take the time to try switching to postgresql if they can't
Am Freitag, 19. Mai 2006 02:35 schrieb Robert Treat:
On Thursday 18 May 2006 12:38, Josh Berkus wrote:
Personally, I'd go after MSSQL before I bothered with MySQL. Sure,
let's make *migration* easier for those who wake up and smell the BS, but
migration can (and probably should) be
On Fri, May 19, 2006 at 01:26:34AM +0200, Dawid Kuroczko wrote:
Personally my opinion is that there is no point in pushing PostgreSQL
everywhere -- if there is no siginifcant performance gain, most managers
will refuse it, on the grounds that if it ain't (too) broke, don't fix it.
The real
When MySQL is at that
point, which database do you think executives will be choosing? The one
with a very large userbase and lots of marketing and PR that they've
heard plenty about,
All due respect, Jim -- but don't you work for a publicly traded
database company that happens to have its
Andrew Dunstan [EMAIL PROTECTED] writes:
Mark Woodward wrote:
Again, there is so much code for MySQL, a MySQL emulation layer, MEL
for
short, could allow plug and play compatibility for open source, and
closed
source, applications that otherwise would force a PostgreSQL user to
hold
his
On Thu, May 18, 2006 at 02:58:11PM -0400, Mark Woodward wrote:
The reality is that MySQL is widely supported by some very, shall we say,
interesting open source projects and using these products with
PostgreSQL would be a plus.
The biggest headache I find with using postgres is that various
Martijn van Oosterhout wrote:
The biggest headache I find with using postgres is that various GPL
licenced programs have trouble directly shipping postgresql support
because of our use of OpenSSL. Each and every one of those program
needs to add an exception to their licence for distributors to
Martijn van Oosterhout wrote:
On Thu, May 18, 2006 at 02:58:11PM -0400, Mark Woodward wrote:
The reality is that MySQL is widely supported by some very, shall we say,
interesting open source projects and using these products with
PostgreSQL would be a plus.
The biggest headache I find with
Joshua D. Drake wrote:
Martijn van Oosterhout wrote:
On Thu, May 18, 2006 at 02:58:11PM -0400, Mark Woodward wrote:
The reality is that MySQL is widely supported by some very, shall we say,
interesting open source projects and using these products with
PostgreSQL would be a plus.
The
Joshua D. Drake wrote:
Martijn van Oosterhout wrote:
On Thu, May 18, 2006 at 02:58:11PM -0400, Mark Woodward wrote:
The reality is that MySQL is widely supported by some very, shall we
say,
interesting open source projects and using these products with
PostgreSQL would be a plus.
The
On Fri, 2006-05-19 at 09:11 -0700, Joshua D. Drake wrote:
Martijn van Oosterhout wrote:
On Thu, May 18, 2006 at 02:58:11PM -0400, Mark Woodward wrote:
The reality is that MySQL is widely supported by some very, shall we say,
interesting open source projects and using these products with
Alvaro Herrera wrote:
Joshua D. Drake wrote:
Martijn van Oosterhout wrote:
On Thu, May 18, 2006 at 02:58:11PM -0400, Mark Woodward wrote:
The reality is that MySQL is widely supported by some very, shall we say,
interesting open source projects and using these products with
PostgreSQL would
On Fri, May 19, 2006 at 11:29:23AM -0400, Mark Woodward wrote:
I kind of agree with this statement, but while I was playing devils's
advocate and just grousing a bit about having to use MySQL, there is a
sort of reality of openomics where mind-share is everything.
The more mind-share you
Actually, I think it's a lot more accurate to compare PostgreSQL and
MySQL as FreeBSD vs Linux from about 5 years ago. Back then FreeBSD was
clearly superior from a technology standpoint, and clearly playing
second-fiddle when it came to users. And now, Linux is actually
technically superior in
Moving to -advocacy, bcc to -hackers.
On Fri, May 19, 2006 at 08:11:42AM -0700, Joshua D. Drake wrote:
When MySQL is at that
point, which database do you think executives will be choosing? The one
with a very large userbase and lots of marketing and PR that they've
heard plenty about,
All
Actually, I think it's a lot more accurate to compare PostgreSQL and
MySQL as FreeBSD vs Linux from about 5 years ago. Back then FreeBSD was
clearly superior from a technology standpoint, and clearly playing
second-fiddle when it came to users. And now, Linux is actually
technically superior
On Fri, May 19, 2006 at 03:39:23PM -0400, Mark Woodward wrote:
Actually, I think it's a lot more accurate to compare PostgreSQL and
MySQL as FreeBSD vs Linux from about 5 years ago. Back then FreeBSD was
clearly superior from a technology standpoint, and clearly playing
second-fiddle
[EMAIL PROTECTED] (Mark Woodward) writes:
Jim C. Nasby wrote:
Maybe a compatability layer isn't worth doing, but I certainly
think it's very much worthwhile for the community to do everything
possible to encourage migration from MySQL. We should be able to
lay claim to most advanced and most
Rod Taylor wrote:
Exceptions exist in the GPL for libraries and tools included in the
operating system and this is enough in most cases. GPL applications on
Windows may have problems.
What exception, exactly? Does an exception apply to libreadline,
because list I looked, it didn't.
--
Bruce Momjian wrote:
Rod Taylor wrote:
Exceptions exist in the GPL for libraries and tools included in the
operating system and this is enough in most cases. GPL applications on
Windows may have problems.
What exception, exactly? Does an exception apply to libreadline,
because list I
Andrew Dunstan wrote:
Bruce Momjian wrote:
Rod Taylor wrote:
Exceptions exist in the GPL for libraries and tools included in the
operating system and this is enough in most cases. GPL applications on
Windows may have problems.
What exception, exactly? Does an exception
On Fri, May 19, 2006 at 04:41:20PM -0400, Bruce Momjian wrote:
Yes, the exeption applies to libreadline, which is why we can deliver
psql with libreadline linked on Linux, for example. But we can't on
Windows or Solaris.
OK, where do you see this exception? I have not.
The exception
Ühel kenal päeval, R, 2006-05-19 kell 09:40, kirjutas Christopher
Kings-Lynne:
We also need better support for non C locales in tsearch. As I was porting
mysql's sakila sample database I was reminded just how painful it is when
you
initdb in a non-supported locale (which is probably
On 5/19/06, Joshua D. Drake [EMAIL PROTECTED] wrote:
And with that, I am going to sit in a lawn chair and watch the bonfire.
This is one of the finest examples of unfocused discussions I've ever
seen on -hackers... while surely entertaining, what a huge waste of
time.
--
Jonah H. Harris,
Jonah H. Harris wrote:
On 5/19/06, Joshua D. Drake [EMAIL PROTECTED] wrote:
And with that, I am going to sit in a lawn chair and watch the bonfire.
This is one of the finest examples of unfocused discussions I've ever
seen on -hackers... while surely entertaining, what a huge waste of
time.
Ühel kenal päeval, R, 2006-05-19 kell 22:53, kirjutas Martijn van
Oosterhout:
libreadline is not a problem because you can distribute postgresql
compiled with readline and comply with all licences involved
simultaneously.
oh? my impression was that we are clear, because libreadline is just
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Fri, May 19, 2006 at 04:41:20PM -0400, Bruce Momjian wrote:
Yes, the exeption applies to libreadline, which is why we can deliver
psql with libreadline linked on Linux, for example. But we can't on
Windows or Solaris.
Joshua D. Drake wrote:
Jonah H. Harris wrote:
On 5/19/06, Joshua D. Drake [EMAIL PROTECTED] wrote:
And with that, I am going to sit in a lawn chair and watch the bonfire.
This is one of the finest examples of unfocused discussions I've ever
seen on -hackers... while surely
* Mark Woodward:
On the other hand, you shouldn't use mysql_use_result() if you are doing
a lot of processing for each row on the client side, or if the output is
sent to a screen on which the user may type a ^S (stop scroll). This ties
up the server and prevent other threads from updating
On Wed, May 17, 2006 at 09:35:34PM -0400, John DeSoi wrote:
On May 17, 2006, at 8:08 PM, Mark Woodward wrote:
What is the best way to go about creating a plug and play,
PostgreSQL
replacement for MySQL? I think the biggest problem getting PostgreSQL
accepted is that so much code is
All,
What is the best way to go about creating a plug and play,
PostgreSQL
replacement for MySQL? I think the biggest problem getting PostgreSQL
accepted is that so much code is available for MySQL.
http://pgfoundry.org/projects/mysqlcompat/
Even better would be coming up with a
On May 18, 2006, at 12:24 PM, Jim C. Nasby wrote:
Even better would be coming up with a compatability mode, a la what
EnterpriseDB has done for Oracle.
Right, you'll definitely need to hack the C source code to force
PostgreSQL to accept invalid dates ;)
Jim C. Nasby wrote:
On Wed, May 17, 2006 at 09:35:34PM -0400, John DeSoi wrote:
On May 17, 2006, at 8:08 PM, Mark Woodward wrote:
What is the best way to go about creating a plug and play,
PostgreSQL
replacement for MySQL? I think the biggest problem getting PostgreSQL
accepted is that so
Josh Berkus wrote:
Personally, I'd go after MSSQL before I bothered with MySQL. Sure, let's
make *migration* easier for those who wake up and smell the BS, but migration
can (and probably should) be one-way.
Yeah. Let's write a Transact-SQL PL handler.
--
Alvaro Herrera
On Thu, 18 May 2006, Joshua D. Drake wrote:
Jim C. Nasby wrote:
On Wed, May 17, 2006 at 09:35:34PM -0400, John DeSoi wrote:
On May 17, 2006, at 8:08 PM, Mark Woodward wrote:
What is the best way to go about creating a plug and play, PostgreSQL
replacement for MySQL? I think the biggest
'k, so you want pure PostgreSQL ... but, shouldn't it be possible,
with all of our CREATE FUNCTION / RULES / etc features to create a
'translation layer' that could be loaded, like anything else in contrib?
Sure but that isn't what was suggested :)
Hell, even if it gave an initial in for
On Thu, 18 May 2006, Joshua D. Drake wrote:
I understand the idea but I personally don't like it. I am not really
interested in cross-database compatible code. 9 times out of 10 it is
hacky, slow and lacks a solid supportable model because you are always
taking into account *the other*
Marc,
To give someone a running chance at migrating it to PostgreSQL, a 'MySQL
compatibility module' would allow them to just plug the existing DB in,
and then work at improving sections of the code over time ...
Have you even looked at KL's mysqlcompat?
--
--Josh
Josh Berkus
PostgreSQL @
On Thu, May 18, 2006 at 10:35:48AM -0700, Joshua D. Drake wrote:
I understand the idea but I personally don't like it. I am not
really interested in cross-database compatible code. 9 times out of
10 it is hacky, slow and lacks a solid supportable model because you
are always taking into
On Thu, May 18, 2006 at 02:56:12PM -0300, Marc G. Fournier wrote:
On Thu, 18 May 2006, Joshua D. Drake wrote:
I understand the idea but I personally don't like it. I am not really
interested in cross-database compatible code. 9 times out of 10 it is
hacky, slow and lacks a solid
On Thu, May 18, 2006 at 11:09:28AM -0700, David Fetter wrote:
postgres=# CREATE TABLE dual();
CREATE TABLE
You forgot to populate it.
In reality I think you'd want dual to be a view on SELECT 1; or whatever
the appropriate value is.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL
On Thu, May 18, 2006 at 02:56:12PM -0300, Marc G. Fournier wrote:
the point isn't whether or not MySQL is a competitor ... the point is that
there are *alot* of MySQL based applications out there that are a major
PITA to convert (or get converted) all at once ...
More importantly, there's a
And MySQL is much closer to being a competitor now than they were in
4.1. And feature-wise they'll probably equal PostgreSQL in the next
release. Will the features be anywhere near as robust or well thought
out? No. But in a heck of a lot of companies that doesn't matter.
Your kidding right?
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
And to be frank, I don't think we should waste our time on MySQL. It
isn't a competitor, it just thinks it is. We should focus on our real
competition which is DB2, MSSQL, and Oracle.
One thing which would be kind of nice would be to have a
On Thu, May 18, 2006 at 01:22:55PM -0500, Jim C. Nasby wrote:
On Thu, May 18, 2006 at 11:09:28AM -0700, David Fetter wrote:
postgres=# CREATE TABLE dual();
CREATE TABLE
You forgot to populate it.
Oh, right. :)
postgres=# CREATE TABLE dual AS SELECT 1;
SELECT
Cheers,
D
--
David Fetter
Jim C. Nasby wrote:
Maybe a compatability layer isn't worth doing, but I certainly think
it's very much worthwhile for the community to do everything possible to
encourage migration from MySQL. We should be able to lay claim to most
advanced and most popular OSS database.
We'll do that by
Jim C. Nasby wrote:
On Wed, May 17, 2006 at 09:35:34PM -0400, John DeSoi wrote:
On May 17, 2006, at 8:08 PM, Mark Woodward wrote:
What is the best way to go about creating a plug and play,
PostgreSQL
replacement for MySQL? I think the biggest problem getting PostgreSQL
accepted is that so
Jim C. Nasby wrote:
Maybe a compatability layer isn't worth doing, but I certainly think
it's very much worthwhile for the community to do everything possible to
encourage migration from MySQL. We should be able to lay claim to most
advanced and most popular OSS database.
We'll do that by
John DeSoi wrote:
Right, you'll definitely need to hack the C source code to force
PostgreSQL to accept invalid dates ;)
http://sql-info.de/mysql/gotchas.html#1_14
Couldn't we just install something that replaced invalid dates with a randomly generated but
otherwise correct dates? That way
While I do agree with the ideal, the reality may not be good enough. Even
I, a PostgreSQL user for a decade, have to use MySQL right now because
that is what the client uses.
Then you aren't choosing your clients wisely. :)
I am not trying to be rude, but if you don't want to use MySQL,
Mark Woodward wrote:
Jim C. Nasby wrote:
Maybe a compatability layer isn't worth doing, but I certainly think
it's very much worthwhile for the community to do everything possible to
encourage migration from MySQL. We should be able to lay claim to most
advanced and most popular OSS
On Thu, May 18, 2006 at 02:58:11PM -0400, Mark Woodward wrote:
Jim C. Nasby wrote:
On Wed, May 17, 2006 at 09:35:34PM -0400, John DeSoi wrote:
On May 17, 2006, at 8:08 PM, Mark Woodward wrote:
What is the best way to go about creating a plug and play,
PostgreSQL
replacement for
Thomas Hallgren wrote:
John DeSoi wrote:
Right, you'll definitely need to hack the C source code to force
PostgreSQL to accept invalid dates ;)
http://sql-info.de/mysql/gotchas.html#1_14
Couldn't we just install something that replaced invalid dates with a
randomly generated but otherwise
Joshua D. Drake wrote:
Thomas Hallgren wrote:
John DeSoi wrote:
Right, you'll definitely need to hack the C source code to force
PostgreSQL to accept invalid dates ;)
http://sql-info.de/mysql/gotchas.html#1_14
Couldn't we just install something that replaced invalid dates with a
randomly
Joshua D. Drake wrote:
Thomas Hallgren wrote:
Couldn't we just install something that replaced invalid dates with a
randomly generated but otherwise correct dates? That way they would
become completely invisible. No one could even tell that the date was
invalid to start with.
No we can't,
On Thu, May 18, 2006 at 09:58:21PM +0200, Lukas Smith wrote:
Joshua D. Drake wrote:
No we can't, because then we are taking an invalid date, which is
potentially valid data (to the user) and modifying it to a valid
date that is indeed invalid data.
One of the reasons that mysql is just
I do agree that its probably not worth allocating core resources to
this, but spouting outdated FUD is really making you two look foolish.
And which FUD would this be?
You have to understand that MySQL evolves just like PostgreSQL does. So
you better focus on advertising where PostgreSQL
You've made some sweeping allegations here and no specifics.
sweeping allegations?
http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html
SET [GLOBAL|SESSION] sql_mode='ALLOW_INVALID_DATES'
Which can be turned off or on by any mysql user. Not to mention the fact
that it is even an
On Thu, May 18, 2006 at 01:25:34PM -0700, Joshua D. Drake wrote:
I do agree that its probably not worth allocating core resources to
this, but spouting outdated FUD is really making you two look foolish.
And which FUD would this be?
That Feb. 31st is a valid date in MySQL. You can now
Andrew Dunstan [EMAIL PROTECTED] writes:
Mark Woodward wrote:
Again, there is so much code for MySQL, a MySQL emulation layer, MEL for
short, could allow plug and play compatibility for open source, and closed
source, applications that otherwise would force a PostgreSQL user to hold
his or
David Fetter wrote:
On Thu, May 18, 2006 at 09:58:21PM +0200, Lukas Smith wrote:
In what way is this outdated? Please provide a specific example.
see below ..
You have to understand that MySQL evolves just like PostgreSQL does.
If it were true, I would have to understand it, but the
[EMAIL PROTECTED] (Marc G. Fournier) writes:
To give someone a running chance at migrating it to PostgreSQL, a
'MySQL compatibility module' would allow them to just plug the
existing DB in, and then work at improving sections of the code over
time ...
Hell, if done well, the module should be
If we had infinite resources this might make sense. We don't, so it
doesn't. There is a real cost to producing a compatibility layer,
and the cost will be those spiffy new features.
Let's get recursive queries, MERGE, and a couple more things and
they will still be chasing our heels.
Lukas Smith wrote:
.. but spouting outdated FUD is really making you two look foolish.
Wow. On a scale from 1 to 10 measuring seriousness, I'd put my posting on -4. I'd advice you
to take a step back and get some distance if you consider it outdated FUD.
Regards,
Thomas Hallgren
On Thursday 18 May 2006 16:17, Philippe Schmid wrote:
As a users of both Postgres and MySQL, I would also say, better add
missing features to Postgres than chasing some specialties that are
going to vanish anyway in MySQL.
I miss :
- a core full-text indexing engine. Tsearch2 is nice, but not
On Thursday 18 May 2006 12:38, Josh Berkus wrote:
Personally, I'd go after MSSQL before I bothered with MySQL. Sure, let's
make *migration* easier for those who wake up and smell the BS, but
migration can (and probably should) be one-way.
If you want to get users to swtich to your software
And MySQL is much closer to being a competitor now than they were in
4.1. And feature-wise they'll probably equal PostgreSQL in the next
release. Will the features be anywhere near as robust or well thought
out? No. But in a heck of a lot of companies that doesn't matter.
Don't forget that they
We also need better support for non C locales in tsearch. As I was porting
mysql's sakila sample database I was reminded just how painful it is when you
initdb in a non-supported locale (which is probably the default on the
majority of distros out there)
In 8.2 tsearch2 supports utf8...
If you want to get users to swtich to your software from your competitors, you
have to eliminate barriers, and a big one for any database is getting locked
into a specific one. People aren't going to take the time to try switching
to postgresql if they can't easily make it back to thier former
Christopher Kings-Lynne wrote:
And MySQL is much closer to being a competitor now than they were in
4.1. And feature-wise they'll probably equal PostgreSQL in the next
release. Will the features be anywhere near as robust or well thought
out? No. But in a heck of a lot of companies that doesn't
Chris Browne wrote:
[EMAIL PROTECTED] (Marc G. Fournier) writes:
To give someone a running chance at migrating it to PostgreSQL, a
'MySQL compatibility module' would allow them to just plug the
existing DB in, and then work at improving sections of the code over
time ...
Hell, if done well,
Sorry to interrupt, but I have had the opportinuty to have to work with
MySQL. This nice little gem is packed away in the reference for
mysql_use_result().
On the other hand, you shouldn't use mysql_use_result() if you are doing
a lot of processing for each row on the client side, or if the
Mark Woodward wrote:
Sorry to interrupt, but I have had the opportinuty to have to work with
MySQL. This nice little gem is packed away in the reference for
mysql_use_result().
On the other hand, you shouldn't use mysql_use_result() if you are doing
a lot of processing for each row on the
On May 17, 2006, at 8:08 PM, Mark Woodward wrote:
What is the best way to go about creating a plug and play,
PostgreSQL
replacement for MySQL? I think the biggest problem getting PostgreSQL
accepted is that so much code is available for MySQL.
http://pgfoundry.org/projects/mysqlcompat/
100 matches
Mail list logo
