Jochem van Dieten wrote:
Also, let's not mistake the means for the goal. Using indexes is just
a way to solve it and there may be other fixes. The goal is to improve
performance.
no.. using indexes is THE way to fix it :)
I don't want a subquery scanning all 700 million rows in my table wh
On 6/9/05, [EMAIL PROTECTED] wrote:
>
> Okay, so I understand the idea about one field being the "creation" time, and
> the other being the "last modified" time (which a particularly pedantic
> application might regard as being one-and-the-same, at time of
> first-creation) and so I see you might
> http://dev.mysql.com/doc/mysql/en/timestamp-4-1.html
>
> > Absolutely brilliant document *g* ...
> >
> > So now, it makes a difference if it's the first TIMESTAMP column,
> > if it's running in MaxDB mode, if it has a defaulf of NULL (which will
> > be silently changed), if it has no default, a
On 6/9/05, Martijn Tonies wrote:
http://dev.mysql.com/doc/mysql/en/timestamp-4-1.html
> Absolutely brilliant document *g* ...
>
> So now, it makes a difference if it's the first TIMESTAMP column,
> if it's running in MaxDB mode, if it has a defaulf of NULL (which will
> be silently changed), if
> You can have any number of timestamp columns, but only one of them can
> be set to autoupdate. As of 4.1 you are not limited to this being the
> 1st one in the table and CURRENT_TIMESTAMP, CURRENT_TIMESTAMP(), or
> NOW() can be used in the DEFAULT. Read
>
> http://dev.mysql.com/doc/mysql/en/times
On Wed, 8 Jun 2005 [EMAIL PROTECTED] wrote:
> A long time ago when I was doing support for Lotus Notes, I was told that
> the customer who 'complains' about legitimate bugs may be the most valuable
> type of customer of all. This is because they care enough to vent. Who
> knows how many unhappy c
I'm missing something, here; what earthly good is there, in having two fields
in the same tuple being created so that they both automatically store exactly
the same data... and if it was valuable, is there no way of more reliably
building this behaviour into the external application?
Okay, so I
.html
The DATETIME, DATE, and TIMESTAMP Types
for MUCH more detail.
-Original Message-
From: Greg Whalin [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 09, 2005 2:54 PM
To: Jeff Smelser
Cc: mysql@lists.mysql.com
Subject: Re: Seriously.. When are we going to get subqueries?!
Jeff Smelser
Jeff Smelser wrote:
On Thursday 09 June 2005 01:26 pm, George L. Sexton wrote:
Another limitation in MySQL is that you can only have one timestamp column
with a default of CURRENT_TIMESTAMP.
How many friggin times do I have to say that this is not an issue with 4.1 and
above? Which, BTW,
On Thursday 09 June 2005 01:26 pm, George L. Sexton wrote:
> Another limitation in MySQL is that you can only have one timestamp column
> with a default of CURRENT_TIMESTAMP.
>
How many friggin times do I have to say that this is not an issue with 4.1 and
above? Which, BTW, is production mysql..
On 6/9/05, Bartis, Robert M (Bob) wrote:
>
> Its an email alias. You're asking for help from people you don't even know.
> You should therefore present your needs clearly and concisely. You should
> expect there to be questions. You should expect to not always get timely
> information. you sho
On 6/9/05, Roger B.A. Klorese wrote:
>
> If you're the first person this has bothered
He isn't, search the bugbase. (Including reports that are closed
because it is documented, without providing a fix, workaround or even
recategorizing as feauture request.)
> and if the limitations don't provid
[snip]
...minimal level of common decadency...
[/snip]
heh.
I am minimally decadent!
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Original Message-
From: George L. Sexton [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 09, 2005 2:26 PM
To: mysql@lists.mysql.com
Subject: Re: Seriously.. When are we going to get subqueries?!
You obviously don't understand the limitations of timestamps.
Another limitation in MySQL
On Thursday 09 June 2005 12:42, George L. Sexton wrote:
> On Thursday 09 June 2005 12:31, you wrote:
> > George L. Sexton wrote:
> > >You obviously don't understand the limitations of timestamps.
> >
> > You obviously don't understand how ineffective leading with an insult is.
My mistake.
> > If
George L. Sexton wrote:
You obviously don't understand the limitations of timestamps.
You obviously don't understand how ineffective leading with an insult is.
If you're the first person this has bothered, and if the limitations
don't provide inconsistency with a standard -- just with ot
If my compiler would validate the SQL Statements and ensure that they were
perfect, then I wouldn't have a problem at all.
However, since no developer tool that I have ever used (and I've used a lot of
different ones) does compile time validation of SQL syntax, that's pretty
much out of the que
You obviously don't understand the limitations of timestamps.
Another limitation in MySQL is that you can only have one timestamp column
with a default of CURRENT_TIMESTAMP.
It's not an issue I don't know. It's an issue I'd like to see fixed so that I
can list MySQL as a supported database alon
On 6/9/05, Keith Ivey wrote:
> I'm a little surprised that case-sensitivity is such a big deal. What sort of
> programmers randomly vary their capitalization from one occurrence of an
> identifier to the next
Inconsistencies in the capitalization aren't necessarily introduced by
a programmer. Esp
This is the weirdest thread I've ever seen. I've never seen so many seques
used in a thread
Agreed.
However, if you read the entire thread you have learned more in ONE location
about timestamps, default values, creating tables, other RDBMS types,
interoperability, contribution to the open
I'm a little surprised that case-sensitivity is such a big deal. What sort of
programmers randomly vary their capitalization from one occurrence of an
identifier to the next, and wouldn't people who are so non-detail-oriented be
making a lot of typos as well?
--
Keith Ivey <[EMAIL PROTECTED]>
On Thursday 09 June 2005 11:47 am, George Sexton wrote:
> I'm working in that direction. I first posted to the regular mysql list,
> and then I posted again to the internals list. I guess the next step is to
> talk to the MySQL people.
We answered you I thought.. Whats the issue you dont know?
J
This is the weirdest thread I've ever seen. I've never seen so many
seques used in a thread
All we need now is for someone to post a question about configuring
Tomcat to work with Microsoft SQL Server.
To get back to the spirit of the original post, I personally wouldn't
use subqueries
> -Original Message-
> From: Jay Blanchard [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 09, 2005 10:34 AM
> To: George Sexton; mysql@lists.mysql.com
> Subject: RE: Seriously.. When are we going to get subqueries?!
>
> [snip]
> > 1. Join the
[snip]
> 1. Join the development work.
>
I tried contributing over at the Tomcat project and really just got
abused
by the team there.
[/snip]
That is unfortunate, but cannot be held against the MySQL team, can it?
[snip]
> B. Find a product more suitable to your needs.
My issue is that shops
> -Original Message-
> From: Jay Blanchard [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 09, 2005 8:30 AM
> To: George Sexton
> Cc: mysql@lists.mysql.com
> Subject: RE: Seriously.. When are we going to get subqueries?!
>
> If you are
> not pleased with
[snip]
Well, Oracle, DB2, SQL Server, Access, PostgreSQL, and Sybase SQL
Anywhere
all do this. I looked at my copy of "A Guide to The SQL Standard" by
Chris
Date. It pretty plainly states that DEFAULT allows niladic (no argument)
functions. Its about time MySQL stopped complaining about things bein
[snip]
Not true. Triggers are in the SQL specification. They are a legitimate
feature with specified expected behaviour. A hack is only implementing
function returns as default field values on timestamps, rather than
handling all field types in a unified way and allowing them to be set to
the r
Jay Blanchard wrote:
[snip]
Well, George, you never mentioned that this was your problem. And you
would run into the same problem, given your definition above,
regardless
of database (unless the database product has a hack to account for it,
I am not aware of any).
Not true. PostgreSQL c
[snip]
> Well, George, you never mentioned that this was your problem. And you
> would run into the same problem, given your definition above,
regardless
> of database (unless the database product has a hack to account for it,
I
> am not aware of any).
Not true. PostgreSQL can do it. If you want t
On Thu, 09 Jun 2005 14:28:56 +0100
Gordan Bobic <[EMAIL PROTECTED]> wrote:
> My understanding was the timestamp fields were only set when the
> record is created. They are not changed when the record is
> modified.
http://dev.mysql.com/doc/mysql/en/timestamp-4-1.html
"The first TIMESTAMP column
[snip]
> 1)Why can't I declare a datetime field with DEFAULT NOW()
4.1 has options to default timestamps on update/inserts or both..
[/snip]
Cool, I didn't know that. I should have read the docs more closely this
morning.
--
MySQL General Mailing List
For list archives: http://lists.mysql.c
On Wed, 8 Jun 2005 21:57:25 -0600
"George Sexton" <[EMAIL PROTECTED]> wrote:
> I think MySQL has a little ways to go yet before I would
> subjectively call it best.
ok.
> I posted twice to the list with questions about porting my
> application that runs on (SQL Server, Oracle, PostgreSQL, Sybase
Jay Blanchard wrote:
[snip]
The issue with timestamp is this:
You can only have one timestamp with a default of the current date.
My app has two fields in one table
Created_datedatetime default now()
Last_update datetime default now()
This doesn't work with timestamp because t
On Wednesday 08 June 2005 10:57 pm, George Sexton wrote:
> 1)Why can't I declare a datetime field with DEFAULT NOW()
4.1 has options to default timestamps on update/inserts or both..
Jeff
pgp2pHd6mM2jF.pgp
Description: PGP signature
[snip]
The issue with timestamp is this:
You can only have one timestamp with a default of the current date.
My app has two fields in one table
Created_datedatetime default now()
Last_update datetime default now()
This doesn't work with timestamp because timestamp doesn't suppor
Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
> -Original Message-
> From: Jay Blanchard [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 09, 2005 5:56 AM
> To: George Sexton; mysql@lists.mysql.com
> Subject: RE: Seriously.. When are we going to ge
I think MySQL has a little ways to go yet before I would subjectively
call it best.
I posted twice to the list with questions about porting my application
that
runs on (SQL Server, Oracle, PostgreSQL, Sybase SQL Anywhere, MS Access,
and
DB2) to MySQL. No one on the mysql list, or the internals
[snip]
I think MySQL has a little ways to go yet before I would subjectively
call
it best.
I posted twice to the list with questions about porting my application
that
runs on (SQL Server, Oracle, PostgreSQL, Sybase SQL Anywhere, MS Access,
and
DB2) to MySQL. No one on the mysql list, or the intern
On 6/9/05, Kevin Burton wrote:
> Jeff Smelser wrote:
>>
>> Thats funny.. looks like it will be added to 5.1.. Dunno why they
think fixing
>> it is adding a feature..
>
> WOW! That's just insane! This seriously has to be fixed in 5.0 or sooner...
Chill out man. It is not like it is returning the
ilto:[EMAIL PROTECTED]
> Sent: Wednesday, June 08, 2005 10:16 AM
> To: Jeff Smelser; mysql@lists.mysql.com
> Subject: RE: Seriously.. When are we going to get subqueries?!
>
>
> The best open-source database on the market today? Free
> Constant improvements to database? Free
>
Greg Whalin wrote:
Granted, Kevin's tone was a bit harsh, but his sentiments should be
encouraged (frustration w/ a lack of feature). The concept that
people should be happy with what they get for a free product only
serves to keep the quality of free products below what they could be.
It w
Jeff Smelser wrote:
Thats funny.. looks like it will be added to 5.1.. Dunno why they think fixing
it is adding a feature..
WOW! That's just insane! This seriously has to be fixed in 5.0 or sooner...
The thing is that MySQL has both promised this feature and is claiming
that 5.0 is now
A long time ago when I was doing support for Lotus Notes, I was told that
the customer who 'complains' about legitimate bugs may be the most valuable
type of customer of all. This is because they care enough to vent. Who
knows how many unhappy customers one has if none ever complain? What if
al
AIL PROTECTED]
Sent: Wednesday, June 08, 2005 1:06 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; mysql@lists.mysql.com
Subject: Re: Seriously.. When are we going to get subqueries?!
Jay Blanchard wrote:
> [snip]
> On Wednesday 08 June 2005 11:16 am, you wrote:
>
>>[snip]
>>
[snip]
I personally find the idea that just because a product is free that
people are not allowed to...
[/snip]
I was just trying to fling a little humor on to the situation, not start
a flame war about who is right and what rights they do or do not have. I
too believe that criticism, in the prop
Jay Blanchard wrote:
[snip]
On Wednesday 08 June 2005 11:16 am, you wrote:
[snip]
Thats funny.. looks like it will be added to 5.1.. Dunno why they
think
fixing
it is adding a feature..
[/snip]
The best open-source database on the market today? Free
Constant improvements to database? Free
On Wednesday 08 June 2005 11:49 am, you wrote:
> Easy there boss, I was just responding to the thread and meant no
> offense. I saw the whole thing as funny.
Oh.. email sucks that way..
My apologies as well..
Jeff
pgpvHgJLsGjaw.pgp
Description: PGP signature
> [snip]
> Thats funny.. looks like it will be added to 5.1.. Dunno why they think
> fixing
> it is adding a feature..
> [/snip]
>
> The best open-source database on the market today? Free
> Constant improvements to database? Free
>
> Ability to complain when we don't get what we want? Priceless
[snip]
On Wednesday 08 June 2005 11:16 am, you wrote:
> [snip]
> Thats funny.. looks like it will be added to 5.1.. Dunno why they
think
> fixing
> it is adding a feature..
> [/snip]
>
> The best open-source database on the market today? Free
> Constant improvements to database? Free
>
> Ability to
On Wednesday 08 June 2005 11:16 am, you wrote:
> [snip]
> Thats funny.. looks like it will be added to 5.1.. Dunno why they think
> fixing
> it is adding a feature..
> [/snip]
>
> The best open-source database on the market today? Free
> Constant improvements to database? Free
>
> Ability to compla
[snip]
Thats funny.. looks like it will be added to 5.1.. Dunno why they think
fixing
it is adding a feature..
[/snip]
The best open-source database on the market today? Free
Constant improvements to database? Free
Ability to complain when we don't get what we want? Priceless
--
MySQL General
On Wednesday 08 June 2005 10:56 am, you wrote:
> In the last episode (Jun 08), Jeff Smelser said:
> > On Tuesday 07 June 2005 04:22 pm, Kevin Burton wrote:
> > > Subqueries in 4.1 are totally broken. They don't use indexes.
> > > They're evil. We're told we have subqueries but there's no way
> >
In the last episode (Jun 08), Jeff Smelser said:
> On Tuesday 07 June 2005 04:22 pm, Kevin Burton wrote:
> > Subqueries in 4.1 are totally broken. They don't use indexes.
> > They're evil. We're told we have subqueries but there's no way
> > anyone on earth could use them. To make matters worse
On Tuesday 07 June 2005 04:22 pm, Kevin Burton wrote:
> Subqueries in 4.1 are totally broken. They don't use indexes. They're
> evil. We're told we have subqueries but there's no way anyone on earth
> could use them. To make matters worse a lot of developers are TRICKED
> into using them and as
DBA wrote:
- Original Message -
From: "Kevin Burton" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, June 07, 2005 6:11 PM
Subject: Re: Seriously.. When are we going to get subqueries?!
Greg Whalin wrote:
They do use indexes if you use
- Original Message -
From: "Kevin Burton" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, June 07, 2005 6:11 PM
Subject: Re: Seriously.. When are we going to get subqueries?!
> Greg Whalin wrote:
>
>> They do use indexes if you use th
Greg Whalin wrote:
They do use indexes if you use them to build derived tables and are
pretty fast. The only case where I see them not using indexes when I
think they should is when you use a sub-query for an IN() clause.
I'm sorry.. yes.. They're not using indexes when within IN clauses whi
They do use indexes if you use them to build derived tables and are
pretty fast. The only case where I see them not using indexes when I
think they should is when you use a sub-query for an IN() clause.
Kevin Burton wrote:
OK...
Subqueries in 4.1 are totally broken. They don't use indexes.
OK...
Subqueries in 4.1 are totally broken. They don't use indexes. They're
evil. We're told we have subqueries but there's no way anyone on earth
could use them. To make matters worse a lot of developers are TRICKED
into using them and assume that mysql would do the right thing but its a
60 matches
Mail list logo
