Paul McGarry <[EMAIL PROTECTED]> writes:
> Is it me, or does the declaration of difference as an unsigned int
> prevent the if statements just below from working correctly?
*Clearly* broken :-(
I suppose this could only have escaped notice because hardly anyone
uses fti with a stopword list ...
Hello,
Is it me, or does the declaration of difference as an unsigned int
prevent the if statements just below from working correctly?
Should it not be a normal int?
>From postgresql-7.0.2/contrib/fulltextindex/fti.c
==
bool
is_stopword(char *text)
{
char **StopLow;/
=?iso-8859-1?Q?Mat=EDas?= Giovannini <[EMAIL PROTECTED]> writes:
>> BTW, I would like to get confirmation from someone with a PPC that the
>> new fmgr code works with normal optimization levels on PPC. If you
>> want to try it, grab the current nightly snapshot tarball or current
>> CVS sources a
Tom Lane wrote:
>
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > First, what optimization level is too high on PPC for the old fmgr?
>
> Anything higher than -O0, probably :-(.
>
> BTW, I would like to get confirmation from someone with a PPC that the
> new fmgr code works with normal optimizatio
Lamar Owen <[EMAIL PROTECTED]> writes:
> First, what optimization level is too high on PPC for the old fmgr?
Anything higher than -O0, probably :-(.
BTW, I would like to get confirmation from someone with a PPC that the
new fmgr code works with normal optimization levels on PPC. If you
want to
Matías Giovannini wrote:
> Tom Lane wrote:
> > Can anyone else check these same RPMs? I have a nasty feeling that they
> > might have been miscompiled (eg, built with optimization level higher than
> Unfortunately, I don't even know how to start to make binary RPMs, so I
> can't be of much help
Tom Lane wrote:
>
> =?iso-8859-1?Q?Mat=EDas?= Giovannini <[EMAIL PROTECTED]> writes:
> > I'm baffled at this: \d (and friends) won't give me the definition of a
> > table, view, function, etc:
>
> Wow, that's pretty broken. I assure you \d works for everyone else ;-).
> I think you must be look
The problem's not so much the aggregates as the views. Views containing
GROUP BY don't work properly in any but the simplest cases. Fixing this
will take a major redesign of querytrees, which we are currently hoping
to accomplish in the 7.2 development cycle.
regards, to
Known bug ... we don't quite have JOIN syntax ironed out yet :-(
But thanks for the report, anyway.
regards, tom lane
"Alexei A.Romanenko" <[EMAIL PROTECTED]> writes:
> It seems to me there is a problem with regular expressions.
> When i create table and try to insert some restriction for
> a fields, system accept it. Then, whem i insert something, which
> dont match to regexp, it inserted anyway or backwards.
N
=?iso-8859-1?Q?Mat=EDas?= Giovannini <[EMAIL PROTECTED]> writes:
> I'm baffled at this: \d (and friends) won't give me the definition of a
> table, view, function, etc:
Wow, that's pretty broken. I assure you \d works for everyone else ;-).
I think you must be looking at a serious configuration
Your name : Alexei A. Romanenko
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : Intel Pentium
Operating System (example: Linux 2.0.26 ELF) : Linux 2.2.12 ELF
PostgreSQL version (example:
Your name : Sergei Laskavy
Your email address : <[EMAIL PROTECTED]>
System Configuration
-
Architecture (example: Intel Pentium) : Sun SPARC
Operating System (example: Linux 2.0.26 ELF) : Sun Solaris 2.5.1
PostgreSQL version (example: Postg
POSTGRESQL BUG REPORT TEMPLATE
Your name : Darcy
Your email address : [EMAIL PROTECTED
14 matches
Mail list logo
