On 09/22/2014 09:40 AM, John McKown wrote:
> On Mon, Sep 22, 2014 at 10:31 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> On Fri, Sep 19, 2014 at 7:16 AM, Bill Moran <wmoran(at)potentialtech(dot)com> wrote:
>>> On Fri, 19 Sep 2014 09:32:09 +0200
>>> Marius Grama <mariusneo(at)gmail(dot)com> wrote:
>>>> Can anybody explain me what happens in the background when the alter
>>>> statement is executed? I've tried it out on a small copy of the table (70K)
>>>> and the operation completed in 0.2 seconds.
>>>> Will the table be completely locked during the execution of the ALTER
>>>> statement?
>>> I share Gavin's concern that you're fixing this in the wrong place. I expect
>>> that you'll be better served by configuring the middleware to do the right thing.
>> I'll pile on here: in almost 20 years of professional database
>> development I've never had an actual problem that was solved by
>> introducing or shortening a length constraint to text columns except
>> in cases where overlong strings violate the data model (like a two
>> character state code for example). It's a database equivalent of "C
>> programmer's disease". Input checks from untrusted actors should
>> happen in the application.
>>
>> merlin
>>
> I do not have your experience level with data bases, but if I may, I
> will make an addition. Input checks should also happen in the RDBMS
> server. I have learned you cannot trust end users _or_ programmers.
> Most are good and conscientious. But there are a few who just aren't.
> And those few seem to be very prolific in making _subtle_ errors. Had
> one person who was really good at replacing every p with a [ and P
> with {
>
>
You don't want that string to get all the way to the server and fail,
blow out a transaction and carry that joyous news back to the user who
now has to start over completely. Further no mear length constraint is
going to fix p<=>[. Not say the db cannot have the constraint (no [
allowed?) but a good app checks input on the fly.