Not strictly a bug, but I have added the stub methods to
the JDBC driver to permit compilation with the 1.4.0 JDK.
Note this is not an implementation of the new functionality, it
merely returns false or throws NotImplemented exceptions, but
at least it all compiles.
I did this when 1.4.0 was in b
Hi all,
I think I found a bug using the IN operator.
I have a table t populated as follow:
a | b
---+
1 | 11
2 | 22
3 | 33
4 | NULL
(4 rows)
select * from t where b in (11,22,NULL);
a | b
---+
1 | 11
2 | 22
(2 rows)
select * from t where b not in (11,22,NULL);
a | b
---+
Dear Sir,
When I start "postmaster -D
/cygdrive/d/apps/cygwin/usr/local/pgsql/data" I am getting the
follwoing message.
DEBUG: database system was shut down at 2002-05-23
17:45:00DEBUG: checkpoint record is at 0/11F970DEBUG: redo
record is at 0/11F970; undo rec
Dear Sir,
When I start "postmaster -D
/cygdrive/d/apps/cygwin/usr/local/pgsql/data" I am getting the follwoing
message.
DEBUG: database system was shut down at 2002-05-23
17:45:00DEBUG: checkpoint record is at 0/11F970DEBUG: redo
record is at 0/11F970; undo record is at 0/0; sh
POSTGRESQL BUG REPORT TEMPLATE
Your name : Terence Ingram
Your email address : [EMAIL PROTECTED]
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of jose
> Sent: Wednesday, May 22, 2002 9:38 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [BUGS] in(NULL)
>
>
> Hi all,
>
> I think I found a bug using the IN operator.
>
>
> I have a tabl
On Tue, May 21, 2002 at 10:12:20AM -0400, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > But the /y portion is shown in this case:
> > pmoanalysis=> select ipaddress||'a' from dhcpservers;
> > ?column?
> > -
> > 1.2.3.4/32a
> > (1 row)
>
> This implicitly coerces the inet value
jose <[EMAIL PROTECTED]> writes:
> I think I found a bug using the IN operator.
> select * from t where b not in (11,22,NULL);
This is not a bug. The behavior of NOT IN with NULLs is not very
intuitive but it is correct according to the SQL standard. The result
can only be FALSE (when b is 11 o
Holger Mitterwald ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
JDBC: DatabaseMetaData.getColumns() "feature"
Long Description
When trying to call the method DatabaseMetaData.getColumns with a a tablenamepattern
(sTableName
"Terence Ingram" <[EMAIL PROTECTED]> writes:
> Why is this so?
Numeric literals too large to fit in an int are interpreted as floats.
You can work around the issue by explicitly coercing the literal to
numeric, or by single-quoting it (so that its type is not determined
until after agency_uid is
I said:
> You can work around the issue by explicitly coercing the literal to
> numeric, or by single-quoting it (so that its type is not determined
> until after agency_uid is known to be numeric), or by updating to PG
> 7.2 which uses a slightly different set of type-resolution rules.
Actually,
Ralph Lecessi ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
Is there any way to free up some more space?
Long Description
Firstly, Kudos to you all for making such a mature product available
as an open source distribution. I
Jose,
First, do not waste your time comparing PG to MySql: MySql IS NOT SQL!
Second, any operation on NULL is NULL.
Third, no set can include NULL.
You want to rewrite your query as:
select * from t where b in (11,22) or b is null;
jose wrote:
>
> Hi all,
>
> I think I found a bug using the I
Hi,
i have a little problem when selecting entries from a table, specified by a
long match on a field of type TEXT. Is there a length limitation for the '='
operator when comparing a field of type TEXT to a given string ?
Example:
SELECT description FROM sequences_33 WHERE description LIKE 'gi
"Michael Beckstette" <[EMAIL PROTECTED]> writes:
> i have a little problem when selecting entries from a table, specified by a
> long match on a field of type TEXT. Is there a length limitation for the '='
> operator when comparing a field of type TEXT to a given string ?
No.
> Example:
> SELE
Hi,
ok my fault. It was a cut and paste error, there is no leading blank. In my
view this only happens when the strings to compare are quite "long".
If there is no limitation for the '=' operator itself,could it be possible that
something like this happens when the query is passed through LIPQ's P
16 matches
Mail list logo