Re: [GENERAL] tsearch2 in 7.4beta1 compile problem

2003-09-14 Thread Tom Lane
Teodor Sigaev [EMAIL PROTECTED] writes:
 AFAICT tsearch2's incompatibility is in the redefined YY_INPUT macro,
 which seems of no value for Postgres anyway.  Can't we take that out?

 I resolve problem with gm4 with a help of symlink and reorder my PATH. So, it 
 compiles but creates core dump while regression (postgres is compiled with 
 enable-debug and enable-cassert):

I found the cause -- you had #defined malloc as palloc, etc.  That
caused the yy_buffer_stack to get deallocated between calls to the
lexer, which flex isn't expecting.  Since you have code to clean up
the lexer state, I don't see any need to use palloc here.

regards, tom lane

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [GENERAL] tsearch2 in 7.4beta1 compile problem

2003-08-15 Thread Oleg Bartunov
On Thu, 14 Aug 2003, Tom Lane wrote:

 Oleg Bartunov [EMAIL PROTECTED] writes:
  On Wed, 13 Aug 2003, Jeff Davis wrote:
  I cd to the tsearch2 directory and typed make, however I get an error that
  yy_current_buffer is an undeclared identifier in wordparser/parser.c (which
  is apparently autogenerated with flex from parser.l).

  This is a FAQ. Don't use flex 2.5.31
  Downgrade to stable 2.5.4.

 Still, it would be better if it worked than not.  (All the core code
 does seem to work with flex 2.5.31 now; only contrib is behind.)

ok. I recall discussion several months ago about 2.5.31 version.
So, we oficially support it ?


 AFAICT tsearch2's incompatibility is in the redefined YY_INPUT macro,
 which seems of no value for Postgres anyway.  Can't we take that out?


We'll see.

   regards, tom lane

 ---(end of broadcast)---
 TIP 4: Don't 'kill -9' the postmaster


Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [GENERAL] tsearch2 in 7.4beta1 compile problem

2003-08-15 Thread Tom Lane
Oleg Bartunov [EMAIL PROTECTED] writes:
 On Thu, 14 Aug 2003, Tom Lane wrote:
 Still, it would be better if it worked than not.  (All the core code
 does seem to work with flex 2.5.31 now; only contrib is behind.)

 ok. I recall discussion several months ago about 2.5.31 version.
 So, we oficially support it ?

I wouldn't say that, exactly --- if anyone has any problems with 2.5.31
I'll be the first to say use 2.5.4.  (2.5.31 doesn't even compile on
my primary machine.)  But I assume the flex guys will fix their little
problems soon, and that before PG 7.4 reaches end of life the newer flex
behavior will be standard.  So I think it behooves us to update our code
to be compatible.  The core code all works with either 2.5.4 or 2.5.31
now, and I'd like to see contrib doing the same.  (cube and seg are
broken, but I'll work on fixing those if you'll take care of tsearch
and tsearch2.)

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [GENERAL] tsearch2 in 7.4beta1 compile problem

2003-08-15 Thread Oleg Bartunov
On Fri, 15 Aug 2003, Tom Lane wrote:

 Oleg Bartunov [EMAIL PROTECTED] writes:
  On Thu, 14 Aug 2003, Tom Lane wrote:
  Still, it would be better if it worked than not.  (All the core code
  does seem to work with flex 2.5.31 now; only contrib is behind.)

  ok. I recall discussion several months ago about 2.5.31 version.
  So, we oficially support it ?

 I wouldn't say that, exactly --- if anyone has any problems with 2.5.31
 I'll be the first to say use 2.5.4.  (2.5.31 doesn't even compile on
 my primary machine.)  But I assume the flex guys will fix their little
 problems soon, and that before PG 7.4 reaches end of life the newer flex
 behavior will be standard.  So I think it behooves us to update our code
 to be compatible.  The core code all works with either 2.5.4 or 2.5.31
 now, and I'd like to see contrib doing the same.  (cube and seg are
 broken, but I'll work on fixing those if you'll take care of tsearch
 and tsearch2.)


ok, I see your arguments. Teodor is working on that issue.


   regards, tom lane

 ---(end of broadcast)---
 TIP 6: Have you searched our list archives?

http://archives.postgresql.org


Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [GENERAL] tsearch2 in 7.4beta1 compile problem

2003-08-15 Thread Teodor Sigaev
AFAICT tsearch2's incompatibility is in the redefined YY_INPUT macro,
which seems of no value for Postgres anyway.  Can't we take that out?
I resolve problem with gm4 with a help of symlink and reorder my PATH. So, it 
compiles but creates core dump while regression (postgres is compiled with 
enable-debug and enable-cassert):

#0  0x284b5507 in tsearch2_yy_switch_to_buffer (new_buffer=0x84040a0)
at parser.c:1725
1725YY_CURRENT_BUFFER_LVALUE-yy_buf_pos = (yy_c_buf_p);
(gdb)  print (yy_buffer_stack)[(yy_buffer_stack_top)]
$1 = 0x7f7f7f7f
(gdb)  print yy_buffer_stack_top
$2 = 0
(gdb) bt
#0  0x284b5507 in tsearch2_yy_switch_to_buffer (new_buffer=0x84040a0)
at parser.c:1725
#1  0x284b5bb2 in tsearch2_yy_scan_buffer (
base=0x8404314 345 [EMAIL PROTECTED] ' http://www.com/ 
http://aew.werc.ewr/?ad=qwe;
dw 1aew.werc.ewr/?ad=qwedw 2aew.werc.ewr http://3aew.werc.ewr/?ad=qwedw http:/
/4aew.werc.ewr http://5aew.werc.ewr:8100/?  ad=qwedw 6aew.w..., size=566)
at parser.c:1976
#2  0x284b5c8e in tsearch2_yy_scan_bytes (
bytes=0x835aa48 345 [EMAIL PROTECTED] ' http://www.com/ 
http://aew.werc.ewr/?ad=qwe
dw 1aew.werc.ewr/?ad=qwedw 2aew.werc.ewr http://3aew.werc.ewr/?ad=qwedw http:
//4aew.werc.ewr http://5aew.werc.ewr:8100/?  ad=qwedw 6aew.w..., len=564)
at parser.c:2020
#3  0x284b5fed in start_parse_str (
str=0x835aa48 345 [EMAIL PROTECTED] ' http://www.com/ 
http://aew.werc.ewr/?ad=qwed
w 1aew.werc.ewr/?ad=qwedw 2aew.werc.ewr http://3aew.werc.ewr/?ad=qwedw http://
4aew.werc.ewr http://5aew.werc.ewr:8100/?  ad=qwedw 6aew.w..., limit=564)
at parser.l:303
It seems to me, bug in flex...





--
Teodor Sigaev  E-mail: [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html