Sorry guess I wasn't being as clear as I thought. To be a bit more
precise, I really think that validation should occur _first_ at the
point of entry (for a web browser, I put in Javascript code to verify
it there as well as in the web service doing the same validation
because some people disable Javascript as a possible security breach
vector), then also do the same, or even more, validation in the back
end server. I.e. don't trust any step of the process which is not
under your immediate control. As the "owner" of the data base, I want
to validate the data "myself" according to the proper business rules.
The application developer should also validate the input. What I don't
believe in is a "trusted application" from which I would accept data
and not validate it before updating the data base. If such an
application were to exist, due to management dictum, I would audit
everything that I could to prove any corruption to the data base was
caused by this "can't ever be wrong" application. Yes, I am a
paranoid.
On Mon, Sep 22, 2014 at 11:18 AM, Rob Sargent <robjsargent@xxxxxxxxx> wrote:
> On 09/22/2014 09:40 AM, John McKown wrote:
>
> 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.
>
> 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.
>
>
>
--
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan
Maranatha! <><
John McKown
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
