"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Actually, the right way to fix that is of course to call
> check_stack_depth() in makepol and TS_execute.
Done.
That is, I did it in HEAD's integrated tsearch code. I suppose the same
hazard exists in all back-branch contrib/tsearch2 versions ..
On Thursday 30 August 2007 21:15, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > pagila=# select to_date('05 December 2000', 'DD Month ');
> > to_date
> > ---
> > 0001-12-05 BC
> > (1 row)
> >
> > I can't imagine that's expected behavior bug?
>
> You needed to sa
Robert Treat <[EMAIL PROTECTED]> writes:
> pagila=# select to_date('05 December 2000', 'DD Month ');
> to_date
> ---
> 0001-12-05 BC
> (1 row)
> I can't imagine that's expected behavior bug?
You needed to say FMMonth, else it expects fixed-width column.
to_date and friends a
Peter,
I don't know if this is directly related to your problem, but the
version of dbd_db_pg_notifies you are using has a memory leak in it.
The memory leak causes a small amount of memory to be leaked every time
pg_notifies is called from your perl code. This memory leak affected
several
example from docs:
pagila=# select to_date('05 Dec 2000', 'DD Mon ');
to_date
2000-12-05
(1 row)
slight modification:
pagila=# select to_date('05 December 2000', 'DD Month ');
to_date
---
0001-12-05 BC
(1 row)
I can't imagine that's expected behavior bug?
o
"Richard Harris" <[EMAIL PROTECTED]> writes:
> The queries, query1 and query2, below are identical except that query1 has a
> 'left join' where query2 has a 'join'. Both queries return three rows.
> However query2 (with the 'join') returns all non-null values in column
> t1b_pkt1 where query 1 with
but the documentation does not say I shouldn't be able to do it.
Additionally, an alternate method (which was not included) using
temporary tables works fine. It fails when switching to the old record.
thanks
cyrus
Tom Lane wrote:
Cyrus Downey <[EMAIL PROTECTED]> writes:
Accord
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> The problem seems to be unbounded recursion in the makepol function that
> converts the input query from infix to polish notation. An easy fix
> would be to just add a level parameter to makepol that's incremented on
> each recursion, and throw an
Kris Jurka <[EMAIL PROTECTED]> writes:
> On Thu, 30 Aug 2007, Magnus Hagander wrote:
>> This is a known problem (though arguably not actually a bug) but it's far
>> from trivial to fix which is why it hasn't been fixed yet.
> Actually this will be fixed in 8.3:
> http://archives.postgresql.org/pgs
Dear Kris and Magnus,
Thanks you very much for your prompt reply. I'm now clear the behavior
and its future plan.
Thanks again!
best regards,
Kris Jurka wrote:
>
>
> On Thu, 30 Aug 2007, Magnus Hagander wrote:
>
>> There's your problem right there: it does *not* mean that the default
>> se
Heikki Linnakangas wrote:
> Passing a query with enough nested parenthesis in it causes a segfault.
> Attached is a handy little program to generate such a query, the actual
> query was too big to get through to the list.
>
> The problem seems to be unbounded recursion in the makepol function that
Passing a query with enough nested parenthesis in it causes a segfault.
Attached is a handy little program to generate such a query, the actual
query was too big to get through to the list.
The problem seems to be unbounded recursion in the makepol function that
converts the input query from infix
On Thu, 30 Aug 2007, Magnus Hagander wrote:
There's your problem right there: it does *not* mean that the default
setting would be effective. It means that the setting won't be changed.
Remove the comment and set it to false, and it'll work.
(if you restart the server instead of reload it *wil
On Thu, Aug 30, 2007 at 03:02:54AM +, fuminori ido wrote:
>
> The following bug has been logged online:
>
> Bug reference: 3589
> Logged by: fuminori ido
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 7.4.7
> Operating system: GNU/Linux, Debian3.1
> Description:
The following bug has been logged online:
Bug reference: 3589
Logged by: fuminori ido
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.7
Operating system: GNU/Linux, Debian3.1
Description:/etc/init.d/postgresql reload doesn't reflect
/etc/postgresql/postgresql
15 matches
Mail list logo
