Should we validate max length on string fields?












-2















We have a validation in our application limiting user first and last name length to 255 characters. Is there any technical reason we ought to be doing this? I'm wondering if there is maybe any security concern or risk we put ourselves at by not limiting the length of strings. We're using Postgres text columns.






postgresql







share|improve this question























  • If this is a business constraint, then yes you should reflect that in a database constraint as well. If you are indexing the columns you probably should limit the length as well. Note that there is no optimization whatsoever for column defined as varchar(255) over a column defined as varchar(260) or varchar(301) - that 255 is a left-over "magic number" that does have any performance impact

    – a_horse_with_no_name
    Nov 23 '18 at 7:40













  • Related: stackoverflow.com/questions/8295131

    – a_horse_with_no_name
    Nov 23 '18 at 7:43
















-2















We have a validation in our application limiting user first and last name length to 255 characters. Is there any technical reason we ought to be doing this? I'm wondering if there is maybe any security concern or risk we put ourselves at by not limiting the length of strings. We're using Postgres text columns.






postgresql







share|improve this question























  • If this is a business constraint, then yes you should reflect that in a database constraint as well. If you are indexing the columns you probably should limit the length as well. Note that there is no optimization whatsoever for column defined as varchar(255) over a column defined as varchar(260) or varchar(301) - that 255 is a left-over "magic number" that does have any performance impact

    – a_horse_with_no_name
    Nov 23 '18 at 7:40













  • Related: stackoverflow.com/questions/8295131

    – a_horse_with_no_name
    Nov 23 '18 at 7:43














-2












-2








-2








We have a validation in our application limiting user first and last name length to 255 characters. Is there any technical reason we ought to be doing this? I'm wondering if there is maybe any security concern or risk we put ourselves at by not limiting the length of strings. We're using Postgres text columns.






postgresql







share|improve this question














We have a validation in our application limiting user first and last name length to 255 characters. Is there any technical reason we ought to be doing this? I'm wondering if there is maybe any security concern or risk we put ourselves at by not limiting the length of strings. We're using Postgres text columns.






postgresql




postgresql






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 22 '18 at 23:37









lobatilobati

2,61932241




2,61932241













  • If this is a business constraint, then yes you should reflect that in a database constraint as well. If you are indexing the columns you probably should limit the length as well. Note that there is no optimization whatsoever for column defined as varchar(255) over a column defined as varchar(260) or varchar(301) - that 255 is a left-over "magic number" that does have any performance impact

    – a_horse_with_no_name
    Nov 23 '18 at 7:40













  • Related: stackoverflow.com/questions/8295131

    – a_horse_with_no_name
    Nov 23 '18 at 7:43



















  • If this is a business constraint, then yes you should reflect that in a database constraint as well. If you are indexing the columns you probably should limit the length as well. Note that there is no optimization whatsoever for column defined as varchar(255) over a column defined as varchar(260) or varchar(301) - that 255 is a left-over "magic number" that does have any performance impact

    – a_horse_with_no_name
    Nov 23 '18 at 7:40













  • Related: stackoverflow.com/questions/8295131

    – a_horse_with_no_name
    Nov 23 '18 at 7:43

















If this is a business constraint, then yes you should reflect that in a database constraint as well. If you are indexing the columns you probably should limit the length as well. Note that there is no optimization whatsoever for column defined as varchar(255) over a column defined as varchar(260) or varchar(301) - that 255 is a left-over "magic number" that does have any performance impact

– a_horse_with_no_name
Nov 23 '18 at 7:40







If this is a business constraint, then yes you should reflect that in a database constraint as well. If you are indexing the columns you probably should limit the length as well. Note that there is no optimization whatsoever for column defined as varchar(255) over a column defined as varchar(260) or varchar(301) - that 255 is a left-over "magic number" that does have any performance impact

– a_horse_with_no_name
Nov 23 '18 at 7:40















Related: stackoverflow.com/questions/8295131

– a_horse_with_no_name
Nov 23 '18 at 7:43





Related: stackoverflow.com/questions/8295131

– a_horse_with_no_name
Nov 23 '18 at 7:43












1 Answer
1






active

oldest

votes


















1














Text = variable unlimited length.. If you put limiter why don't use varchar(255)?



For security concern and performance put limiter are good. If your database file heavy and if someone spams to your text, the data type exceeds 8 KB.. That will put heavy in your db and for worst scenario it can Break Down..



EDIT :



As Documentation says:




