Yes, sorry for the mess. The problem was somewhere else (not quite
well written log procedure issuing conversion used for logging, even
tho log was off).
--
GJ
"If we knew what we were doing, it wouldn't be called Research, would
it?" - AE
---(end of broadcas
Grzegorz Jaskiewicz <[EMAIL PROTECTED]> writes:
> I have few fprintf(stderr,""") in function that converts internal
> rep. into string. I was really supprised to see them on me screen when :
> select count(b) from blah where b ~ 'something';
> was issued. What the hell, isn't it wrong ?
Depends
Pollard, Mike schrieb:
If count() convert to a string (an assumption that Martijn
has cast into doubt, or perhaps shredded), then rather than convert all
non-nulls that are not a string into a string, I was proposing
converting the values into an int with the values 0 or 1 (0 means that
row was
Original Message-
> From: Tino Wildenhain [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 16, 2005 8:43 AM
> To: Pollard, Mike
> Cc: Richard Huxton; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] question about count(b) where b is a custom
type
>
> Pollard, Mik
On Wed, Nov 16, 2005 at 08:28:28AM -0500, Pollard, Mike wrote:
> Details, details. But there is a valid general question here, and
> changing the semantics of the query will not address it. When doing a
> count(col), why convert col into a string just so you can determine if
> it is null or not?
Pollard, Mike schrieb:
Richard Huxton wrote:
Pollard, Mike wrote:
Firstly, if you just want a count, what's wrong with count(1) or
count(*).
Because unless the column does not allow nulls, they will not return
the
same value.
Ah, but in the example given the column was being matched
Richard Huxton wrote:
> Pollard, Mike wrote:
> >>Firstly, if you just want a count, what's wrong with count(1) or
> >>count(*).
> >>
> >
> >
> > Because unless the column does not allow nulls, they will not return
the
> > same value.
>
> Ah, but in the example given the column was being matched ag
Pollard, Mike wrote:
Firstly, if you just want a count, what's wrong with count(1) or
count(*).
Because unless the column does not allow nulls, they will not return the
same value.
Ah, but in the example given the column was being matched against a
value, so nulls were already excluded.
> Firstly, if you just want a count, what's wrong with count(1) or
> count(*).
>
Because unless the column does not allow nulls, they will not return the
same value.
Mike Pollard
SUPRA Server SQL Engineering and Support
Cincom Systems, Inc.
Better to remain silen
On K, 2005-11-16 at 10:05 +0100, Grzegorz Jaskiewicz wrote:
> Hi folks
>
> We're developing here gist index (which works finally, and I remember
> about writing some docs about it).
> I have few fprintf(stderr,""") in function that converts internal
> rep. into string. I was really supprised t
On Wed, Nov 16, 2005 at 10:05:36AM +0100, Grzegorz Jaskiewicz wrote:
> Hi folks
>
> We're developing here gist index (which works finally, and I remember
> about writing some docs about it).
> I have few fprintf(stderr,""") in function that converts internal
> rep. into string. I was really su
Hi folks
We're developing here gist index (which works finally, and I remember
about writing some docs about it).
I have few fprintf(stderr,""") in function that converts internal
rep. into string. I was really supprised to see them on me screen when :
select count(b) from blah where b ~ 'so
12 matches
Mail list logo
