> I just skimmed your post, but how about this for another solution:
>
> Create insert and update triggers to trim the data as it arrives in
> the database? Will that do what you want?
>
> --
> Michael Wood <esiotrot@gmail.com>
>
Unfortunately no. This would require a trigger for each and every table in
the database (there will be many), and all those triggers will have to be
maintained with every structure change. Although one can limit the number
of different trigger functions or write a generalized trigger function,
data entry is just one side of the problem and querying data is another:
create table mytable (field1 text); -- or varchar
--than comes the following statement from client app:
Insert into mytable (aa );
-- if aforementioned trigger is in effect then actually aa will be stored
-- but when client app asks for some data:
select * from mytable where field1=aa ;
--no records will satisfy the condition - unless field1 is of type char(n)!
Well, Im happy with my solution (so far at least:-) parsing all queries
coming out of the client-app and Rtrim()ing all ISAM field references and
expressions. It adds some processing time to all queries but thats
negligible taking into account that accessing PG/SQL tables is at least
10x slower than ISAM access and it has additional benefit of incurring no
additional processing cost in PG.
As I said before, some sort of ANSI_PADDING option, possibly scoped to a
table or a column, would be nice
And ignoring text to text operator redefinition might be a bug.
A.Tom