Re: ALTER TEXT field to VARCHAR(1024)

Поиск
Список
Период
Сортировка
От Tim Clarke
Тема Re: ALTER TEXT field to VARCHAR(1024)
Дата
Msg-id 54204E5D.1020303@manifest.co.uk
обсуждение исходный текст
Ответ на Re: ALTER TEXT field to VARCHAR(1024)  (Rob Sargent <robjsargent@gmail.com>)
Список pgsql-general
On 22/09/14 17:18, Rob Sargent wrote:
> On 09/22/2014 09:40 AM, John McKown wrote:
>> On Mon, Sep 22, 2014 at 10:31 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
>>> On Fri, Sep 19, 2014 at 7:16 AM, Bill Moran <wmoran@potentialtech.com> wrote:
>>>> On Fri, 19 Sep 2014 09:32:09 +0200
>>>> Marius Grama <mariusneo@gmail.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.
>
>
>

Indeed - both is the answer; back-end (trigger) checks for safety,
front-end application polite messages for clarity and ease of use.

--
Tim Clarke



В списке pgsql-general по дате отправления:

Предыдущее
От: Rob Sargent
Дата:
Сообщение: Re: ALTER TEXT field to VARCHAR(1024)
Следующее
От: John McKown
Дата:
Сообщение: Re: ALTER TEXT field to VARCHAR(1024)