Re: Escape Processing problems

Поиск
Список
Период
Сортировка
Искать
От
Barry Lind
Тема
Re: Escape Processing problems
Дата
Msg-id
3B8BF727.2030506@xythos.com
Список
Дерево обсуждения
Re: Escape Processing problems Barry Lind <barry@xythos.com>
Re: Escape Processing problems "Thomas O'Dowd" <tom@nooper.com>
Re: Re: Escape Processing problems "Thomas O'Dowd" <tom@nooper.com>
Re: Re: Escape Processing problems Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: Escape Processing problems "Thomas O'Dowd" <tom@nooper.com>
Re: Re: Escape Processing problems Bruce Momjian <pgman@candle.pha.pa.us>
Patch for Statement Escape Processing problems "Thomas O'Dowd" <tom@nooper.com>
Re: Patch for Statement Escape Processing problems "Thomas O'Dowd" <tom@nooper.com>
Re: Patch for Statement Escape Processing problems Bruce Momjian <pgman@candle.pha.pa.us>
Re: Patch for Statement Escape Processing problems Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: Escape Processing problems Rene Pijlman <rene@lab.applinet.nl>
Re: Re: Escape Processing problems "Thomas O'Dowd" <tom@nooper.com>
Thomas,

This is doing exactly what it is supposed to according to the JDBC Spec. 
  In fact there are a bunch of other '{X  }'  things that the Spec 
defines that it should also be handling.

thanks,
--Barry

Thomas O'Dowd wrote:
> Hi all,
> 
> The Connection.EscapeSQL() routine is broken IMHO . Actually, I'm not
> sure why it is trying to fix strings starting with "{d" in the first place?
> 
> Anyway, currently I've turned it off in the statement with
> setEscapeProcessing(false)
> 
> The problem I'm having is that "{d" appears in the data that I'm trying
> to store and its not a date. So data like the following...
> 
> .....blahhh}; {blahhh }; {docs=""};
> 
> is turning into...
> 
> .....blahhh}; {blahhh };   ocs="" ;
>                          ^^      ^
> 
> What's more is if I have something like "{d....." and there is no ending 
> brace, it will throw a StringIndexOutOfBoundsException as the return
> value of the indexOf() looking for the closing brace will not find one
> and thus setCharAt() will use an illegal index of -1 :(
> 
> The routine is below for reference... Can anyone explain why it is trying
> to do this on me in the first place. I would think escape processing would
> do something a little different like watching my single quotes etc.
> 
>     public String EscapeSQL(String sql) {
>       //if (DEBUG) { System.out.println ("parseSQLEscapes called"); }
> 
>       // If we find a "{d", assume we have a date escape.
>       //
>       // Since the date escape syntax is very close to the
>       // native Postgres date format, we just remove the escape
>       // delimiters.
>       //
>       // This implementation could use some optimization, but it has
>       // worked in practice for two years of solid use.
>       int index = sql.indexOf("{d");
>       while (index != -1) {
>         //System.out.println ("escape found at index: " + index);
>         StringBuffer buf = new StringBuffer(sql);
>         buf.setCharAt(index, ' ');
>         buf.setCharAt(index + 1, ' ');
>         buf.setCharAt(sql.indexOf('}', index), ' ');
>         sql = new String(buf);
>         index = sql.indexOf("{d");
>       }
>       //System.out.println ("modified SQL: " + sql);
>       return sql;
>     }
> 
> Cheers,
> 
> Tom.
> 


В списке pgsql-jdbc по дате отправления
От: Barry Lind
Дата:
От: Barry Lind
Дата:
FAQ