I'm not sure if this is a bug, or not - but it looks like one to me.
if you say:
CREATE TABLE testtable (
col1 char(1),
data text
);
INSERT INTO testtable (col1, data) VALUES ('1', 'foobar');
INSERT INTO testtable (col1, data) VALUES ('2', 'foobarbaz');
The following queries all wor
Dnia Thu, 24 May 2007 12:20:54 +0100, Tomas Doran napisał(a):
> CREATE TABLE testtable (
> col1 char(1),
> data text
> );
>
> INSERT INTO testtable (col1, data) VALUES ('1', 'foobar'); INSERT INTO
> testtable (col1, data) VALUES ('2', 'foobarbaz');
>
> The following queries all work
Am Donnerstag, 24. Mai 2007 13:20 schrieb Tomas Doran:
> CREATE TABLE testtable (
> col1 char(1),
> data text
> );
> The following queries all work:
> INSERT INTO testtable (col1, data) VALUES (3::int, 'foobarbazquux');
> SELECT * FROM testtable WHERE col1 = 3::int;
> SELECT * FROM te
On 24 May 2007, at 12:34, Marcin Stępnicki wrote:
Dnia Thu, 24 May 2007 12:20:54 +0100, Tomas Doran napisał(a):
CREATE TABLE testtable (
col1 char(1),
data text
);
INSERT INTO testtable (col1, data) VALUES ('1', 'foobar'); INSERT
INTO
testtable (col1, data) VALUES ('2', 'foob
Tomas Doran wrote:
On 24 May 2007, at 12:34, Marcin Stępnicki wrote:
I'm not sure if I understand you correctly, but it seems that you are
comparing apples to oranges here (integer and character values).
Yep, totally - it's not nice, but we need to do it at $ork for
hysterical raisins..
Dnia Thu, 24 May 2007 12:54:48 +0100, Tomas Doran napisał(a):
> If I can do something to make it work in the postgres backend, then that'd
> be acceptable, and I'm investigating that..
>From what I know it's impossible without touching the source.
> This is, at the very least, is a glaring inco
On 24 May 2007, at 13:19, Richard Huxton wrote:
Tomas Doran wrote:
On 24 May 2007, at 12:34, Marcin Stępnicki wrote:
I'm not sure if I understand you correctly, but it seems that you
are
comparing apples to oranges here (integer and character values).
Yep, totally - it's not nice, but we
Tomas Doran <[EMAIL PROTECTED]> writes:
> The tightening in general is biting me, but if the answer was 'it was
> deliberate tightening', and the behavior was consistent, then we'd
> have just dealt with it - it's the in-consistent behavior that makes
> me think this is a bug (or at least a g
On 24 May 2007, at 15:51, Tom Lane wrote:
Tomas Doran <[EMAIL PROTECTED]> writes:
The tightening in general is biting me, but if the answer was 'it was
deliberate tightening', and the behavior was consistent, then we'd
have just dealt with it - it's the in-consistent behavior that makes
me thi
on lwn I read that pg is having problems releasing because of a want of
reviewers.
although my C is far too rusty I'd like to help out, perhaps with doc
or testing.
can someone direct me to the appropriate site?
On 5/24/07, chester c young <[EMAIL PROTECTED]> wrote:
on lwn I read that pg is having problems releasing because of a want of
reviewers.
although my C is far too rusty I'd like to help out, perhaps with doc
or testing.
can someone direct me to the appropriate site?
See:
http://www.postgresq
I have an audit table that I am trying to get a count of the number of distinct
entries per day by the external table key field. I
can do a
select count(distinct(id)) from audit where timestamp >= '01-may-2007'
and get a total count. What I need is a way to group on each day and get a
count
am Thu, dem 24.05.2007, um 14:49:47 -0400 mailte Edward W. Rouse folgendes:
> I have an audit table that I am trying to get a count of the number of
> distinct
> entries per day by the external table key field. I can do a
>
> select count(distinct(id)) from audit where timestamp >= '01-may-2007
On 5/24/07, Edward W. Rouse <[EMAIL PROTECTED]> wrote:
I have an audit table that I am trying to get a count of the number of
distinct entries per day by the external table key field. I can do a
select count(distinct(id)) from audit where timestamp >= '01-may-2007'
and get a total count. What
14 matches
Mail list logo
