Hi Pete. I'm in no big hurry, but I don't wish to miss anything. Do
you have any news about default values on blobs?
- chad
On 13 Mar 2007, at 15:57, Pete Harlan wrote:
>> 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
--
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
Attachment: [application/pgp-signature] This is a digitally signed message part PGP.sig
