"Robby Dermody" <[EMAIL PROTECTED]> writes:
> allshotup=# CREATE TABLE foo (bla0 text, bla1 varchar(20)[], bla2
> char(20)[], bla3 text[]);
> CREATE
> allshotup=# INSERT INTO foo (bla0) VALUES ('test');
> INSERT 19408 1
> allshotup=# UPDATE foo SET bla1[1] = 'bla1', bla2[1] = 'bla2', bla3[1] =
>
Hi, I'm running 7.1.3 on a redhat linux system, using the rpm packages from
the postgresql site:
[nova@naomi scripts]$ rpm -qa|grep postgresql
postgresql-libs-7.1.3-0.onms.5
postgresql-server-7.1.3-0.onms.5
postgresql-python-7.1.3-0.onms.5
postgresql-7.1.3-0.onms.5
postgresql-contrib-7.1.3-0.onms
On Wed, 9 Jan 2002, Bruno Wolff III wrote:
> I am seeing different results when using 'natural join' as opposed to
> 'join ... using' on what I think the equivalent columns should be.
> The 'join ... using' version of the query gives the expected answer.
> I have tried this on 7.1.3 (built local
Natural join of those two tables will be on (gameid, touched)
not only (gameid). You should've noticed that the natural
join was only emitting one copy of the "touched" column ...
regards, tom lane
---(end of broadcast)---
On Wed, 9 Jan 2002, Mike Hoolehan wrote:
> Please enter a FULL description of your problem:
>
> if a quoted column alias in a FROM clause sub-select contains upper-case
> chars, then that column cannot be later referenced without using quotes
>
> P
Mike Hoolehan <[EMAIL PROTECTED]> writes:
> SELECT * FROM (SELECT col1 as "Foo" from table1) AS innerQuery
> WHERE Foo = 'whatever';
> results in
> "ERROR: Attribute 'foo' not found"
> no matter what capitalization is used for "Foo" in the where clause
> (i.e. foo='whatever', FOO='whatever',
Mike Hoolehan writes:
> if a quoted column alias in a FROM clause sub-select contains upper-case
> chars, then that column cannot be later referenced without using quotes
This is expected behaviour. See also
http://www.de.postgresql.org/users-lounge/docs/7.1/postgres/sql-syntax.html#SQL-SYNTAX
I am seeing different results when using 'natural join' as opposed to
'join ... using' on what I think the equivalent columns should be.
The 'join ... using' version of the query gives the expected answer.
I have tried this on 7.1.3 (built locally) and 7.2b4 with a patch
to how foreign keys are ch
POSTGRESQL BUG REPORT TEMPLATE
Your name : Mike Hoolehan
Your email address : [EMAIL PROTECTED]
This is NOT fixed in 2.9. It seems to have something
to with parsing the structure definitions, here is a more
complete case:
exec sql includesqlca;
exec sql type APC_LAYO_FLD is struct {
long apcl_id;
char apclf_sect_flg[2];
};
exec sql type APC_LAYOUT is struct {
long apcl_id;
James Lynn ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
JDBC InputStream.read() from oid returns incorrect values for negative bytes and
really messes up -1
Long Description
Using: PostgresSQL 7.1, jdbc7.1-1.2.jar
After in
Think I've identified a bug in ecpg 2.8 (RH7.1) the following
code aborts (crashes) ecpg:
exec sql include sqlca;
exec sql include ../../libhome/dbincs/apc_layout.h;
exec sql include ../../libhome/dbincs/apc_layo_fld.h;
static int
get_org_name()
{
exec sql begin declare section
12 matches
Mail list logo