If you desire to store long strings with no specific upper limit, use
text or character varying without a length specifier, rather than
making up an arbitrary length limit.




Back to your original question "Should we validate max length on string fields"?



When see documentation said.. It would be better you make as Varchar(255) rather than Varchar without length specifier and do limiter in application side



And for performance:




Long strings are compressed by the system automatically, so the
physical requirement on disk might be less. Very long values are also
stored in background tables so that they do not interfere with rapid
access to shorter column values.




I will say great for Postgresql :)






share|improve this answer


























  • The PostgreSQL docs actually suggest that text is no less performant, though, if you need something variable length, and may be better since they don't need to check the length before storing a value. See the Tip here: postgresql.org/docs/10/datatype-character.html

    – lobati
    Nov 23 '18 at 2:38











  • @lobati yes.. I am already read that.. about performance which is great postgresql.. And said If you desire to store long strings with no specific upper limit, use text or character varying without a length specifier, rather than making up an arbitrary length limit...

    – dwir182
    Nov 23 '18 at 2:53











  • I can't see how you could "break down" the database by supplying long strings.

    – a_horse_with_no_name
    Nov 23 '18 at 7:40











  • Yes.. I want to remove that @a_horse_with_no_name but if i remove the first argument i show i think that's not good.. That's just my speculation.. If i am wrong you can dv me.. :)

    – dwir182
    Nov 23 '18 at 7:44











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53439104%2fshould-we-validate-max-length-on-string-fields%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









1














Text = variable unlimited length.. If you put limiter why don't use varchar(255)?



For security concern and performance put limiter are good. If your database file heavy and if someone spams to your text, the data type exceeds 8 KB.. That will put heavy in your db and for worst scenario it can Break Down..



EDIT :



As Documentation says:




If you desire to store long strings with no specific upper limit, use
text or character varying without a length specifier, rather than
making up an arbitrary length limit.




Back to your original question "Should we validate max length on string fields"?



When see documentation said.. It would be better you make as Varchar(255) rather than Varchar without length specifier and do limiter in application side



And for performance:




Long strings are compressed by the system automatically, so the
physical requirement on disk might be less. Very long values are also
stored in background tables so that they do not interfere with rapid
access to shorter column values.




I will say great for Postgresql :)






share|improve this answer


























  • The PostgreSQL docs actually suggest that text is no less performant, though, if you need something variable length, and may be better since they don't need to check the length before storing a value. See the Tip here: postgresql.org/docs/10/datatype-character.html

    – lobati
    Nov 23 '18 at 2:38











  • @lobati yes.. I am already read that.. about performance which is great postgresql.. And said If you desire to store long strings with no specific upper limit, use text or character varying without a length specifier, rather than making up an arbitrary length limit...

    – dwir182
    Nov 23 '18 at 2:53











  • I can't see how you could "break down" the database by supplying long strings.

    – a_horse_with_no_name
    Nov 23 '18 at 7:40











  • Yes.. I want to remove that @a_horse_with_no_name but if i remove the first argument i show i think that's not good.. That's just my speculation.. If i am wrong you can dv me.. :)

    – dwir182
    Nov 23 '18 at 7:44
















1














Text = variable unlimited length.. If you put limiter why don't use varchar(255)?



For security concern and performance put limiter are good. If your database file heavy and if someone spams to your text, the data type exceeds 8 KB.. That will put heavy in your db and for worst scenario it can Break Down..



EDIT :



As Documentation says:




If you desire to store long strings with no specific upper limit, use
text or character varying without a length specifier, rather than
making up an arbitrary length limit.




Back to your original question "Should we validate max length on string fields"?



When see documentation said.. It would be better you make as Varchar(255) rather than Varchar without length specifier and do limiter in application side



And for performance:




Long strings are compressed by the system automatically, so the
physical requirement on disk might be less. Very long values are also
stored in background tables so that they do not interfere with rapid
access to shorter column values.




I will say great for Postgresql :)






share|improve this answer


























  • The PostgreSQL docs actually suggest that text is no less performant, though, if you need something variable length, and may be better since they don't need to check the length before storing a value. See the Tip here: postgresql.org/docs/10/datatype-character.html

    – lobati
    Nov 23 '18 at 2:38











  • @lobati yes.. I am already read that.. about performance which is great postgresql.. And said If you desire to store long strings with no specific upper limit, use text or character varying without a length specifier, rather than making up an arbitrary length limit...

    – dwir182
    Nov 23 '18 at 2:53











  • I can't see how you could "break down" the database by supplying long strings.

    – a_horse_with_no_name
    Nov 23 '18 at 7:40











  • Yes.. I want to remove that @a_horse_with_no_name but if i remove the first argument i show i think that's not good.. That's just my speculation.. If i am wrong you can dv me.. :)

    – dwir182
    Nov 23 '18 at 7:44














