Getting value of bind variables

Started by Jayadevan Mover 14 years ago7 messagesgeneral
Jump to latest
#1Jayadevan M
Jayadevan.Maymala@ibsplc.com

Hell l,
I am trying to debug a query that gives an error. The error in the
application server log is
" ERROR: operator does not exist: timestamp without time zone = character
varying
Hint: No operator matches the given name and argument type(s). You might
need to add explicit type casts.
Position: 1274"
How can I get the value of the $1,$2 etc in the query?
WHERE MST.CMPCOD= $1
AND UPPER ( CUSINDINF.FAMNAM )= UPPER ($2)
AND UPPER ( CUSINDINF.INITLS )= UPPER ($3)
AND ( CUSINDINF.MEMDOB ) = ($4)
AND MST.CUSNUM <> $5

It looks like the error is for the condition ( CUSINDINF.MEMDOB ) = ($4) ,
memdob being a date of birth (timestamp) column. When I try the query at
psql with some values, the data is retrieved OK. Is there some logging
available in PostgreSQL that will tell me what values were actually used?
As of now, I am trying with logging level set to debug5 in postgresql.conf
for all logging options. But what is the 'correct' approach?

Regards,
Jayadevan

DISCLAIMER:

"The information in this e-mail and any attachment is intended only for
the person to whom it is addressed and may contain confidential and/or
privileged material. If you have received this e-mail in error, kindly
contact the sender and destroy all copies of the original communication.
IBS makes no warranty, express or implied, nor guarantees the accuracy,
adequacy or completeness of the information contained in this email or any
attachment and is not liable for any errors, defects, omissions, viruses
or for resultant loss or damage, if any, direct or indirect."

