| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Damiano Bolzoni <damiano(dot)bolzoni(at)gmail(dot)com> |
| Cc: | Sylvain Leroux <sl20(at)wanadoo(dot)fr>, pgsql-jdbc(at)postgresql(dot)org |
| Subject: | Re: Search content within a bytea field |
| Date: | 2009-08-31 14:11:11 |
| Message-ID: | 798.1251727871@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-jdbc |
Damiano Bolzoni <damiano(dot)bolzoni(at)gmail(dot)com> writes:
> But...why if I manually query with a SQL client (AquaStudio) as
> follows:
> SELECT myfield FROM mytable WHERE myfield LIKE '%hello%'
> and 'myfield' is a bytea field I get the result I expected?
The unknown-type literal is assumed to be of type bytea in this case.
In general, if the parser finds "known_type_value operator unmarked_literal"
then it preferentially selects an operator with both input types the
same, ie, it prefers to believe the unmarked_literal is the same data
type as the other input.
The JDBC environment behaves differently because setString and so on
do not produce unmarked literals --- there's an implicit cast to
some datatype. So you have to make sure you've picked a
parameter-setting function that is reasonably compatible with the
intended operation. This is a good thing, really; it tends to keep
the system from choosing an unexpected operation.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Kellerer | 2009-08-31 14:21:16 | Re: Search content within a bytea field |
| Previous Message | dmp | 2009-08-31 13:39:19 | Re: Search content within a bytea field |