if standard cause head acheing ignore standard
You do so with UPPERCASE, so now you use all lowercased.
This is good when you do thing simpler.
But why you ignore asking of thousands people about case preserving?
create table test ( "Id" integer );
SELECT "Id" as "ID" FROM test
This cause BIG h
Why PG do not use index?
select max(id) from akh_testing_result
For MySQL this query take 2-3ms, but Postgres take 132 000ms to execute query.
select max(id) from akh_testing_result
Query executed in 2,12 minutes, 1 Record(s) Returned
--
Hello, all
From sql.ru forum:
not important, is it one rule like:
create rule v_del as on delete to v do instead (
delete from o1 where id = old.o1_id;
delete from o2 where id = old.o2_id;
);
or split into two rule like:
create rule v_del1 as on delete to v do instead (
dele
[EMAIL PROTECTED] wrote:
> Why PG do not use index?
> select max(id) from akh_testing_result
What PG version are you using? Recent versions should indeed use the
index. Perhaps you just need to upgrade.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The Postgre
Hello, all
> not important, is it one rule like:
> create rule v_del as on delete to v do instead (
>delete from o1 where id = old.o1_id;
>delete from o2 where id = old.o2_id;
> );
>
> or split into two rule like:
> create rule v_del1 as on delete to v do instead (
>delete
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Added to TODO:
> > * Add more cross-data-type operators
> > http://archives.postgresql.org/pgsql-bugs/2008-01/msg00189.php
>
> Uh ... that is exactly 180 degrees away from the point of the thread.
OK, I see now, updated:
*
In response to "Hugo Rafael Lesme Marquez" <[EMAIL PROTECTED]>:
>
> The following bug has been logged online:
>
> Bug reference: 4055
> Logged by: Hugo Rafael Lesme Marquez
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.2.7 and 8.3.1
> Operating system: Windows 2
In response to [EMAIL PROTECTED]:
> Why PG do not use index?
The standard question: when was the last time you did a vacuum analyze
on this table?
>
> select max(id) from akh_testing_result
> For MySQL this query take 2-3ms, but Postgres take 132 000ms to execute query.
>
> select max(id) from
Sergey Burladyan <[EMAIL PROTECTED]> writes:
> Sorry, after thinking some time about this problem now i may be understand
> what going on there... %)
> When first rule was exec - no OLD row anymore in "v" view, nothing will be
> joined and in second rule
> OLD value is empty... so my question is
The following bug has been logged online:
Bug reference: 4058
Logged by: Frank F.
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5-2PGDG
Operating system: Centos
Description:xml_table() segfaults on null
Details:
The xml_table() function in the xml2 contri
Hi,
I came across something weird that I personally can't explain regarding the
EXTRACT function.
I've created a few SQLs to let people see what is happening. Perhaps there
is an explaination for it.
Here is my script to test:
-- The first column of the following 2 queries is trying to
-- c
On Tue, Mar 25, 2008 at 07:50:30PM -, David Rowley wrote:
> Hi,
>
> I came across something weird that I personally can't explain regarding the
> EXTRACT function.
> I've created a few SQLs to let people see what is happening. Perhaps there
> is an explaination for it.
>
> Here is my script t
David Fetter <[EMAIL PROTECTED]> writes:
> On Tue, Mar 25, 2008 at 07:50:30PM -, David Rowley wrote:
>> SELECT FLOOR(EXTRACT(EPOCH FROM '2007-04-09 00:59:59'::TIMESTAMP WITHOUT
>> TIME ZONE) / 86400.0),EXTRACT(EPOCH FROM '2007-04-09 00:59:59'::TIMESTAMP
>> WITHOUT TIME ZONE);
> This is a bug
The following bug has been logged online:
Bug reference: 4057
Logged by: Reginald Drake
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.7
Operating system: Ubuntu linux
Description:SUM returns NULL when given no rows
Details:
Doing something like "SELECT SU
"Reginald Drake" <[EMAIL PROTECTED]> writes:
> Doing something like "SELECT SUM(some_integer_column) FROM some_table WHERE
> FALSE" gives me NULL, where I would expect 0. Since COUNT does give a
> meaningful value when applied to zero columns, maybe SUM should do the same.
You might expect that, b
Thanks for the feedback.
I would have been more suspicious of time zones if the unusual date had
fallen on the 25th of march that year, this is when daylight savings starts
in the timezone that postgresql uses on my system.
The AT TIME ZONE sounds like the best fix for my problem.
Thank you
The following bug has been logged online:
Bug reference: 4059
Logged by: Mark Steben
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Linux redhat
Description:Vacuum full not always cleaning empty tables
Details:
I sent an email to 'pgsql
The following bug has been logged online:
Bug reference: 4060
Logged by: Bruce Nairn
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: Windows XP Pro
Description:libpq - large stack causes TCP/IP error
Details:
I'm using the libpq interfac
"Frank F." <[EMAIL PROTECTED]> writes:
> The xml_table() function in the xml2 contrib module causes a segfault in
> postgres 8.2.5 if it encounters a null value in the column that it's trying
> to pull XML data from.
Seems to have been broken since day one :-(. Will fix.
Mark Steben wrote:
> I sent an email to 'pgsql-bugs@postgresql.org' entitled
> 'Possible bug with VACUUM FULL' and also an addendum
> But neglected to also send this bug report form.
> You can refer to those emails; in a nutshell, I have found that VACUUM FULL
> will not clean dead tuples out of
20 matches
Mail list logo
