| From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
|---|---|
| To: | Bill Moran <wmoran(at)potentialtech(dot)com> |
| Cc: | Marius Grama <mariusneo(at)gmail(dot)com>, PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: ALTER TEXT field to VARCHAR(1024) |
| Date: | 2014-09-22 15:31:59 |
| Message-ID: | CAHyXU0ywZwgbkB213fB1P1nViPsB7vq70HoZPWf99pj8-35PoQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2014-09-22 15:34:10 | Re: Postgre SQL SHA-256 Compliance |
| Previous Message | Merlin Moncure | 2014-09-22 15:17:47 | Re: Postgre SQL SHA-256 Compliance |