> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Emil J.
> Sent: den 4 november 2006 10:46
> To: pgsql-bugs@postgresql.org
> Subject: [BUGS] BUG #2735: DEBUG: Error 2769: Custom Action
> GetAvailableLocales did not close 1 MSIHANDLEs
>
>
> The f
The following bug has been logged online:
Bug reference: 2740
Logged by: Alon Goldshuv
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.5
Operating system: Mac OSX intel
Description:gcc bug on intel mac with postgresql -O3 optimized build
Details:
I don't kn
Joe Conway <[EMAIL PROTECTED]> writes:
> ... But as I've opined before, all of this seems to me to be much cleaner if
> arrays were always one-dimensional, and array elements could also be
> nested arrays (per SQL 2003). If we said that the cardinality of the
> nested array is an integral part o
The following bug has been logged online:
Bug reference: 2739
Logged by: Mason Hale
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.5
Operating system: GNU/Linux 2.6.9-42.0.3.ELsmp
Description:INTERSECT ALL not working
Details:
'INTERSECT ALL' does not retu
"Mason Hale" <[EMAIL PROTECTED]> writes:
> The query below should return 10 rows,
Not by my reading of the spec. SQL92 7.10 saith:
b) If a set operator is specified, then the result of applying
the set operator is a table containing the following rows:
i)
Tom -Many thanks for the quick reply. I feel honored to receive email from you after seeing your name so many times in my web searches on Postgres topics.That's not how I understood INTERSECT ALL to work. But it's the clear the spec is right and my understanding is wrong.
This is not a bug.Unfortun
On Fri, 2006-11-03 at 15:16 -0700, Rusty Conover wrote:
> It doesn't appear that ANALYZE uses the specified operator class for
> producing statistics on an index when that operator class is not the
> default for the data type. This appears to be leading to poor query
> planning.
> For spee
On Nov 6, 2006, at 1:53 PM, Simon Riggs wrote:
On Fri, 2006-11-03 at 15:16 -0700, Rusty Conover wrote:
It doesn't appear that ANALYZE uses the specified operator class for
producing statistics on an index when that operator class is not the
default for the data type. This appears to be leadi
On Mon, 2006-11-06 at 14:47 -0700, Rusty Conover wrote:
> I just
> want the ANALYZE call to use the index's opclass definitions of = and
> < if the index is created with a custom operator class that is not
> the default for the data type.
Which is exactly what the manual specifically says i
On Nov 6, 2006, at 3:20 PM, Simon Riggs wrote:
On Mon, 2006-11-06 at 14:47 -0700, Rusty Conover wrote:
I just
want the ANALYZE call to use the index's opclass definitions of = and
< if the index is created with a custom operator class that is not
the default for the data type.
Which is exac
On Mon, Nov 06, 2006 at 08:53:28PM +, Simon Riggs wrote:
> On Fri, 2006-11-03 at 15:16 -0700, Rusty Conover wrote:
>
> > It doesn't appear that ANALYZE uses the specified operator class for
> > producing statistics on an index when that operator class is not the
> > default for the data ty
On Mon, 2006-11-06 at 15:54 -0700, Rusty Conover wrote:
> I still think this is a deficiency in the analyze function to not use
> the operator_class that the index uses when producing statistics for
> that index.
Agreed, but that isn't the way it works right now, AFAICS. TODO...
--
Simon
12 matches
Mail list logo
