Re: [BUGS] FW: Noticed a Bug with stored procedures

2010-03-22 Thread Korry Douglas
untVariable; -- Korry ------- Korry Douglas Senior Database Dude EnterpriseDB Corporation The Enterprise Postgres Company Phone: (804)241-4301 Mobile: (620) EDB-NERD

Re: [BUGS] ecpg preprocessor regression in 9.0

2010-11-02 Thread Korry Douglas
On closer look, it's quite obvious: the code added to ECPGdump_a_type thinks that ECPGt_const is a variable type, and tries to look up the variable. The straightforward fix is this: ... But I wonder if there is a better way to identify variable-kind of ECPGttypes than list the ones that are not. T

Re: [BUGS] ecpg preprocessor regression in 9.0

2010-11-02 Thread Korry Douglas
On closer look, it's quite obvious: the code added to ECPGdump_a_type thinks that ECPGt_const is a variable type, and tries to look up the variable. The straightforward fix is this: ... But I wonder if there is a better way to identify variable-kind of ECPGttypes than list the ones that are not. T

Re: [BUGS] BUG #5753: Existing Functions No Longer Work

2010-11-16 Thread Korry Douglas
e that a third-party JDBC driver was doing some behind-the-curtains work on your behalf. -- Korry ----------- Korry Douglas Senior Database Dude EnterpriseDB Corporation The Enterprise Postgres Company Phone: (804)241-43

Re: [BUGS] BUG #5816: index not used in function

2011-01-09 Thread Korry Douglas
> We may have different perceptions of something being a 'bug'. I always > have several simple ways of determining it. One of them is when a > work-around is in the proposal. Yours is one. It seems to me that the important question in this case is whether or not the query produced the correct res

Re: [BUGS] BUG #5816: index not used in function

2011-01-12 Thread Korry Douglas
Frank, thanks for educating me. -- Korry > -Original Message- > From: Korry Douglas [mailto:korry.doug...@enterprisedb.com] > Sent: Sunday, January 09, 2011 2:34 PM > To: frank > Cc: 'Kevin Grittner'; pgsql-bugs@postgresql.org > Subject: Re: [BUGS]

Re: [BUGS] NO DATA error message in Frontend when querying large datasets

2011-01-26 Thread Korry Douglas
;no data" is coming from some code that is not >> written to cope with that happening. >> >> You might consider using a cursor to fetch large results a few rows at a >> time. >> >> regards, tom lane >> > > -- > Sent via

Re: [BUGS] BUG #5935: Log lotation not working for default log format

2011-03-17 Thread Korry Douglas
What would you expect the new log file to be named? Your log_filename is set to postgresql-%a.log. The %a part expands to the current day of the week. If it's Thursday and you already have a file for Thursday, what would the new file name be? -- Korry > The following bug has

Re: [BUGS] BUG #5935: Log lotation not working for default log format

2011-03-17 Thread Korry Douglas
quence that meant "replace me with the next available sequence number... %n might translate to _1, _2, _3, ...). -- Korry P.S. I'm not disagreeing with you, just explaining the code as it exists today. > > Brad. > >> -Original Message- &g