1












1








1







Text = variable unlimited length.. If you put limiter why don't use varchar(255)?



For security concern and performance put limiter are good. If your database file heavy and if someone spams to your text, the data type exceeds 8 KB.. That will put heavy in your db and for worst scenario it can Break Down..



EDIT :



As Documentation says:




If you desire to store long strings with no specific upper limit, use
text or character varying without a length specifier, rather than
making up an arbitrary length limit.




Back to your original question "Should we validate max length on string fields"?



When see documentation said.. It would be better you make as Varchar(255) rather than Varchar without length specifier and do limiter in application side



And for performance:




Long strings are compressed by the system automatically, so the
physical requirement on disk might be less. Very long values are also
stored in background tables so that they do not interfere with rapid
access to shorter column values.




I will say great for Postgresql :)






share|improve this answer















Text = variable unlimited length.. If you put limiter why don't use varchar(255)?



For security concern and performance put limiter are good. If your database file heavy and if someone spams to your text, the data type exceeds 8 KB.. That will put heavy in your db and for worst scenario it can Break Down..



EDIT :



As Documentation says:




If you desire to store long strings with no specific upper limit, use
text or character varying without a length specifier, rather than
making up an arbitrary length limit.




Back to your original question "Should we validate max length on string fields"?



When see documentation said.. It would be better you make as Varchar(255) rather than Varchar without length specifier and do limiter in application side



And for performance:




Long strings are compressed by the system automatically, so the
physical requirement on disk might be less. Very long values are also
stored in background tables so that they do not interfere with rapid
access to shorter column values.




I will say great for Postgresql :)







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 23 '18 at 7:42









a_horse_with_no_name

305k46466562




305k46466562










answered Nov 23 '18 at 0:30









dwir182dwir182

1,445619




1,445619













  • The PostgreSQL docs actually suggest that text is no less performant, though, if you need something variable length, and may be better since they don't need to check the length before storing a value. See the Tip here: postgresql.org/docs/10/datatype-character.html

    – lobati
    Nov 23 '18 at 2:38











  • @lobati yes.. I am already read that.. about performance which is great postgresql.. And said If you desire to store long strings with no specific upper limit, use text or character varying without a length specifier, rather than making up an arbitrary length limit...

    – dwir182
    Nov 23 '18 at 2:53











  • I can't see how you could "break down" the database by supplying long strings.

    – a_horse_with_no_name
    Nov 23 '18 at 7:40











  • Yes.. I want to remove that @a_horse_with_no_name but if i remove the first argument i show i think that's not good.. That's just my speculation.. If i am wrong you can dv me.. :)

    – dwir182
    Nov 23 '18 at 7:44



















  • The PostgreSQL docs actually suggest that text is no less performant, though, if you need something variable length, and may be better since they don't need to check the length before storing a value. See the Tip here: postgresql.org/docs/10/datatype-character.html

    – lobati
    Nov 23 '18 at 2:38











  • @lobati yes.. I am already read that.. about performance which is great postgresql.. And said If you desire to store long strings with no specific upper limit, use text or character varying without a length specifier, rather than making up an arbitrary length limit...

    – dwir182
    Nov 23 '18 at 2:53











  • I can't see how you could "break down" the database by supplying long strings.

    – a_horse_with_no_name
    Nov 23 '18 at 7:40











  • Yes.. I want to remove that @a_horse_with_no_name but if i remove the first argument i show i think that's not good.. That's just my speculation.. If i am wrong you can dv me.. :)

    – dwir182
    Nov 23 '18 at 7:44

















The PostgreSQL docs actually suggest that text is no less performant, though, if you need something variable length, and may be better since they don't need to check the length before storing a value. See the Tip here: postgresql.org/docs/10/datatype-character.html

– lobati
Nov 23 '18 at 2:38





The PostgreSQL docs actually suggest that text is no less performant, though, if you need something variable length, and may be better since they don't need to check the length before storing a value. See the Tip here: postgresql.org/docs/10/datatype-character.html

– lobati
Nov 23 '18 at 2:38













