Unix Technical Forum

SQL standards in Mysql

This is a discussion on SQL standards in Mysql within the pgsql Sql forums, part of the PostgreSQL category; --> Here's one Mysql developer's response to adding (fixing) the integer/bigint/tinyint types to their CAST function: http://bugs.mysql.com/bug.php?id=34562 ---------------------------(end of broadcast)--------------------------- ...


Go Back   Unix Technical Forum > Database Server Software > PostgreSQL > pgsql Sql

Register FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-19-2008, 06:01 PM
Ken Johanson
 
Posts: n/a
Default SQL standards in Mysql

Here's one Mysql developer's response to adding (fixing) the
integer/bigint/tinyint types to their CAST function:

http://bugs.mysql.com/bug.php?id=34562




---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #2 (permalink)  
Old 04-19-2008, 06:01 PM
Alvaro Herrera
 
Posts: n/a
Default Re: SQL standards in Mysql

Ken Johanson wrote:
> Here's one Mysql developer's response to adding (fixing) the
> integer/bigint/tinyint types to their CAST function:
>
> http://bugs.mysql.com/bug.php?id=34562


So they are anal too, but in the opposite direction?

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #3 (permalink)  
Old 04-19-2008, 06:01 PM
Scott Marlowe
 
Posts: n/a
Default Re: SQL standards in Mysql

On Fri, Feb 22, 2008 at 1:57 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Ken Johanson wrote:
> > Here's one Mysql developer's response to adding (fixing) the
> > integer/bigint/tinyint types to their CAST function:
> >
> > http://bugs.mysql.com/bug.php?id=34562

>
> So they are anal too, but in the opposite direction?


No, they're just hopelessly lost and making good time. Or lazy. Or
both. I'm not sure.

There's example after example of things in the mysql bug database that
should make anyone considering it as a database engine cringe and walk
away shaking their head. for instance, someone JUST submitted this
bug:

http://bugs.mysql.com/bug.php?id=34231

Which is about a problem with the mysql packages including a
statically linked zlib which makes it impossible to compile php
against it. Problem is, their inability to properly package / not
package zlib with mysql is an ongoing problem. As far back as 2004 it
showed up. Then was fixed, then showed up again, then was fixed.

Here's the most recent "we fixed it! Oh shit it's broken again" bug record:

http://bugs.mysql.com/bug.php?id=15255

Before that we had

http://bugs.mysql.com/bug.php?id=3700

After that we had

http://bugs.mysql.com/bug.php?id=28569

and now the latest reports. It's like the Keystone Kops create RPM
packages reading those messages. Pick any subject area. Foreign
keys, SQL compliance, and on and on and you'll find dozens of the same
bugs coming and going as one person stomps it and another apparently
reinstates it.

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #4 (permalink)  
Old 04-19-2008, 06:01 PM
Dean Gibson
 
Posts: n/a
Default Re: SQL standards in Mysql

On 2008-02-22 16:13, Scott Marlowe wrote:
> There's example after example of things in the mysql bug database that should make anyone considering it as a database engine cringe and walk away shaking their head.

I don't understand why anyone wanting a real SQL DB would pick MySQL.

Four years ago I knew nothing about SQL (I still pronounce it S-Q-L),
but wanted to set up a real DB with the maximum flexibility. So, I:

1. Asked a friend in the DB world (primarily Oracle) what he
recommended, and he said "MySQL".
2. I then bought a book on SQL ("Using SQL", by Rafe Colburn, ISBN
0-7897-1974-6, © 2000 Que Publishing), which mentions every common SQL
DB __except__ PostgreSQL.

So, I went with PostgreSQL. Why? From the book, it was clear that
MySQL lacked so many features of a decent SQL DB. In particular (at the
time) VIEWs and sub-selects. I didn't know much about VIEWs and
sub-selects, but it appeared to me that they were pretty
important/powerful features that any SQL DB should have. PostgreSQL was
the only one left standing (at least on my budget). (I ran it on a
Pentium 233 for a year before I upgraded the hardware.)

As of now, MySQL has VIEWs and sub-selects, but there appear to be a
number of other little "gotchas" that lurk (which the original poster of
this and the related threads has so amply illustrated). One of the
advantage of standards-compliant software is that, while you may be
surprised by some feature, that feature has been examined by a number of
people and (typically) found to be the best way of being consistent in a
broader view, rather than a feature that has been written (or not) for
the sake of expediency in a particular implementation. Further, many
standards are features that, while sometimes not met by existing
implementations, are at least a goal of consistency and functionality
that is aspired to (and usually planned for in future releases).

