Re: ALTER TEXT field to VARCHAR(1024)

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: John McKown <john(dot)archie(dot)mckown(at)gmail(dot)com>
Cc: PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: ALTER TEXT field to VARCHAR(1024)
Date: 2014-09-23 06:56:28
Message-ID: CAMkU=1xVKc79XEcm+D--WaFWdMuNFOguhu=_k+5er2JtNFPerA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Sep 22, 2014 at 8:40 AM, John McKown <john(dot)archie(dot)mckown(at)gmail(dot)com>
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.
>

So fire them.

> 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 {
>

Your solution is what, arbitrarily forbidding the use of '[' when that is
not a logically forbidden character, just because someone might make a
mistake? What do you do when they wish that someone have "a lot of gun on
your vacation"?

Nothing ticks me off more than some DBA deciding that it is unreasonable
for my street address to be more than 25 characters long, when obviously
neither I nor the USPS agrees with that arbitrary limitation. Unless 25 is
the maximum number of characters that physically fit on the mailing label
(and you are sure you will never change label printers), it is not your job
to decide how long my street name can be. Get over yourself.

If you need to verify that the data is accurate, then implement methods to
verify that. Verifying that the data is "reasonable", according to some
ignorant standard of reasonableness, is not the same thing as verifying
that it is accurate.

More than one company has lost business by refusing to acknowledge that I
might know how to spell my own address.

Cheers,

Jeff, whose street address has 27 characters, whether you like it or not.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Craig Ringer 2014-09-23 08:36:39 Where art thou, plpython2.dll? (EDB installer)
Previous Message Abelard Hoffman 2014-09-23 06:29:06 Re: Installing Postgresql on Linux Friendlyarm