# [EMAIL PROTECTED] / 2006-07-11 12:04:07 -0400:
> On 6/30/2006 1:07 PM, Merlin Moncure wrote:
>
> >* mysql has a few features here and there which are nice...just to
> >name a few, flush tables with lock, multiple insert, etc
(...)
> The multiple insert stuff is not only non-standard, it al
On 7/12/06 3:32 AM, "Rafal Pietrak" <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-07-11 at 15:24 -0500, Ron Johnson wrote:
>> Joshua D. Drake wrote:
>>> It is also something that users are clammoring for (and my customers). To
>>> the point that I have customers using unions to emulate the behavior
On 7/11/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Guido Neitzer wrote:
> On 11.07.2006, at 19:36 Uhr, Merlin Moncure wrote:
> It is not, as prepared statements have the problem that they are only
> optimized once and very generically and without actual knowledge of
> the parameter content, th
On Tue, 2006-07-11 at 21:11, Alvaro Herrera wrote:
> Maybe we could check the MCVs, and store those for which the plan would
> be A (say indexscan) and those for which it would be B (say bitmap
> indexscan), etc; so we'd save more than one plan and choose at execution
> time depending on the actual
On Tue, 2006-07-11 at 15:24 -0500, Ron Johnson wrote:
> Joshua D. Drake wrote:
> > It is also something that users are clammoring for (and my customers). To
> > the point that I have customers using unions to emulate the behavior. Why?
> > Because it is really, really fast.
>
> When inserting mult
On 11.07.2006, at 21:11 Uhr, Alvaro Herrera wrote:
I had the problem a few months ago, where my app server plugin and
the jdbc driver used prepared statements for selecting stuff from the
database. Most of the time, indexes weren't used at all, so
PostgreSQL performance was the worst I've ever s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joshua D. Drake wrote:
>> The multiple insert stuff is not only non-standard, it also encourages
>> the bad practice of using literal values directly in the SQL string
>> versus prepared statements with place holders. It is bad practice
>> because it i
Jan Wieck wrote:
> On 7/11/2006 1:08 PM, Scott Marlowe wrote:
>
>> On Tue, 2006-07-11 at 11:04, Jan Wieck wrote:
>>> On 6/30/2006 1:07 PM, Merlin Moncure wrote:
>>>
>>> > * mysql has a few features here and there which are nice...just to
>>> > name a few, flush tables with lock, multiple insert, e
Jan Wieck <[EMAIL PROTECTED]> writes:
> On 7/11/2006 1:08 PM, Scott Marlowe wrote:
>> I thought it was in the SQL 99 standard...
> The SQL bible doesn't say SQL99, it says it is a DB2 specific feature.
If you're speaking of INSERT INTO foo VALUES (a, row), (another, row), ...
that's in SQL92.
Guido Neitzer wrote:
> On 11.07.2006, at 19:36 Uhr, Merlin Moncure wrote:
>
> >As to preparing
> >statements, I agree in principle although I don't know if that is a
> >good argument not to make the non-paramaterized interface more
> >powerful.
>
> It is not, as prepared statements have the probl
On 7/11/06, Guido Neitzer <[EMAIL PROTECTED]> wrote:
On 11.07.2006, at 19:36 Uhr, Merlin Moncure wrote:
> As to preparing
> statements, I agree in principle although I don't know if that is a
> good argument not to make the non-paramaterized interface more
> powerful.
It is not, as prepared sta
> The multiple insert stuff is not only non-standard, it also encourages
> the bad practice of using literal values directly in the SQL string
> versus prepared statements with place holders. It is bad practice
> because it introduces SQL injection risks since the responsibility of
> literal value
On 7/11/2006 1:36 PM, Merlin Moncure wrote:
that said, i tried to put fairness in my comparison, many pg/mysql
comparisons ulimately resort to a dismissive mysql diss which does not
play well to the uninformed third party. so, I made an attempt at
something with some substance.
Totally unders
On 11.07.2006, at 19:36 Uhr, Merlin Moncure wrote:
As to preparing
statements, I agree in principle although I don't know if that is a
good argument not to make the non-paramaterized interface more
powerful.
It is not, as prepared statements have the problem that they are only
optimized once
On 7/11/2006 1:08 PM, Scott Marlowe wrote:
On Tue, 2006-07-11 at 11:04, Jan Wieck wrote:
On 6/30/2006 1:07 PM, Merlin Moncure wrote:
> * mysql has a few features here and there which are nice...just to
> name a few, flush tables with lock, multiple insert, etc
The multiple insert stuff is no
On Tue, 2006-07-11 at 11:04, Jan Wieck wrote:
> On 6/30/2006 1:07 PM, Merlin Moncure wrote:
>
> > * mysql has a few features here and there which are nice...just to
> > name a few, flush tables with lock, multiple insert, etc
> The multiple insert stuff is not only non-standard, it also encourage
On 7/11/06, Jan Wieck <[EMAIL PROTECTED]> wrote:
On 6/30/2006 1:07 PM, Merlin Moncure wrote:
I have no clue what flushing tables with lock might be good for. Are
applications in MySQuirreL land usually smarter than the DB engine with
respect to when to checkpoint or not?
no, but the ability to
On 6/30/2006 1:07 PM, Merlin Moncure wrote:
* mysql has a few features here and there which are nice...just to
name a few, flush tables with lock, multiple insert, etc
I have no clue what flushing tables with lock might be good for. Are
applications in MySQuirreL land usually smarter than the
On Sat, 2006-07-01 at 22:27, Christopher Browne wrote:
> In an attempt to throw the authorities off his trail, [EMAIL PROTECTED]
> ("Merlin Moncure") transmitted:
> > hm. that's all very true (and important), but I try and keep focus
> > on the things besides basic correctness that drive the devel
Merlin Moncure wrote:
* mysql has a few features here and there which are nice...just to
name a few, flush tables with lock, multiple insert, etc
PostgreSQL does have multiple inserts, but complying to the SQL92
standard, through INSERT (...) SELECT ...
For example:
INSERT INTO my_table (id,
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED]
("Merlin Moncure") transmitted:
> hm. that's all very true (and important), but I try and keep focus
> on the things besides basic correctness that drive the development
> cultural divide that seperates the two communities. p
On 6/30/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
Actually, PITR is in no way analagous. Try replicating something like
'INSERT INTO table SELECT random();' on MySQL and note how all the data
is different.
pgpool replication is equivalent to MySQL's replication. Or if you want
more sophisticat
"Merlin Moncure" 寫道：
> On 30 Jun 2006 08:58:27 -0700, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > I am new to pgsqlI really appreciate the licensing terms of
> > pgsql...mysql licensing is a little bit risky to use...
> >
> > Q. when using pgsql as a very heavy and mission critical appli
On Fri, Jun 30, 2006 at 01:07:32PM -0400, Merlin Moncure wrote:
> * mysql has decent out of the box replication that is easy to set up
> (one day I hope pg get hot PITR which is analagous feature)
Actually, PITR is in no way analagous. Try replicating something like
'INSERT INTO table SELECT rando
Mysql does not allow you to use now() as the default value of a column.
From their docs:
"The DEFAULT clause specifies a default value for a column. With one
exception, the default value must be a constant; it cannot be a function
or an expression. This means, for example, that you cannot set th
Merlin Moncure wrote:
>
> * mysql performance advantage is greatly overstated, although
> postgresql requires you to use certain conventions (example: prepared
> statements) to get comparable performance
> * both databases (IMO) are very stable. in 6 years of workikng with
> both databases, I've n
On 30 Jun 2006 08:58:27 -0700, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I am new to pgsqlI really appreciate the licensing terms of
pgsql...mysql licensing is a little bit risky to use...
Q. when using pgsql as a very heavy and mission critical applications,
what are the advantages of us
27 matches
Mail list logo
