Re: ALTER TEXT field to VARCHAR(1024)
От | Merlin Moncure |
---|---|
Тема | Re: ALTER TEXT field to VARCHAR(1024) |
Дата | |
Msg-id | CAHyXU0ywZwgbkB213fB1P1nViPsB7vq70HoZPWf99pj8-35PoQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ALTER TEXT field to VARCHAR(1024) (Bill Moran <wmoran@potentialtech.com>) |
Ответы |
Re: ALTER TEXT field to VARCHAR(1024)
|
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: