Thanks - we have realised that it is a 'feature' of the pgAdmin III query window (if the data is viewed directly then it is correct): and is listed in the pgadmin FAQS as 'query data is truncated'. Its just a pity they don't use something more recognisable such as ... or (...)
Cathy
Burn !
Docs say: Only the database owner or a superuser can rename a database;
non-superuser owners must also have the CREATEDB privilege.
Looks like a superuser must have CREATEDB too:
[EMAIL PROTECTED] SELECT usesuper, usecreatedb from pg_user where usename =
'fduch';
usesuper | usecreatedb
"Alexander M. Pravking" <[EMAIL PROTECTED]> writes:
> Docs say: Only the database owner or a superuser can rename a database;
> non-superuser owners must also have the CREATEDB privilege.
> Looks like a superuser must have CREATEDB too:
Yeah, the test in RenameDatabase is only looking at createdb
I wrote:
> This is quite clear that the output of a HAVING clause is a "grouped
> table" no matter whether the query uses GROUP BY or aggregates or not.
> What that means is that neither the HAVING clause nor the targetlist
> can use any ungrouped columns except within aggregate calls; that is,
>
Here is your Sql run in a DB2 database.
connect to phoenix
Database Connection Information
Database server= DB2/LINUX 8.1.5
SQL authorization ID = GILL
Local database alias = PHOENIX
create table tab (col integer)
DB2I The SQL command completed successfully.
select 1 fro
Tom Lane wrote:
Would those of you with access to other DBMSes try this:
create table tab (col integer);
select 1 from tab having 1=0;
select 1 from tab having 1=1;
insert into tab values(1);
insert into tab values(2);
select 1 from tab having 1=0;
select 1 from tab having 1=1;
I claim that a SQL-c
Tom Lane wrote:
>
> Would those of you with access to other DBMSes try this:
>
> create table tab (col integer);
> select 1 from tab having 1=0;
> select 1 from tab having 1=1;
> insert into tab values(1);
> insert into tab values(2);
> select 1 from tab having 1=0;
> select 1 from tab having 1=1;
On Thu, 10 Mar 2005 12:44:50 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
> Would those of you with access to other DBMSes try this:
>
On informix 9.21.UC4
> create table tab (col integer);
> select 1 from tab having 1=0;
>
returns no rows
> select 1 from tab having 1=1;
>
returns no rows
> inser
On Thu, Mar 10, 2005 at 12:44:50PM -0500, Tom Lane wrote:
>
> Would those of you with access to other DBMSes try this:
>
> create table tab (col integer);
> select 1 from tab having 1=0;
> select 1 from tab having 1=1;
> insert into tab values(1);
> insert into tab values(2);
> select 1 from tab
"Barry Lind" <[EMAIL PROTECTED]> writes:
> On Oracle 9.2 you get 0, 0, 0, and 2 rows.
Really!? Well, we always knew they were a bit standards-challenged ;-).
I have more faith in DB2 being an accurate implementation of the spec.
regards, tom lane
"Peter Wright" <[EMAIL PROTECTED]> writes:
> I think this demonstrates the problem much better than I could explain in
> words. The bug is shown in the two
> SELECT queries with a WHERE clause. Very bizarre.
I've applied a patch that corrects this problem in CVS HEAD, but since
it changes the beha
select 1 from tab having 1=1;
returns 2 rows
I'm curious whats in those two rows... {{1} {1}} ?
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Hi Tom, others,
First I must say that I appreciate the effort you've invested already
into finding the best "correct" solution. It's very encouraging. :)
I think I understand your analysis of the problem being that HAVING is
erroneously optimised/simplified to WHERE in some cases - and so the
in
Peter Wright <[EMAIL PROTECTED]> writes:
> [various stuff snipped]
> You say, "WHERE is defined to filter rows before application of
> aggregates", but I'd _think_ that should be interpreted to apply only
> to aggregates in the _current_ query (ie. not in sub-queries).
Well, the subtext of this di
14 matches
Mail list logo
