> Anyway, do you agree, Pete, that adding BLOB DEFAULT '' makes more
> sense, from a maintenance standpoint?
Very much so! I think being able to specify a default value for blobs
is a far superior solution than adding a new SQL mode. Whenever given
a choice between adding a new feature and removing the constraint that
made that feature appear necessary, removing the constraint is usually
the best option.
The reason I didn't look into doing that originally is that it's such
an obvious thing to implement that I assumed by its absence that there
are fundamental reasons why it hadn't been done. (E.g., if adding
that functionality required a non-backwards-compatible change to the
on-disk format for table schemas, or if the SQL spec disallows
defaults for blob columns.)
If you don't foresee such obstacles to allowing the user to specify a
default for blob columns, that's terrific.
> Do you think you'd be interested in working on it?
I am brand-new to looking at the MySQL source. I'm comfortable and
experienced with C++ and development generally, but if someone with
more MySQL experience and/or more time also is interested in that
project, that might make more sense than my doing it.
If I am to work on it, is there internal documentation besides the
source code itself that might assist me? It's not necessary, but if
there is, that could help.
Also, the free BitKeeper client isn't particularly useful. It's fine
for pulling the latest sources, but it doesn't look like you can use
it to, e.g., show uncommited changes you have made to your working
tree. If I am going to develop more than just a tiny patch, I'll want
to use real version control.
As commercial BitKeeper is out for me (I have thoughts about hacking
"git" or Subversion from time to time, so unless Larry has changed
what used to be worst-in-class licensing terms, I'm not allowed to use
BK), do you have any standard recommendations for people? I can
manage my own local mirror of the MySQL sources easily enough, but
perhaps there's some other option community developers use.
Many thanks,
--Pete
On Tue, Mar 13, 2007 at 03:26:16PM -0400, Chad MILLER wrote:
> On 12 Mar 2007, at 11:57, Chad MILLER wrote:
> >Hi Pete. Leaving aside for a moment the architectural decisions
> >(which I'll ask about internally), here's my review of the patch.
>
> On 13 Mar 2007, at 14:47, Chad MILLER wrote:
> >On 13 Mar 2007, at 14:28, Pete Harlan wrote:
> >>Thank you very much for reviewing my patch. I'll come up with
> >>another
> >>one to address your points, and I'll submit it with a feature-request
> >>bug report as you suggest.
> >
> >Hi Pete. Great! To be clear for others, you did the right thing
> >in mailing first. I'd rather see the idea posted before a bug
> >filed to track it.
>
>
> Alright Pete, good(-ish) news and bad news:
>
> I heard from our architectural gurus, and the verdict is that
> additional sql_modes are Bad. In this case, you're trying to work
> around the fact that BLOBs don't take default values. The correct
> solution, then is to change that, rather than pack "emptiness" and
> "defaultness" -- two bits of information -- into one bit of a SQL
> mode. Imagine the next person wanting ZERO_DEFAULT_FOR_BLOB, et c.
> Those are headaches we want to avoid, and so we wouldn't apply the
> patch as you've suggested. Sorry!
>
> The good news is that I can't think of a reason that adding support
> for default values for BLOBs would be hard. It's a bit of a mystery
> to me that it isn't implemented, to be honest. It's probably a hold-
> over from the pre-5.0 days. Unifying the types so they all work the
> same is a task that's both "sexy" and obviously right, and it
> probably rips out some special-case code. What's not to like?!
>
> Anyway, do you agree, Pete, that adding BLOB DEFAULT '' makes more
> sense, from a maintenance standpoint? Do you think you'd be
> interested in working on it?
>
> - chad
>
> --
> Chad Miller, Software Developer chad@stripped
> MySQL Inc., www.mysql.com
> Orlando, Florida, USA 13-20z, UTC-0400
> Office: +1 408 213 6740 sip:6740@stripped
