Re: RESOLVED: varchar comparison and trim()
От | ta@lavabit.com |
---|---|
Тема | Re: RESOLVED: varchar comparison and trim() |
Дата | |
Msg-id | 7066.87.252.128.113.1356115904.squirrel@lavabit.com обсуждение исходный текст |
Ответ на | RESOLVED: varchar comparison and trim() (ta@lavabit.com) |
Список | pgsql-novice |
> 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
В списке pgsql-novice по дате отправления: