POSTGRESQL BUG REPORT TEMPLATE
Your name : Darcy
Your email address : [EMAIL PROTECTED
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
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:
=?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
"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
Known bug ... we don't quite have JOIN syntax ironed out yet :-(
But thanks for the report, anyway.
regards, tom lane
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
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
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
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
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
=?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
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;/
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 ...
14 matches
Mail list logo
