From: | Kris Jurka <books(at)ejurka(dot)com> |
---|---|
To: | Valery Meshkov <meshok2001-news(at)yahoo(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: BUG #3106: A problem with escaping table name pattern for DatabaseMetaData.getColumns() |
Date: | 2007-03-06 16:49:05 |
Message-ID: | Pine.BSO.4.64.0703061135300.13161@leary.csoft.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-jdbc |
On Sun, 4 Mar 2007, Valery Meshkov wrote:
> The following bug has been logged online:
>
> Bug reference: 3106
> PostgreSQL version: 8.2.3
> Description: A problem with escaping table name pattern for
> DatabaseMetaData.getColumns()
> Details:
>
> I am seeing a problem in the JDBC driver postgresql-8.2-504.jdbc3.jar with
> getting columns of the table 'A_B'. I am escaping '_' with the escape
> value returned by DatabaseMetaData.getSearchStringEscape(), which in my case
> is "\\\\" (standard_conforming_strings is off). When I pass the resulting
> table name 'A\\_B' to DatabaseMetaData.getColumns() the number of
> backslashes doubles again, resulting in 4 backslashes in the select
> statement:
>
The problem is that there is a different search string escape depending on
whether you plan to interpolate it into a query or pass it as a parameter
to a PreparedStatement. The getSearchStringEscape method is assuming
you're going to interpolate it into a query and returns the doubled
version. getColumns is assuming you're passing a parameter that it
then interpolates and must escape itself.
The fact that the javadoc for getColumns has a see also for
getSearchStringEscape implies to me that our implementation is wrong and
it shouldn't return the doubled version and anyone interpolating text into
a query must escape it appropriately including the search string escape.
I'll put a fix for this into the next release.
Kris Jurka
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-03-06 17:43:47 | Re: BUG #3110: Online Backup introduces Duplicate OIDs |
Previous Message | Bryan O'Neill | 2007-03-06 15:40:15 | BUG #3115: backend died abnormally HELP!! |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-03-06 17:22:57 | Plan invalidation vs. unnamed prepared statements |
Previous Message | Heikki Linnakangas | 2007-03-06 16:28:43 | Re: Modifying the concurrent transaction limit |