Skip site navigation (1) Skip section navigation (2)

Re: JDBC Support for standard_conforming_strings

From: Kris Jurka <jurka(at)ejurka(dot)com>
To: Michael Paesold <mpaesold(at)gmx(dot)at>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: JDBC Support for standard_conforming_strings
Date: 2006-11-13 06:02:22
Message-ID: 45580A6E.2010905@ejurka.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
Michael Paesold wrote:
> 
> I am sending a work-in-progress patch now, as I have some more questions 
> on how to proceed.
> 
> Progress so far:

Looks good so far.  So two typos in comments.  Incremental diff attached.

> Question 1:
> -----------
> The V2 code as well as the query-parsing code in 
> AbstractJdbc2DatabaseMetaData is either mostly static or has otherwise 
> no reference to the connection object. There are two ways to tackle 
> this: either pass around standardConformingStrings (the variable name 
> could be stdStrings for brevity), or give the code access to the current 
> connection.
> 

Doesn't really matter how you pass this around.  The patch's usage of an 
additional boolean parameter looks fine to me.

> Question 2:
> -----------
> The problem with the V2 protocol code is, that tracking the state of 
> standard_conforming_strings is not really possible, AFAICS. Currently I 
> just read standard_conforming_strings at startup, and that's it. So as 
> soon as someone changes the variable, quoting will be incorrect, which 
> is a security issue. Therefore my new suggestion is to used the E'' 
> string syntax in the V2 protocol path if the server version is >= 8.2. 
> The version of the server cannot change during the connection, so we are 
> save here.

I'm not super worried about this.  If an administrator changes the value 
in postgresql.conf and HUPs the postmaster they really can't expect 
every client to pick this up immediately.  Even when we are monitoring 
the state (V3) we won't know it has changed until after we execute the 
next query (with the wrong escaping setting).  If an interface allows 
the user to enter arbitrary SQL such that they can change this setting 
then it's not really a security issue because they don't need to break 
escaping to sneak a query in because they can already execute any query 
they want.

> For question 1, I would then suggest to add an argument to the V2Query 
> constructor that tells whether E'' should be used instead of '', or not.

This is a good idea.

> For parsing inside the JDBC driver, we would still rely on the initially 
> reported value of standard_conforming_strings. We could also add an URL 
> parameter to specify what should be set initially.
> 

I'd like to see a generic way of setting any GUC parameter at startup, 
instead of just this one.  The existing methods of setting this per user 
or per database should be OK.

Attachment: typos.patch
Description: text/plain (1.9 KB)

In response to

Responses

pgsql-jdbc by date

Next:From: Michael SchmidtDate: 2006-11-13 17:05:57
Subject: Help with transactions and FK's
Previous:From: Oliver JowettDate: 2006-11-12 21:22:42
Subject: Re: [HACKERS] server process (PID 1188) exited with exit code

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group