The sad fact is that we live in a world of expediency (not to mention a
bit of hype). Many people don't even do the elementary research that I
did before glibly picking a DB for their server, in their rush to be the
next dot-com (or other) success. As a result, PostgreSQL is not
supported by some software packages. For example, I think phpBB is the
only major message board software that supports PostgreSQL (see
http://www.phpbb.com/about/features/compare.php ), and in fact has for
some time. Of course, they have a DB abstraction layer (wow, what an
concept!), which allows them to easily support a number of DBs. Of
course, what does that tell you about the level of design and
professionalism of phpBB versus the others? Note that I have no
connection with the phpBB project, and in fact find many of the
developers arrogant. I'm just saying that any software that doesn't
support a number of DBs probably wasn't designed and/or implemented
properly.

Hopefully, some event in the near future will tip the scales in the
public perception of SQL DBs, and PostgreSQL will get better respect.

-- Dean

--
Mail to my list address MUST be sent via the mailing list.
All other mail to my list address will bounce.


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #5 (permalink)  
Old 04-19-2008, 06:01 PM
Scott Marlowe
 
Posts: n/a
Default Re: SQL standards in Mysql

On Fri, Feb 22, 2008 at 7:39 PM, Dean Gibson (DB Administrator)
<postgresql@ultimeth.com> wrote:
> So, I went with PostgreSQL. Why? From the book, it was clear that
> MySQL lacked so many features of a decent SQL DB. In particular (at the
> time) VIEWs and sub-selects.


Note that unless someone's done some hacking recently, mysql uses
nested loops for subselects. Which is fine for a few dozen or hundred
entries. not so much for 1M rows. Handling subselects is as much
about performance as it is about convenience. There was a time a few
years ago when oracle would beat the pants off postgresql or mysql if
you did this:

delete from tablea where id in (select id from tableb);

when tableb was pretty large. PostgreSQL hackers fixed that issue
some time ago. MySQL, as far as I know, has no plans to fix their
poor performance. Because somebody checked off subselect and that's
all they needed, a check box.

> the only one left standing (at least on my budget). (I ran it on a
> Pentium 233 for a year before I upgraded the hardware.)


Oh man, this takes me back. My first two postgresql servers were both
pg v6.5.3 or so and ran on:

Pentium-100 with 64 Meg of ram,
Quad CPU Sparc-20 (4x50MHz CPUs) with a stack of SCSI hard drives
running the last version of RH to support sparc back then.

> supported by some software packages. For example, I think phpBB is the
> only major message board software that supports PostgreSQL (see
> http://www.phpbb.com/about/features/compare.php ), and in fact has for
> some time. Of course, they have a DB abstraction layer (wow, what an
> concept!), which allows them to easily support a number of DBs. Of
> course, what does that tell you about the level of design and
> professionalism of phpBB versus the others? Note that I have no
> connection with the phpBB project, and in fact find many of the
> developers arrogant. I'm just saying that any software that doesn't
> support a number of DBs probably wasn't designed and/or implemented
> properly.


Well, somebody needs to teach them how this thing called patch works.
The fact that all the hacks are installed by hand makes me queezy
about messing with any modifications.

Note that w-agora is a pretty nice bbs that supports mysql, oracle,
and pgsql. I like the interface, but it doesn't look like there's a
lot of recent development on it. I like the fact that it uses a nice
threaded interface and can work with oracle, pgsql, or mysql.

> Hopefully, some event in the near future will tip the scales in the
> public perception of SQL DBs, and PostgreSQL will get better respect.


I think it's slowly happening, not one big event, but a bunch of
little experiences adding up. I think one of the things helping that
in the long run is the number of very capable DBAs that are slowly
coming to pgsql from other dbs, like DB2 or Oracle or Informix.

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #6 (permalink)  
Old 04-19-2008, 06:01 PM
Scott Marlowe
 
Posts: n/a
Default Re: SQL standards in Mysql

On Fri, Feb 22, 2008 at 11:03 PM, Mail Delivery Subsystem
<mailer-daemon@googlemail.com> wrote:
> This is an automatically generated Delivery Status Notification
>
> Delivery to the following recipient failed permanently:
>
> postgresql@ultimeth.com
> To: "Dean Gibson (DB Administrator)" <postgresql@ultimeth.com>


Look, if you're going to send email to this list from an address that
doesn't accept email from anything but this list, and since this list
by default is a "reply to all" list (i.e. people hit reply to all) the
LEAST you can do is reconfigure your Mail client to change the reply
to field to point to whatever list it is you are sending to. Or have
the decency to program your MTA to just throw those messages away.
Bouncing messages from a public list is kinda rude.

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #7 (permalink)  
Old 04-19-2008, 06:01 PM
Tom Lane
 
Posts: n/a
Default Re: SQL standards in Mysql

Ken Johanson <pg-user@kensystem.com> writes:
> Here's one Mysql developer's response to adding (fixing) the
> integer/bigint/tinyint types to their CAST function:


> http://bugs.mysql.com/bug.php?id=34562


Hmm ... while I'm certainly not someone to defend mysql on a regular
basis, I can see their point of view here. They are supporting a
limited (and clearly documented) subset of the SQL spec in this area,
so it's surely a feature request rather than a bug that they don't
support more. The disagreement seems to come down to what the priority
of the feature addition ought to be. We have a few sore spots of our
own on questions like this one, so I'm disinclined to throw the first
stone ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #8 (permalink)  
Old 04-19-2008, 06:01 PM
Aarni =?utf-8?q?Ruuhim=C3=A4ki?=
 
Posts: n/a
Default Re: SQL standards in Mysql

On Saturday 23 February 2008 07:50, Tom Lane wrote:
>Hmm ... while ...
> so I'm disinclined to throw the first
> stone ...


Meanwhile,

Throw cones, not stones.

http://cfx.kymi.com/lotsacones.jpg

These things/projectiles hurt not so much. And it's fun !

BR,

--
Aarni Ruuhimäki

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #9 (permalink)  
Old 04-19-2008, 06:01 PM
Dean Gibson
 
Posts: n/a
Default Re: Bouncing replies [was: SQL standards in Mysql]

On 2008-02-22 21:34, Scott Marlowe wrote:

> Bouncing messages from a public list is kinda rude.
>

No more so, than sending two copies of your reply to me, because you
don't go up to your mailer's "To:" line and manually delete the extra
address (as I do on EVERY reply I send to this list).

In fact, if you do that, you won't get the bounce. I do it out of
consideration for others: since _I_ would prefer to not receive two
copies of replies, I assume that _others_ prefer the same. I don't whine
about it; I just do it.

So, in return for that consideration, I get your reply. How did getting
the bounce hurt you or your computer, or make any extra work for you,
more than I would have to do when I get a duplicate message????

Perhaps I've been working with computers too long. I've been PAID as a
full-time software developer for the past 40 years (45 if you count
part-time employment in college), and I'm AMAZED at the amount of
intolerance I see on the Internet with respect to eMails. Some people
whine because the reply is at the top of the message rather than at the
bottom. There are perfectly good reasons for replying at the top OR at
the bottom, depending upon the circumstances. Other people whine
because the sender does not wrap his/her eMail at 76 columns, or because
the eMail is ALL CAPS, or some other imagined slight. Being an
ADAPTABLE human being, rather than UPSET people who aren't similarly
inclined, I simply ADAPT to the environment in most cases.

In this particular case:

>
> Look, if you're going to send email to this list from an address that doesn't accept email from anything but this list, and since this list by default is a "reply to all" list (i.e. people hit reply to all) the LEAST you can do is reconfigure your Mail client to change the reply to field to point to whatever list it is you are sending to.

A good idea, but I use this eMail address to reply to multiple pgsql-xxx
lists. That would require a separate sender address for each list, but
I can do that if I'm really hurting other people. It just means that I
will have to delete the duplicate replies, rather than have to hear
about the problems (which have yet to be identified) the bounces causes
other people. I'll consider it.


> Or have the decency to program your MTA to just throw those messages away.
>

That's a universally discredited idea among mail administrators: You
either reject unwanted mail _during_the_SMTP_dialog_, or you forward it
on to the recipient. The former is strongly preferred for dealing with
spam (which is why I bounce non-list replies), to avoid the bandwidth,
storage, and other issues.

Now, for anyone who can't deal with the above, either:

1. don't reply to my posts;
2. edit the "To:" line in your replies to me; or
3. send me your eMail address and I will manually whitelist you (note
that the whitelisting will disappear if some spammer uses your eMail
address to circumvent the bounces). In fact, I'm surprised that
spammers don't already do that using one of the administrator accounts
here. My eMail address here has been one of the largest targets for the
spam my SMTP server rejects over the past few years, and I haven't even
been very active here.

Sincerely, Dean

--
Mail to my list address MUST be sent via the mailing list.
All other mail to my list address will bounce.


Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #10 (permalink)  
Old 04-19-2008, 06:01 PM
Dave Page
 
Posts: n/a
Default Re: Bouncing replies [was: SQL standards in Mysql]

On Mon, Feb 25, 2008 at 9:08 PM, Dean Gibson (DB Administrator)
<postgresql@ultimeth.com> wrote:
>
> On 2008-02-22 21:34, Scott Marlowe wrote:
>
>
> Bouncing messages from a public list is kinda rude.
>
> No more so, than sending two copies of your reply to me, because you don't
> go up to your mailer's "To:" line and manually delete the extra address (as
> I do on EVERY reply I send to this list).


It is considered polite to follow the customs of the groups in which
one participates. For example, if you meet with Japanese people as
part of your work you should bow whilst exchanging business cards,
take care to read the card you are given, and not place it in the back
pocket of your trousers.

In this group we use the mj2 mailing list manager which by default
will not send you a direct copy of any message which also has your
email address explicitly listed. We prefer to use reply-all when
responding to people, and that has become the custom here. It would be
appreciated if you respected that custom during your time with us.

Regards, Dave

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 06:33 AM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
SEO by vBSEO 3.2.0
www.UnixAdminTalk.com