From: | Barry Lind <blind(at)xythos(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Mushran, Vrinda" <Vrinda(at)netopia(dot)com>, "'pgsql-jdbc(at)postgresql(dot)org'" <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: Control characters in sql statements close db connection |
Date: | 2003-01-17 20:49:58 |
Message-ID: | 3E286C76.6080402@xythos.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Tom Lane wrote:
> Barry Lind <blind(at)xythos(dot)com> writes:
>
>>Yes I would say this is expected behavior. If you use the regular
>>Statement object it is your responsibility to properly quote and escape
>>the data. However if you use a PreparedStatement then the driver
>>handles it for you.
>
>
>>So you would issue the following via a PreparedStatement:
>>SELECT * FROM NEB_IPSNMPDEVICES WHERE NEB_IPSNMPDevices.PHY_ADDRESS = ?
>>and then do a stmt.setString(1,"'^(at)`^]:u'");
>
>
> But there is no escape for a \0, except in the limited context of
> BYTEA values. It'd probably be better for the driver to reject 'em.
>
> Does JDBC understand about BYTEA fields? If so, it could generate the
> correct escape when filling a parameter for a BYTEA value, and fail
> otherwise.
>
Yes the driver understands bytea fields and deals with them
appropriately. But there are not currently any checks that prevent
passing \0 in other areas. The jdbc API uses different methods for
binary data versus textual data and thus there are obvious places to add
such checks.
--Barry
From | Date | Subject | |
---|---|---|---|
Next Message | Barry Lind | 2003-01-17 20:55:56 | Re: insertRow and updateable resultset |
Previous Message | Tom Lane | 2003-01-17 18:25:32 | Re: Control characters in sql statements close db connection |