Apologizes if this has already been announced -
http://www.scribd.com/doc/551889/Introducing-Freebsd-70
a presentation of the SMP in FreeBSD 7.0 using PostgreSQL and MySQL to
produce benchmarks.
Notable quotes -
a) MySQL degrades after utilizing all CPUs, while PostgreSQL does not
(the
On Wed, 5 Mar 2008, [EMAIL PROTECTED] wrote:
b) PostgreSQL is in general 35%-45% faster.
And this is using sysbench, which is an old MySQL benchmark with
rudimentary PostgreSQL support bolted on. Last time I checked it didn't
even put statements into transaction blocks correctly under
While no one in thier right mind should be using wikipgedia, I'm sympathetic
to those who might still be stuck on it for some reason, so if you guys can
produce a patch against the wikipgedia cvs, I'd be happy to apply it.
I'd like to patch that name.
---(end of
Andreas 'ads' Scherbaum wrote:
Hello,
On Thu, 22 Feb 2007 00:16:24 +0800
Lincoln Yeoh lyeoh@pop.jaring.my wrote:
Want transactions? Use innoDB. Want to restore a multi-gigabyte
database fast from backups, sure use MyISAM (too many people seem to
have probs doing that with innoDB).
sure you
On Friday 23 February 2007 16:43, Chad Wagner wrote:
On 2/23/07, Bill Moran [EMAIL PROTECTED] wrote:
In any case if anyone is interested I was able to reproduce the changes
that
wikipgedia made and applied those changes (as well as others) all the
way up
to the 1.6.10
On Thu, 22 Feb 2007 17:14:11 -0600
Jim Nasby [EMAIL PROTECTED] wrote:
On Feb 20, 2007, at 11:59 PM, Adam Rich wrote:
As of 5.0.2, the server requires that month and day values
be legal, and not merely in the range 1 to 12 and 1 to 31,
respectively.
Yes, but any session is free to change
Hello,
On Thu, 22 Feb 2007 00:16:24 +0800
Lincoln Yeoh lyeoh@pop.jaring.my wrote:
Want transactions? Use innoDB. Want to restore a multi-gigabyte
database fast from backups, sure use MyISAM (too many people seem to
have probs doing that with innoDB).
sure you want to do this?
Hello all,
On Wed, 21 Feb 2007 10:02:04 -0600
Scott Marlowe [EMAIL PROTECTED] wrote:
It swallows column level foreign key contraints and does nothing with
them, no errors nothing, even if you're defining innodb tables. I.e.
this produces not errors:
mysql create table a (id int primary
On Fri, 23 Feb 2007 13:49:06 +1300
Andrej Ricnik-Bay [EMAIL PROTECTED] wrote:
On 2/23/07, Jim Nasby [EMAIL PROTECTED] wrote:
That depends greatly on what you're doing with it. Generally, as soon
as you start throwing a multi-user workload at it, MySQL stops
scaling. http://tweakers.net
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
How is the Postgres port of the Wikipedia doing this days anyway?
Is it in a shape where one would consider it competitive?
The port of MediaWiki is going well: it is certainly usable, and
is already being used by a number of sites. I
For the record, anyone using wikipgedia deserves the pain they
get: it is deprecated. The latest version of MediaWiki itself is what
should now be used: it will detect if you have Postgres upon
installation. :)
Perhaps the project should be *gasp* deleted then? ;-) Or is there
actual
On 2/25/07, Greg Sabino Mullane [EMAIL PROTECTED] wrote:
For the record, anyone using wikipgedia deserves the pain they
get: it is deprecated. The latest version of MediaWiki itself is what
should now be used: it will detect if you have Postgres upon
installation. :)
Some of us are still
On 2/25/07, Magnus Hagander [EMAIL PROTECTED] wrote:
For the record, anyone using wikipgedia deserves the pain they
get: it is deprecated. The latest version of MediaWiki itself is what
should now be used: it will detect if you have Postgres upon
installation. :)
Perhaps the project should
On 2/23/07, Bill Moran [EMAIL PROTECTED] wrote:
I installed wikipgdia for the WPLUG wiki:
http://wplug.ece.cmu.edu/wiki/
Isn't that the same wikipgedia that is found at pgFoundry? The only issue I
really had the the wikipgedia port is that the codebase is 1.6alpha, and it
seemed like it
In response to Chad Wagner [EMAIL PROTECTED]:
On 2/23/07, Bill Moran [EMAIL PROTECTED] wrote:
I installed wikipgdia for the WPLUG wiki:
http://wplug.ece.cmu.edu/wiki/
Isn't that the same wikipgedia that is found at pgFoundry?
Yes.
The only issue I
really had the the wikipgedia port
On 2/22/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Joshua D. Drake escribió:
Andrej Ricnik-Bay wrote:
On 2/23/07, Jim Nasby [EMAIL PROTECTED] wrote:
That depends greatly on what you're doing with it. Generally, as soon
as you start throwing a multi-user workload at it, MySQL stops
Le vendredi 23 février 2007 16:37, Ian Harding a écrit :
On 2/22/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Joshua D. Drake escribió:
Andrej Ricnik-Bay wrote:
On 2/23/07, Jim Nasby [EMAIL PROTECTED] wrote:
That depends greatly on what you're doing with it. Generally, as
soon as
Ben wrote:
I'm sorry maybe I missed something, but if you don't need NULLs and
feel they just add extra work, why don't you just declare all your
columns to be not null and have them default to zero or an empty string?
which is what mySQL does by default :-)
The statement
CREATE TABLE foo
In that case, the distinction just
adds work.
In that case you declare the column not null and don't use nulls.
--
Scott Ribe
[EMAIL PROTECTED]
http://www.killerbytes.com/
(303) 722-0567 voice
---(end of broadcast)---
TIP 1: if
On Fri, Feb 23, 2007 at 01:49:06PM +1300, Andrej Ricnik-Bay wrote:
On 2/23/07, Jim Nasby [EMAIL PROTECTED] wrote:
That depends greatly on what you're doing with it. Generally, as soon
as you start throwing a multi-user workload at it, MySQL stops
scaling. http://tweakers.net recently did a
Mark Walker wrote:
I'm not sure what you're trying to do but, it appears that you database
design is incorrect. What you need is something like
CREATE TABLE temp_readings
(
_date Date,
temperature double,
source varchar(20),
)
No reading, no record. Are you suggesting that you
Crawford
Sent: Friday, February 23, 2007 1:04 PM
To: Mark Walker
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] postgresql vs mysql
Mark Walker wrote:
I'm not sure what you're trying to do but, it appears that you
database
design is incorrect. What you need is something like
CREATE TABLE
Glen Parker wrote:
Buy the same token, some application have no use whatsoever for the
distinction between NULL and ''. In that case, the distinction just
adds work.
True, I suppose. But if I need that, I can live with a one-time ...not
null default ''... addition to my table definition. Or a
On Thursday 22 February 2007 05:10, Rich Shepard wrote:
On Thu, 22 Feb 2007, Tim Tassonis wrote:
I do still think it is a bit of an oddity, the concept of the null
column. From my experience, it creates more problems than it actually
solves and generally forces you to code more rather than
Steve Crawford schrieb:
Mark Walker wrote:
I'm not sure what you're trying to do but, it appears that you database
design is incorrect. What you need is something like
CREATE TABLE temp_readings
(
_date Date,
temperature double,
source varchar(20),
)
No reading, no record. Are you
Ben wrote:
I'm sorry maybe I missed something, but if you don't need NULLs and feel
they just add extra work, why don't you just declare all your columns to
be not null and have them default to zero or an empty string?
Because I DO need NULLS for non text fields, and I still want NULL to
That's absolutely correct. What I want is a totally non standard
*optional* extension, recognizing that many, even if not most,
applications could benefit from it. I think there's a clean way to do it.
I would never ask for such a thing if I thought it would effect an out
of the box
Glen Parker schrieb:
Ben wrote:
I'm sorry maybe I missed something, but if you don't need NULLs and
feel they just add extra work, why don't you just declare all your
columns to be not null and have them default to zero or an empty string?
Because I DO need NULLS for non text fields, and I
On 2/23/07, Bill Moran [EMAIL PROTECTED] wrote:
In any case if anyone is interested I was able to reproduce the changes
that
wikipgedia made and applied those changes (as well as others) all the
way up
to the 1.6.10 codebase. The only reason I mention this is because 1.6is
the only choice
Brandon Aiken wrote:
That's why you make a table for every device or every measurement,
and then use a view to consolidate it. With updatable views, there's
no excuse not to.
No, you put them all on one table and put nulls in places where no data
is available. With real database systems,
It cannot already do what I want, unless you blatantly ignore what I
wrote. Putting coalesce() calls *everywhere* counts as more work, don't
you agree?
-Glen
Ben wrote:
But, why do you need an extension when the existing system can already
do what you want?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/23/07 15:47, Peter Eisentraut wrote:
Brandon Aiken wrote:
That's why you make a table for every device or every measurement,
and then use a view to consolidate it. With updatable views, there's
no excuse not to.
No, you put them all on
Ben wrote:
What I read was that you have no use for NULLs, and that they're
equivilant to zero or an empty string or some other known value. Sorry
if I misunderstood that.
Equivalent, yes, because NULL doesn't usually mean UNKNOWN in this
system, just NOT ENTERED. I do still have use for
Ron Johnson wrote:
Each of the daily/hourly/etc temperature readings are independent.
Therefore they should each have their own row in the meteorology
readings table. I *think* that breaks 3NF.
If everything is, as you say, independent, then there can be no 3NF
violation, because that only
On Fri, Feb 23, 2007 at 02:50:48PM -0800, Glen Parker wrote:
I can and do solve the problem by simply not using NULL in character
fields, and by the rather gratuitous use of coalesce() in queries.
I'm confused. If you don't use NULLs then you don't need coalesce
either.
The
problem is,
That's why you make a table for every device or every measurement, and
then use a view to consolidate it. With update-able views, there's no
excuse not to.
I would be interested on here some of your experiences on this?
I've built and made use of table hierarchies three levels deep and about
On Thu, Feb 22, 2007 at 01:08:04PM +1100, Chris wrote:
In postgres, to stop an empty blank string:
create table a(a text not null check (char_length(a) 0));
What's wrrong with using
a ''
sd the check? Or is this just a flavour thing?
--
To the extent that we overreact, we proffer
he he. what does the PHP of databases mean?
Joshua D. Drake wrote:
John Smith wrote:
On 2/21/07, Lincoln Yeoh lyeoh@pop.jaring.my wrote:
MySQL: the PHP of databases.
'd appreciate if you stick to the subject.
Oops he probably should not have used MySQL because it is
Chris írta:
CaT wrote:
On Thu, Feb 22, 2007 at 01:08:04PM +1100, Chris wrote:
In postgres, to stop an empty blank string:
create table a(a text not null check (char_length(a) 0));
What's wrrong with using
a ''
sd the check? Or is this just a flavour thing?
Nothing, I just thought of
Zoltan Boszormenyi wrote:
Chris írta:
CaT wrote:
On Thu, Feb 22, 2007 at 01:08:04PM +1100, Chris wrote:
In postgres, to stop an empty blank string:
create table a(a text not null check (char_length(a) 0));
What's wrrong with using
a ''
sd the check? Or is this just a flavour thing?
On Thu, Feb 22, 2007 at 09:13:13AM +0100, Zoltan Boszormenyi wrote:
Chris ?rta:
CaT wrote:
On Thu, Feb 22, 2007 at 01:08:04PM +1100, Chris wrote:
create table a(a text not null check (char_length(a) 0));
What's wrrong with using
a ''
Nothing, I just thought of the other way first :)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My definition is, toy used/trumpeted by pseudo-professionals as a
professional tool, when it just doesn't measure up.
On 02/22/07 02:08, Tyarli wrote:
he he. what does the PHP of databases mean?
Joshua D. Drake wrote:
John Smith wrote:
On
CaT írta:
On Thu, Feb 22, 2007 at 09:13:13AM +0100, Zoltan Boszormenyi wrote:
Chris ?rta:
CaT wrote:
On Thu, Feb 22, 2007 at 01:08:04PM +1100, Chris wrote:
create table a(a text not null check (char_length(a) 0));
What's wrrong with using
a ''
On Thu, Feb 22, 2007 at 11:27:18AM +0100, Zoltan Boszormenyi wrote:
I would do a CHECK (trim(a) '')
Whitespaces are values too, you know.
Yes, I know. But e.g. for a real people name, would you store
accidentally entered spaces before or after the actual name, too?
Which would also ruin
Ron Johnson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My definition is, toy used/trumpeted by pseudo-professionals as a
professional tool, when it just doesn't measure up.
/me Tries really hard to resist responding
/me Fails
I'm sorry, but having just been described as a
Ron Johnson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My definition is, toy used/trumpeted by pseudo-professionals as a
professional tool, when it just doesn't measure up.
Boah, here surely speaks a true professional playing in the league of
Donald Knuth or even Alan Kay, as
Chris wrote:
Erick Papadakis wrote:
So how should I make a database rule in MySQL to not allow blank
strings. Basically to REQUIRE a value for that column, whether it is
NULL or NADA or VOID or whatever you wish to call it. I just want to
make sure that something, some value, is entered for a
Zoltan Boszormenyi wrote:
I would do a CHECK (trim(a) '')
If you were ok with a string consisting soley of whitespace.
I meant NOT NULL CHECK(trim(a) ''), keeping the context of the
above example.
Right. I plead that it was late when i replied. I honestly don't know
what i was
On Thu, Feb 22, 2007 at 12:05:20PM +1100, Chris wrote:
SELECT foo, bar, COUNT(*)
FROM baz
GROUP BY foo
That one actually comes in handy ;) Especially in older versions (4.0)
that don't support subselects..
I must say I don't see any reasonable way of interpreting the above
query. Is the
2007/2/22, Russ Brown [EMAIL PROTECTED]:
Ron Johnson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My definition is, toy used/trumpeted by pseudo-professionals as a
professional tool, when it just doesn't measure up.
/me Tries really hard to resist responding
/me Fails
I'm sorry,
On Thu, 22 Feb 2007, Tim Tassonis wrote:
I do still think it is a bit of an oddity, the concept of the null column.
From my experience, it creates more problems than it actually solves and
generally forces you to code more rather than less in order to achieve
your goals.
Tim,
Long ago, a
Rich Shepard wrote:
On Thu, 22 Feb 2007, Tim Tassonis wrote:
I do still think it is a bit of an oddity, the concept of the null
column.
From my experience, it creates more problems than it actually solves and
generally forces you to code more rather than less in order to achieve
your goals.
Russ == Russ Brown [EMAIL PROTECTED] writes:
Russ Take perl for example. I have still yet to see readable Perl code.
I could say the same for greek, and pl/pgsql.
You can't read it if you're not familiar with it. Please stop bashing Perl
until you've read at least Learning Perl or the
At 01:11 PM 2/22/2007, John Smith wrote:
On 2/21/07, Lincoln Yeoh lyeoh@pop.jaring.my wrote:
MySQL: the PHP of databases.
'd appreciate if you stick to the subject.
jzs
OK sorry... That was more of a footnote.
Link.
---(end of
At 10:22 PM 2/22/2007, Tim Tassonis wrote:
Chris wrote:
An empty string is a KNOWN value. You know exactly what that value
is - it's an empty string.
A NULL is UNKNOWN - it doesn't have a value at all.
I do still think it is a bit of an oddity, the concept of the null
column. From my
Randal L. Schwartz wrote:
Russ Take perl for example. I have still yet to see readable Perl code.
You can't read it if you're not familiar with it.
Seconded. Perl is like the churkendoose -- hybrid strength, ugly as
hell, only poultry known that can scare off a fox every time, whole
On 2/22/07, Martijn van Oosterhout kleptog@svana.org wrote:
On Thu, Feb 22, 2007 at 12:05:20PM +1100, Chris wrote:
SELECT foo, bar, COUNT(*)
FROM baz
GROUP BY foo
That one actually comes in handy ;) Especially in older versions (4.0)
that don't support subselects..
I must say I don't see
10:31 AM
To: Rich Shepard
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] postgresql vs mysql
Rich Shepard wrote:
On Thu, 22 Feb 2007, Tim Tassonis wrote:
I do still think it is a bit of an oddity, the concept of the null
column.
From my experience, it creates more problems than
If you don't know something, why are you trying to record it? From a strict
relational sense, the existence of NULL values in your fields indicates that
your primary keys are not
truly candidate keys for all your fields. That means your database isn't [BCNF]
normalized.
I agree that there
On 22/02/07, Shashank Tripathi [EMAIL PROTECTED] wrote:
I would do a CHECK (trim(a) '')
TRIM() would add some processing time, so I'd include it only if there
was a chance of spaces getting added. From a puritanical point of
view, it is definitely a good idea.
To the original poster, this
I would do a CHECK (trim(a) '')
TRIM() would add some processing time, so I'd include it only if there
was a chance of spaces getting added. From a puritanical point of
view, it is definitely a good idea.
To the original poster, this syntax should work in MySQL as well:
create table
On Feb 20, 2007, at 11:59 PM, Adam Rich wrote:
As of 5.0.2, the server requires that month and day values
be legal, and not merely in the range 1 to 12 and 1 to 31,
respectively.
Yes, but any session is free to change that setting and insert
whatever garbage they want. AFAIK there's
On Feb 21, 2007, at 10:26 AM, Scott Marlowe wrote:
The only thing I can think of that rewrites a whole postgresql table
would be reindexing it, or an update without a where clause (or a
where
clause that includes every row). Normal operations, like create
index,
add column, drop column, etc
On Feb 21, 2007, at 2:23 PM, Brandon Aiken wrote:
IMX, the only things going for MySQL are:
1. It's fast.
That depends greatly on what you're doing with it. Generally, as soon
as you start throwing a multi-user workload at it, MySQL stops
scaling. http://tweakers.net recently did a study
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/22/07 17:17, Jim Nasby wrote:
On Feb 21, 2007, at 10:26 AM, Scott Marlowe wrote:
The only thing I can think of that rewrites a whole postgresql table
would be reindexing it, or an update without a where clause (or a where
clause that
-Original Message-
From: Jim Nasby [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 22, 2007 6:28 PM
To: Brandon Aiken
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] postgresql vs mysql
On Feb 21, 2007, at 2:23 PM, Brandon Aiken wrote:
IMX, the only things going for MySQL
On Thu, 2007-02-22 at 18:48 -0500, Brandon Aiken wrote:
Digg and Slashdot use MySQL databases, so clearly they *can* be made to
support a high-load, high-performance, limited-write style web
application.
You might remember a few months back when SlashDot had to turn off
threaded replies
Ron Johnson wrote:
On 02/21/07 18:09, Erick Papadakis wrote:
How would you like to use a database that has nuances like these --
http://forums.mysql.com/read.php?20,141120,141120#msg-141120
Huh?
A blank string (does that mean '' or ' '?) is not NULL, so of
*course* it should pass the NOT
On 2/23/07, Jim Nasby [EMAIL PROTECTED] wrote:
That depends greatly on what you're doing with it. Generally, as soon
as you start throwing a multi-user workload at it, MySQL stops
scaling. http://tweakers.net recently did a study on that.
I think I recall that wikipedia uses MySQL ... they get
Tim Tassonis wrote:
Chris wrote:
Erick Papadakis wrote:
So how should I make a database rule in MySQL to not allow blank
strings. Basically to REQUIRE a value for that column, whether it is
NULL or NADA or VOID or whatever you wish to call it. I just want to
make sure that something, some
Andrej Ricnik-Bay wrote:
On 2/23/07, Jim Nasby [EMAIL PROTECTED] wrote:
That depends greatly on what you're doing with it. Generally, as soon
as you start throwing a multi-user workload at it, MySQL stops
scaling. http://tweakers.net recently did a study on that.
I think I recall that
I'm not sure what you're trying to do but, it appears that you database
design is incorrect. What you need is something like
CREATE TABLE temp_readings
(
_date Date,
temperature double,
source varchar(20),
)
No reading, no record. Are you suggesting that you would have a weekly
set of
Joshua D. Drake escribió:
Andrej Ricnik-Bay wrote:
On 2/23/07, Jim Nasby [EMAIL PROTECTED] wrote:
That depends greatly on what you're doing with it. Generally, as soon
as you start throwing a multi-user workload at it, MySQL stops
scaling. http://tweakers.net recently did a study on that.
Buy the same token, some application have no use whatsoever for the
distinction between NULL and ''. In that case, the distinction just
adds work.
I would love to see different ways to handle NULL implemented by the
server. For what I do, NULL could always compare equal to zero and ''.
I
Alvaro Herrera wrote:
Joshua D. Drake escribió:
Andrej Ricnik-Bay wrote:
On 2/23/07, Jim Nasby [EMAIL PROTECTED] wrote:
That depends greatly on what you're doing with it. Generally, as soon
as you start throwing a multi-user workload at it, MySQL stops
scaling. http://tweakers.net recently
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/22/07 19:04, Mark Walker wrote:
I'm not sure what you're trying to do but, it appears that you database
design is incorrect. What you need is something like
CREATE TABLE temp_readings
(
_date Date,
temperature double,
source
Joshua D. Drake escribió:
Alvaro Herrera wrote:
Joshua D. Drake escribió:
Andrej Ricnik-Bay wrote:
On 2/23/07, Jim Nasby [EMAIL PROTECTED] wrote:
That depends greatly on what you're doing with it. Generally, as soon
as you start throwing a multi-user workload at it, MySQL stops
Alvaro Herrera wrote:
Joshua D. Drake escribió:
Alvaro Herrera wrote:
Joshua D. Drake escribió:
Andrej Ricnik-Bay wrote:
On 2/23/07, Jim Nasby [EMAIL PROTECTED] wrote:
That depends greatly on what you're doing with it. Generally, as soon
as you start throwing a multi-user workload at it,
On 2/23/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
Andrej Ricnik-Bay wrote:
On 2/23/07, Jim Nasby [EMAIL PROTECTED] wrote:
That depends greatly on what you're doing with it. Generally, as soon
as you start throwing a multi-user workload at it, MySQL stops
scaling. http://tweakers.net
I'm sorry maybe I missed something, but if you don't need NULLs and
feel they just add extra work, why don't you just declare all your
columns to be not null and have them default to zero or an empty string?
On Feb 22, 2007, at 5:11 PM, Glen Parker wrote:
Buy the same token, some
Ben wrote:
I'm sorry maybe I missed something, but if you don't need NULLs and feel
they just add extra work, why don't you just declare all your columns to
be not null and have them default to zero or an empty string?
Stop making sense!
Joshua D. Drake
On Feb 22, 2007, at 5:11 PM, Glen
sounds like you aren't happy with one of the products your company offers at
http://www.commandprompt.com/community/plphp/ - plphp stands for procedural
language php. the language has the php engine at its core and provides php
scripting support for procedures and functions in postgresql. written
Alvaro Herrera [EMAIL PROTECTED] wrote:
Joshua D. Drake escribió:
Andrej Ricnik-Bay wrote:
On 2/23/07, Jim Nasby [EMAIL PROTECTED] wrote:
That depends greatly on what you're doing with it. Generally, as soon
as you start throwing a multi-user workload at it, MySQL stops
scaling.
John Smith wrote:
sounds like you aren't happy with one of the products your company
offers at
http://www.commandprompt.com/community/plphp/ - plphp stands for
procedural
language php. the language has the php engine at its core and provides php
scripting support for procedures and functions
On 2/20/07, gustavo halperin [EMAIL PROTECTED] wrote:
I have a friend that ask me why postgresql is better than mysql.
I personally prefer posgresql, but she need to give in her work 3 or 4
strong reasons for that. I mean not to much technical reasons. Can you
give help me please ?
How
This can (I discovered yesterday) be fixed by adding ONLY_FULL_GROUP_BY
to the sql_mode setting.
As Ron mentioned though that can be happily overridden on a per-session
basis so it's not as 'strict' as it makes out...
Chad Wagner wrote:
On 2/20/07, *gustavo halperin* [EMAIL PROTECTED]
On Wednesday 21 February 2007 1:10:41 am Tom Lane wrote:
Adam Rich [EMAIL PROTECTED] writes:
I'm not apologizing for their past mistakes.. But the issue
you cite is no longer true:
As of 5.0.2, the server requires that month and day values
be legal, and not merely in the range 1 to 12 and
On Wed, Feb 21, 2007 at 08:54:30AM -0500, Jan de Visser wrote:
It gets better: The problem is not just feb 35, it's also that it doesn't
warn
you that it didn't like the input format:
Actually it did, sort of.
mysql insert into test values ('35-Feb-2007');
Query OK, 1 row affected, 1
On Tue, 2007-02-20 at 15:25, gustavo halperin wrote:
Hello
I have a friend that ask me why postgresql is better than mysql.
I personally prefer posgresql, but she need to give in her work 3 or 4
strong reasons for that. I mean not to much technical reasons. Can you
give help me
Scott Marlowe wrote:
You can't change a table in any way without rewriting the whole thing,
resulting in a very long wait and a complete table lock on any alter
table action on big tables. Don't forget that if you've got a really
big table, you need that much space free on the drive to alter
On Wed, 2007-02-21 at 10:12, Jack Orenstein wrote:
Scott Marlowe wrote:
You can't change a table in any way without rewriting the whole thing,
resulting in a very long wait and a complete table lock on any alter
table action on big tables. Don't forget that if you've got a really
big
At 07:31 PM 2/21/2007, Chad Wagner wrote:
On 2/20/07, gustavo halperin
mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote:
I have a friend that ask me why postgresql is better than mysql.
I personally prefer posgresql, but she need to give in her work 3 or 4
strong reasons for that. I mean not to
At 12:02 AM 2/22/2007, Scott Marlowe wrote:
You can't change a table in any way without rewriting the whole thing,
resulting in a very long wait and a complete table lock on any alter
table action on big tables. Don't forget that if you've got a really
Oh yeah, that reminds me. rewriting the
It's got a query parser that's dumb as a brick.
While we're on this topic... I have a question on these series
of queries:
-- Query A
select count(*) from customers c
where not exists ( select 1 from orders o
where o.customer_id = c.customer_id )
-- Query B
select count(*) from customers c
On Wed, 2007-02-21 at 10:54, Adam Rich wrote:
It's got a query parser that's dumb as a brick.
While we're on this topic... I have a question on these series
of queries:
-- Query A
select count(*) from customers c
where not exists ( select 1 from orders o
where o.customer_id =
Adam Rich wrote:
-- Query A
select count(*) from customers c
where not exists ( select 1 from orders o
where o.customer_id = c.customer_id )
-- Query B
select count(*) from customers c
where customer_id not in ( select customer_id from orders)
-- Query C
select count(*) from customers c
On 2/21/07, Lincoln Yeoh lyeoh@pop.jaring.my wrote:
At 07:31 PM 2/21/2007, Chad Wagner wrote:
On 2/20/07, gustavo halperin
mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote:
I have a friend that ask me why postgresql is better than mysql.
I personally prefer posgresql, but she need to give in her
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/21/07 08:42, Michael Fuhr wrote:
On Wed, Feb 21, 2007 at 08:54:30AM -0500, Jan de Visser wrote:
It gets better: The problem is not just feb 35, it's also that it doesn't
warn
you that it didn't like the input format:
Actually it did,
/IT Systems Engineer
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of gustavo
halperin
Sent: Tuesday, February 20, 2007 4:26 PM
To: pgsql-general@postgresql.org
Subject: [GENERAL] postgresql vs mysql
Hello
I have a friend that ask me why postgresql
How would you like to use a database that has nuances like these --
http://forums.mysql.com/read.php?20,141120,141120#msg-141120
ep
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
1 - 100 of 166 matches
Mail list logo