#2Andy Colson
andy@squeakycode.net
In reply to: Jayadevan M (#1)
Re: Getting value of bind variables

On 8/19/2011 6:19 AM, Jayadevan M wrote:

Hell l,
I am trying to debug a query that gives an error. The error in the
application server log is
" ERROR: operator does not exist: timestamp without time zone =
character varying
Hint: No operator matches the given name and argument type(s). You might
need to add explicit type casts.
Position: 1274"
How can I get the value of the $1,$2 etc in the query?
WHERE MST.CMPCOD= $1
AND UPPER ( CUSINDINF.FAMNAM )= UPPER ($2)
AND UPPER ( CUSINDINF.INITLS )= UPPER ($3)
AND ( CUSINDINF.MEMDOB ) = ($4)
AND MST.CUSNUM <> $5

It looks like the error is for the condition ( CUSINDINF.MEMDOB ) = ($4)
, memdob being a date of birth (timestamp) column. When I try the query
at psql with some values, the data is retrieved OK. Is there some
logging available in PostgreSQL that will tell me what values were
actually used?
As of now, I am trying with logging level set to debug5 in
postgresql.conf for all logging options. But what is the 'correct'
approach?

Regards,
Jayadevan

Not sure what the exact setting is, try:

log_statement = 'all'

I've never set the log_min_messages or log_min_error_statement, and I'm
pretty sure I've seen values in my logs.

-Andy

#3Adrian Klaver
adrian.klaver@aklaver.com
In reply to: Andy Colson (#2)
Re: Getting value of bind variables

On Friday, August 19, 2011 6:55:39 am Andy Colson wrote:

As of now, I am trying with logging level set to debug5 in
postgresql.conf for all logging options. But what is the 'correct'
approach?

Regards,
Jayadevan

Not sure what the exact setting is, try:

log_statement = 'all'

I've never set the log_min_messages or log_min_error_statement, and I'm
pretty sure I've seen values in my logs.

If I remember correctly this is version specific, though I cannot remember what
version the actual variables where made visible:(

-Andy

--
Adrian Klaver
adrian.klaver@gmail.com

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Jayadevan M (#1)
Re: Getting value of bind variables

Jayadevan M <Jayadevan.Maymala@ibsplc.com> writes:

I am trying to debug a query that gives an error. The error in the
application server log is
" ERROR: operator does not exist: timestamp without time zone = character
varying

It looks like the error is for the condition ( CUSINDINF.MEMDOB ) = ($4) ,
memdob being a date of birth (timestamp) column. When I try the query at
psql with some values, the data is retrieved OK. Is there some logging
available in PostgreSQL that will tell me what values were actually used?

Yes, if you're using a reasonably recent version of Postgres ---
log_statements should provide that information. However, it's 100%
irrelevant to this problem what the specific value is. The problem is
that the application is declaring the *type* of $4 as varchar rather
than something appropriate.

regards, tom lane

#5Andy Colson
andy@squeakycode.net
In reply to: Adrian Klaver (#3)
Re: Getting value of bind variables

On 8/19/2011 9:01 AM, Adrian Klaver wrote:

On Friday, August 19, 2011 6:55:39 am Andy Colson wrote:

As of now, I am trying with logging level set to debug5 in
postgresql.conf for all logging options. But what is the 'correct'
approach?

Regards,
Jayadevan

Not sure what the exact setting is, try:

log_statement = 'all'

I've never set the log_min_messages or log_min_error_statement, and I'm
pretty sure I've seen values in my logs.

If I remember correctly this is version specific, though I cannot remember what
version the actual variables where made visible:(

Ah, yeah, you are probably right.

I can confirm in PG 9, with just

log_statement = 'all'

I see things like:

DETAIL: parameters: $1 = '%oak%'

in my log.

-Andy

#6Jayadevan M
Jayadevan.Maymala@ibsplc.com
In reply to: Tom Lane (#4)
Re: Getting value of bind variables

Hi,
Thank you for the reply.

I am trying to debug a query that gives an error. The error in the
application server log is
" ERROR: operator does not exist: timestamp without time zone =

character

varying

It looks like the error is for the condition ( CUSINDINF.MEMDOB ) =

($4) ,

memdob being a date of birth (timestamp) column. When I try the query

at

psql with some values, the data is retrieved OK. Is there some logging

available in PostgreSQL that will tell me what values were actually

used?

Yes, if you're using a reasonably recent version of Postgres ---
log_statements should provide that information. However, it's 100%
irrelevant to this problem what the specific value is. The problem is
that the application is declaring the *type* of $4 as varchar rather
than something appropriate.

I guess so. But when I tried the same query on psql by replacing ($4) with
a value like '20110404', the query works OK. The value of $4 is being
passed from a java application. So does this mean I have to change the
data type in java code?

By the way ,even log_statemtnts did not give me the bind variable value.
It gave me values for bind variables for queries which got executed, not
for this particular query. I am logging to csv file and loading it to the
postgres_log as mentioned in the document. For this scenario, does the
output go somewhere else? I am looking at the column query_text (select *
from postgres_log where error_severity='ERROR' and log_time > '20110818')

and it shows
.....AND ( CUSINDINF.MEMDOB )= ($4) ....

Regards,
Jayadevan

DISCLAIMER:

"The information in this e-mail and any attachment is intended only for
the person to whom it is addressed and may contain confidential and/or
privileged material. If you have received this e-mail in error, kindly
contact the sender and destroy all copies of the original communication.
IBS makes no warranty, express or implied, nor guarantees the accuracy,
adequacy or completeness of the information contained in this email or any
attachment and is not liable for any errors, defects, omissions, viruses
or for resultant loss or damage, if any, direct or indirect."

#7Martijn van Oosterhout
kleptog@svana.org
In reply to: Jayadevan M (#6)
Re: Getting value of bind variables

On Tue, Aug 23, 2011 at 09:07:20AM +0530, Jayadevan M wrote:

I guess so. But when I tried the same query on psql by replacing ($4) with
a value like '20110404', the query works OK. The value of $4 is being
passed from a java application. So does this mean I have to change the
data type in java code?

For clarity, when you put the value '20110404' in a query, that is not
a varchar. Rather it's type is coerced to whatever is most appropriate
from the surrounding SQL.

To generate the same error you need to put '20110404'::varchar in place
of the parameter.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

He who writes carelessly confesses thereby at the very outset that he does
not attach much importance to his own thoughts.

-- Arthur Schopenhauer