Обсуждение: Getting value of bind variables

Поиск
Список
Период
Сортировка

Getting value of bind variables

От
Jayadevan M
Дата:
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."





Re: Getting value of bind variables

От
Andy Colson
Дата:
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

Re: Getting value of bind variables

От
Adrian Klaver
Дата:
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

Re: Getting value of bind variables

От
Tom Lane
Дата:
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

Re: Getting value of bind variables

От
Andy Colson
Дата:
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

Re: Getting value of bind variables

От
Jayadevan M
Дата:
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."





Re: Getting value of bind variables

От
Martijn van Oosterhout
Дата:
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

Вложения