That's exactly it - thanks, works perfectly now!
For the record, it's 8.0.3
Dmitri
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 06, 2005 12:32 PM
To: Dmitri Bichko
Cc: pgsql-sql@postgresql.org
Subject: Re: [SQL] UNION index use help
As I understand it, partial indices are generally useful when you only
want to index a range of values, or if the select condition is on a
different field from the one being indexed (eg: ON foo (a) WHERE b IS
NOT NULL).
I am just guessing here, but it sounds like 'person_fk = 2' is going to
be a
SELECT * FROM principals WHERE event = 15821 AND person != 2?
Dmitri
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Leif B.
Kristensen
Sent: Thursday, September 22, 2005 1:30 PM
To: pgsql-sql@postgresql.org
Subject: [SQL] Help with a view
@postgresql.org
Subject: Re: [SQL] Help with a view
On Thursday 22 September 2005 20:03, Dmitri Bichko wrote:
SELECT * FROM principals WHERE event = 15821 AND person != 2?
Sure, that's a concise answer to what I actually wrote, but it wasn't
exactly what I intended :)
Basically
How does the performance of the R-tree searches compare to the Bio::GFF
binning approach?
I've been wondering for a while how well the postgres builtins would do
for this application.
Dmitri
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris
Really seems like that array should be a separate table, then Postgres would
definitely know how to index it.
Dmitri
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Silke Trissl
Sent: Thursday, September 08, 2005 12:14 PM
To:
I believe the problem is that the expression is being eavluated as an
integer, so it's rounded down before it's multiplied by 100;
A simple cast to float4 should help:
test= select (589824 / ((240 * 255840) / 8) * 100);
?column?
--
0
(1 row)
test= select (589824 / ((240 *
How about:
SELECT a.keyfld, a.foo1, b.foo2, c.foo3
FROM a
LEFT JOIN b USING(keyfld)
LEFT JOIN c USING(keyfld)
Dmitri
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Lane Van Ingen
Sent: Wednesday, August 17, 2005 12:55 PM
To:
I don't see what the problem is.
Did you mean to insert (3,'C3') into table c, rather than b?
Dmitri
-Original Message-
From: Mischa Sandberg [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 17, 2005 3:31 PM
To: Dmitri Bichko
Cc: Lane Van Ingen; pgsql-sql@postgresql.org
Subject
I have a couple of views I always add to 'information_schema' to help
with these sorts of things.
Here's the one for foreign keys:
CREATE VIEW information_schema.foreign_key_tables AS SELECT
n.nspname AS schema,
cl.relname AS table_name,
a.attname AS column_name,
I'm guessing it's because char gets padded with spaces to the specified
length.
Any reason you are using char(3) instead of varchar(3)? And why are you
storing numbers as a string, anyway? If you defined the column as a
numeric type, postgres will tell you if you try to insert something
, 2005 6:34 PM
To: Dmitri Bichko
Subject: SUSPECT: RE: Re: [SQL] Problem with a Pettern Matching Check
ANTISPAM UOL » TIRA-TEIMA
Olá,
Você enviou uma mensagem para [EMAIL PROTECTED]
Para que sua mensagem seja encaminhada, por favor, clique aqui
Esta confirmação é necessária porque [EMAIL
Any reason you are using char(3) instead of varchar(3)?
The numbers will have 2 or 3 digits so I tried to save some space :)
Well, smallint is only 2 bytes, so it would be more compact than either
char(3) or varchar(3).
Dmitri
The information transmitted is intended only for the person or
Hello,
I have two tables, one has a foreing key from the other (only showing
the relevant columns and indices here):
Table expresso.probes
Column| Type | Modifiers
-++---
platform_id | integer| not
Hi all,
The docs mention specifying a default tablespace for a database, but it
doesn't seem like you can specify a separate default tablespace for
indices.
Did I overlook something, or is it really not possible to do this?
Thanks,
Dmitri
The information transmitted is intended only for the
Here's one I did a while ago; the tables are trivial in this case (and
the whole thing is definitely overkill) so it should make it easier to
digest.
This becomes useful if you use some sort of ORM layer (Class::DBI in my
case) that can be made to recognize the 'type' column and behave
I'll just second that this is, in fact, extremely annoying.
Dmitri
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael Fuhr
Sent: Thursday, June 16, 2005 11:16 PM
To: pgsql-sql@postgresql.org
Subject: [SQL] Still getting autoreplies from list member
Being lazy, I've created a set of case incensitive text comparison
operators: =*, *, *, and !=*; the function for each just does an
UPPER() on both arguments and then uses the corresponding builtin
operator.
What would make these REALLY useful, is if when running something like:
SELECT * FROM
SELECT your_concat( memo_text ) FROM
(SELECT memo_id, sequence, memo_text FROM table ORDER BY memo_id,
sequence
OFFSET 0) AS foo
GROUP BY memo_id
I'm just curious - what's the 'OFFSET 0' for?
Dmitri
---(end of broadcast)---
TIP 5: Have you
Hello everyone,
I have a table of entities, each entity has a parent_id, I'd like to
have an insert trigger that assigns to that entity a sequential number
which gets incremented per parent_id.
i.e. doing:
INSERT INTO foo(id, parent_id) VALUES('a',1);
INSERT INTO foo(id, parent_id)
I suppose you could put a check constraint that forces a single value on a
column with a unique index? Or an insert trigger that always inserts the same
value into a unique field.
Out of curiosity, why do you need to do this?
Dmitri
-Original Message-
From: [EMAIL PROTECTED]
Hello,
I am trying to use the RULE system to simulate updatable views, with the
final goal of simulating polymorphism in an ORM-like system
(Class::DBI).
Same old idea - when selecting from foo C:DBI checks the type column
and reblesses (I guess casts, in non-perl world) the object to the
You are exactly right - the way I think about it is that if you have two
values which are unknown (a null column and NULL) it does not follow
that they are equal to each other.
As far as TRUE and FALSE go, from what I know you can use = to compare
them with boolean columns, unless I misunderstood
I recently noticed a behaviour which seems quite suboptimal - I am
working on a mart type application, which in practice means I end up
with queries which have a few filters on several central tables, and
then a few dozen subselects for other info (which seems to perform
better than several dozen
24 matches
Mail list logo
