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

From Giovanni Tummarello
Subject Serious 7.2 issue (non quiet string truncation)
Date
Msg-id Pine.LNX.4.21.0202111748070.927-100000@ascu.unian.it
Whole thread Raw
Responses Re: Serious 7.2 issue (non quiet string truncation)  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
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





pgsql-hackers by date:

Previous
From: "Shevland, Joseph (AU - Hobart)"
Date:
Subject: DEBUG output w/o debug set
Next
From: Andrew Sullivan
Date:
Subject: Re: [GENERAL] Feature enhancement request : use of libgda in