Andrew Dunstan <[EMAIL PROTECTED]> writes:
> How would we do that? Not create the array types in bootstrap mode? Or
> just special-case pg_statistic?
Not generate them in bootstrap mode works for me. IIRC, there's code
somewhere in there that allows anyarray to pass as a column type in
bootstrap
On Sat, 7 Apr 2007, Mark Kirkwood wrote:
> Mark Kirkwood wrote:
> bitmap=# SELECT count(*) FROM bitmaptest
> WHERE val1 in (1,7)
> AND val0 IN (4,3)
> ;
>
> ERROR: XX000: unknown stream type 2
> LOCATION: stream_add_node, tidbitmap.c:1033
Thanks. Turned out t
> I'm seeing a segfault on a size TPC-H size 10 database. The patch and
> code are:
> - bitmap patch from 12 Mar
> - 8.3 dev from 27 Mar
Thanks Mark. I tracked this down. I'll post a new patch soon.
Gavin
---(end of broadcast)---
TIP 6: explain an
Tom Lane wrote:
Based on this, I withdraw my efficiency concern about generating
rowtypes for all user tables. I do, however, still object to generating
them for system tables. In particular an array type for pg_statistic
will actively Not Work and probably constitute a security hole, because
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I'm slightly inclined to agree with David that the danger of catalog
> bloat isn't that great, and might not justify the extra work that some
> sort of explicit array creation would involve (e.g. changes in grammar,
> pg_dump), as long as we are agree
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I don't suggest that we stop using the naming convention,
but it would no longer be a hard-and-fast rule, just a convention.
In particular we could rejigger things around the edges to reduce
the name conflict pro
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I don't suggest that we stop using the naming convention,
>> but it would no longer be a hard-and-fast rule, just a convention.
>> In particular we could rejigger things around the edges to reduce
>> the name conflict problem. For ins
Tom Lane wrote:
I've been thinking of proposing that we add a column to pg_type that
points from a type to its array type (if any), ie the reverse link
from typelem. If we had that then the parser could follow that to
determine which type is foo[], instead of relying on the _foo naming
conventi
On Sun, Apr 08, 2007 at 07:08:38PM -0400, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > One of the things that's been bothering me about this proposal is that
> > it leaves untouched and indeed greatly expands the scope of the typename
> > mangling we do. (i.e. adding an entry
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> One of the things that's been bothering me about this proposal is that
> it leaves untouched and indeed greatly expands the scope of the typename
> mangling we do. (i.e. adding an entry to pg_type with _ prepended).
Yeah, that's been bothering me too.
Tom Lane wrote:
David Fetter <[EMAIL PROTECTED]> writes:
On Mon, Apr 02, 2007 at 10:01:44PM -0400, Alvaro Herrera wrote:
So, hum, what happened to the idea of creating the array types only
on demand?
Scotched, as far as I could tell,
More like "you submitted a patch
Tzahi Fadida wrote:
> On Sunday 08 April 2007 21:34:52 Peter Eisentraut wrote:
> > Tzahi Fadida wrote:
> > > What should i do?
> >
> > Telling what version you use and what error messages you see would
> > help.
>
> SET client_min_messages = warning;
> \set ECHO none
> + ERROR: unrecognized co
On Sunday 08 April 2007 21:34:52 Peter Eisentraut wrote:
> Tzahi Fadida wrote:
> > What should i do?
>
> Telling what version you use and what error messages you see would help.
SET client_min_messages = warning;
\set ECHO none
+ ERROR: unrecognized configuration parameter "standard_conformin
Tzahi Fadida wrote:
> What should i do?
Telling what version you use and what error messages you see would help.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will i
My mapper joins the parent classes' tables to the current class' table in
the view. In the ShapeView only ID, X, and Y is selected from the shape
table, and none of the child tables are touched, opposite to your sample.
But even though all Shape objects (circles and rectangles too) are in the
resu
Hi,
I used the development version of PostgreSQL to compile my module
fulldisjunctions. The install scripts works well there (passes).
However, i wanted to check if it still works (backward compatible) with the
stable version and it complains on these lines in the sql script when i do
make insta
2007/4/7, Ottó Havasvölgyi <[EMAIL PROTECTED]>:
My simple example:
Class hierarchy and fields:
Shape (ID, X, Y)
|
+-Circle (ID, Radius)
|
+-Rectangle (ID, Width, Height)
The mapper creates 3 tables with the columns next to the class name.
And it creates 3 views. One of them:
RectangleView: S
17 matches
Mail list logo
