From: | David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: ALTER TEXT field to VARCHAR(1024) |
Date: | 2014-09-22 17:11:18 |
Message-ID: | 1411405878861-5819939.post@n5.nabble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Merlin Moncure-2 wrote
> On Mon, Sep 22, 2014 at 10:40 AM, John McKown
> <
> john.archie.mckown@
> > wrote:
>> On Mon, Sep 22, 2014 at 10:31 AM, Merlin Moncure <
> mmoncure@
> > wrote:
>>> 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 {
>
> Sure. The point is distinguishing things which are *demonstrably*
> false (like a US VIN must be exactly 17 chars) from those that are
> based assumption (such as a cityname must be <= 50 characters). The
> former should be validated in the schema and the latter should not be.
> If you're paranoid about the user submitting 100mb strings for
> "username" and don't trust the application to deal with that, I'd
> maybe consider making a domain 'safetext' which checks length on the
> order of a few thousand bytes and using that instead of 'text' and use
> it everywhere. This will prevent the dba from outsmarting the
> datamodel which is a *much* bigger problem in practice than the one
> length checks attempt to solve.
>
> Domains have certain disadvantages (like no array type) -- be advised.
>
> merlin
These responses all seem beside the point. The OP isn't concerned that
too-long data is making it into the database but rather that an unadorned
text type is functionally a CLOB which the application he is using is
treating like a document instead of a smallish text field that would be
treated like any other value. It's like the difference between choosing
input/text or textarea in HTML. Now, some tools distinguish between "text"
and "varchar" only and the length piece is irrelevant; but whether that
applies here I have no idea.
It might be easier to simply create a view over the table, using the desired
type (truncating the actual value if needed), and feed that view to the
reporting engine.
In the end the two questions are:
1) does adding a length restriction cause a table rewrite?
2) what level of locking occurs while the length check is resolving?
I don't confidently know the answers to those two questions.
David J.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/ALTER-TEXT-field-to-VARCHAR-1024-tp5819608p5819939.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-09-22 17:22:25 | Re: ALTER TEXT field to VARCHAR(1024) |
Previous Message | Karsten Hilbert | 2014-09-22 17:03:17 | Re: Postgre SQL SHA-256 Compliance |