@lobati yes.. I am already read that.. about performance which is great postgresql.. And said If you desire to store long strings with no specific upper limit, use text or character varying without a length specifier, rather than making up an arbitrary length limit...

– dwir182
Nov 23 '18 at 2:53





@lobati yes.. I am already read that.. about performance which is great postgresql.. And said If you desire to store long strings with no specific upper limit, use text or character varying without a length specifier, rather than making up an arbitrary length limit...

– dwir182
Nov 23 '18 at 2:53













I can't see how you could "break down" the database by supplying long strings.

– a_horse_with_no_name
Nov 23 '18 at 7:40





I can't see how you could "break down" the database by supplying long strings.

– a_horse_with_no_name
Nov 23 '18 at 7:40













Yes.. I want to remove that @a_horse_with_no_name but if i remove the first argument i show i think that's not good.. That's just my speculation.. If i am wrong you can dv me.. :)

– dwir182
Nov 23 '18 at 7:44





Yes.. I want to remove that @a_horse_with_no_name but if i remove the first argument i show i think that's not good.. That's just my speculation.. If i am wrong you can dv me.. :)

– dwir182
Nov 23 '18 at 7:44




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid …



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53439104%2fshould-we-validate-max-length-on-string-fields%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







-

這個網誌中的熱門文章

Tangent Lines Diagram Along Smooth Curve

圖片
7 1 I am trying to replicate a diagram and have a minimal example. I don't know how to add additional tangents between the specified points and preserve smoothness. documentclass{article} usepackage{tikz} usetikzlibrary{calc,intersections} begin{document} begin{tikzpicture} % Axes draw [->, name path=x] (-1,0) -- (11,0) node [right] {$x$}; draw [->] (0,-1) -- (0,6) node [above] {$y$}; % Origin node at (0,0) [below left] {$0$}; % Points coordinate (start) at (1,-0.8); coordinate (c1) at (3,3); coordinate (c2) at (5.5,1.5); coordinate (c3) at (8,4); coordinate (end) at (10.5,-0.8); % show the points foreach n in {start,c1,c2,c3,end} fill [black] (n) circle (2pt) node [below] {}; % join the coordinates draw [thick,name path=curve] (start) to[out=70,in=180] (c1) to[out=0,in=180]
閱讀完整內容

Yusuf al-Mu'taman ibn Hud

圖片
Main article: Taifa of Zaragoza Al-Mu'taman Ruler of Zaragoza Reign 1081–1085 Predecessor Ahmad al-Muqtadir Successor Al-Mustain II Born Zaragoza Died 1085 Full name Yusuf ibn Ahmad al-Mu'taman ibn Hūd House Banu Hud Yusuf ibn Ahmad al-Mu'taman ibn Hūd (Arabic: المؤتمن بالله يوسف إبن أحمد إبن هود ‎, al-Mutaman bi l-Lah , died c. 1085) was the third king of the Banu Hud dynasty who ruled over the Taifa of Zaragoza from 1081 to 1085. Yusuf al-Mutaman reigned during the height of power of Muslim Zaragoza , following the thriving period of his father Ahmad al-Muqtadir. He continued his father's efforts and created around him a court of intellectuals, living in the beautiful palace of Aljafería, nicknamed as "the palace of joy". Al-Mu'taman was also a scholarly king and a patron of science, philosophy and arts. As an example of a wise king, he knew astrology, philosophy, and especially mathematics, a discipline in which
閱讀完整內容

Zucchini

圖片
This article is about the vegetable. For other uses, see Zucchini (disambiguation). Zucchini (courgette) A striped and a uniform color zucchini Genus Cucurbita Species Cucurbita pepo Origin 19th century northern Italy The zucchini ( / z uː ˈ k iː n i / , American English) or courgette ( / k ʊər ˈ ʒ ɛ t / , British English) is a summer squash which can reach nearly 1 metre (100 cm; 39 in) in length, but is usually harvested when still immature at about 15 to 25 cm (6 to 10 in). [1] A zucchini is a thin-skinned cultivar of what in Britain and Ireland is referred to as a marrow. [2] [3] In South Africa, a zucchini is known as a baby marrow. Along with certain other squashes and pumpkins, the zucchini belongs to the species Cucurbita pepo . It can be dark or light green. A related hybrid, the golden zucchini, is a deep yellow or orange color. [4] In a culinary context, the zucchini is treated as a vegetable; it is usually cooked and presented as a savory dish o
閱讀完整內容