On 09/22/2014 09:40 AM, John McKown
wrote:
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.On Mon, Sep 22, 2014 at 10:31 AM, Merlin Moncure <mmoncure@xxxxxxxxx> wrote:On Fri, Sep 19, 2014 at 7:16 AM, Bill Moran <wmoran@xxxxxxxxxxxxxxxxx> wrote:On Fri, 19 Sep 2014 09:32:09 +0200 Marius Grama <mariusneo@xxxxxxxxx> 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. merlinI 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 { |