Re: Serious 7.2 issue (non quiet string truncation) - Mailing list pgsql-hackers

Why can't you truncate the string yourself.

Take atleast one of these actions:

1.    Limit the forms themselves to the length in question:
<input type="text" size="50" />

2.    Use trim the string to length in the code (php below):
$string = substr($string, 0, 50);

3.    Have the INSERT truncate the string:
INSERT INTO table (col1) VALUES (substring('valuetoinsert', 1, 5));


Any of the above (or all of the above) will accomplish what you
require.  I personally suggest both 1 and 2.  But 3 can be used if
necessary.
--
Rod Taylor

This message represents the official view of the voices in my head

----- Original Message -----
From: "Giovanni Tummarello" <tummarel@ascu.unian.it>
To: <pgsql-hackers@postgresql.org>
Sent: Monday, February 11, 2002 11:50 AM
Subject: [HACKERS] Serious 7.2 issue (non quiet string truncation)


>
> Hello everybody
>
> I am a Ph.D student who just innocently upgraded from 7.1 to 7.2 his
home
> brewed content management system.
> The update went allright (datawise speaking) but once i fired up the
site
> again i was flooeded with errors.. what happened? simple
> starting from 7.2 strings are not truncated silently anymore.
>
> While this might be standard SQL (i dont know, i am not an expert
and ,
> quite honeslty, i dont care) i have a few notes which might be worth
> considering:
>
> IMHO silent truncation is a valuable feature to my sistem and i see
no
> easy way to get around it, how shold i do ?
>
> a)replacing Char(x) with "text" type? a security hazard! now every
new
> user
> can upload up to 8 MB in string for each text field I leave open!
>
> b)checking the lenght of EACH FIELD IN EACH QUERY? that means
> specifically querying the DB for the metadata (performance
nightmare) or
> including metadata about the db in the application (software
engineering
> nightmare).
>
> c)leave everything as it is.. maybe get those limits a bit larger
and hope
> that no user ever enters stuff that's too large .. else he'll get
nasty
> errors .. on the other hand that also requires me to handle all
query
> failures directly (put error handles) althought very sound and
> conservative coding practices (as the postgres code itself , I
> assume) require this to be done this is really not the case of web
> scripting and i dont really thing it should be required.
>
> To make a long story short
>
> Silent truncation wasnt bad ad all.. can we have it back ? (via a
switch
> or something? ) i think a good idea would be to have it "field wise"
like
> create table foo(a char(120) silent_trunc).
>
> I do not foresee being able to use postgresql in a non hi-end web
> development environment otherwise.
>
> thanks for the attention
> Giovanni Tummarello
>
>
>
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>