Hi,
A Japanese user found strange behavior in JSON type, so I'd like to
share the issue here. He simply tested casting a string literal to json
type, and got an unexpected error when he used a Japanese word as name
and/or value of JSON object.
In the example below, "キー" is a Japanese word which
Hi Tom,
Thanks for the explanation about standard sql.
The goodness of it must be accepted by faith. :-)
I still have a doubt about the result of the GROUP BY clause.
It seems to me that there's an inconsistence between the GROUP BY clause
and the unique index.
The GROUP BY clause, consider NUL
Peter,
Some of the false positives can be suppressed by teaching the analyzer
about the codebase. For example, many of them are due to the custom
assertion/error handlers, where you stop execution on an error path by
calling, for example, 'elog'. You can drastically reduce the number of
false posi
On Fri, Jun 1, 2012 at 11:13 AM, Josh Kupershmidt wrote:
> On Thu, May 31, 2012 at 10:06 PM, Tom Lane wrote:
>> zaks.a...@gmail.com writes:
>
>>> There are two memory leaks in dumputils (v9.2.0beta1):
>>
>>> 1)
>>> File: src/bin/scripts/dumputils.c
>>> Location: line 604, column 11
>>> De
On Fri, Jun 1, 2012 at 11:53 AM, Josh Kupershmidt wrote:
> On Fri, Jun 1, 2012 at 11:38 AM, Anna Zaks wrote:
>> Josh,
>>
>> What kid of machine are you using? Please, let me know how long it
>> took after it's done (It takes about one and a half hours on mine).
>
> It just finished, actually: too
Josh,
I opened an analyzer Bugzilla report for this issue in case you 'd
like to follow up there:
http://llvm.org/bugs/show_bug.cgi?id=13010
Thanks,
Anna.
On Fri, Jun 1, 2012 at 3:19 PM, Anna Zaks wrote:
> On Fri, Jun 1, 2012 at 11:53 AM, Josh Kupershmidt wrote:
>> On Fri, Jun 1, 2012 at 11:38
On Fri, Jun 1, 2012 at 9:26 PM, Josh Kupershmidt wrote:
> On Fri, Jun 1, 2012 at 4:23 PM, Anna Zaks wrote:
>
>> I opened an analyzer Bugzilla report for this issue in case you 'd
>> like to follow up there:
>> http://llvm.org/bugs/show_bug.cgi?id=13010
>
> Thanks, I'll try to schedule another run
The following bug has been logged on the website:
Bug reference: 6674
Logged by: susan
Email address: shinsetsu...@yahoo.fr
PostgreSQL version: 9.1.3
Operating system: windows vista 64b
Description:
Hi,
when i use string_agg without DISTINCT, this function return some
Hello,
It looks like calling xlst_process as follows causes a crash:
select xslt_process('
60
0.75
30
0.75
1
calendar spread
','
http://www.w3.org/1999/XSL/Transform"; version="1.0">
result.asp?value=
','')
After the crash pglog
jo wrote:
> Thanks for the explanation about standard sql.
> The goodness of it must be accepted by faith. :-)
Not if you have the stamina to fight your way through the standards
documents. ;-)
> I still have a doubt about the result of the GROUP BY clause.
> It seems to me that there's an
Hello,
It looks like calling xlst_process as follows causes a crash:
select xslt_process('
60
0.75
30
0.75
1
calendar spread
','
http://www.w3.org/1999/XSL/Transform"; version="1.0">
result.asp?value=
','')
After the crash pglo
On Fri, Jun 01, 2012 at 08:58:32AM +0200, jo wrote:
> Hi Tom,
>
> Thanks for the explanation about standard sql.
> The goodness of it must be accepted by faith. :-)
> I still have a doubt about the result of the GROUP BY clause.
> It seems to me that there's an inconsistence between the GROUP BY
>
Bruce Momjian wrote:
> COUNT(*) can't skip nulls because there is no specified column,
> but why does COUNT(col) skip nulls --- again, inconsistent.
I disagree -- one is counting rows, the other is counting rows with
a value in that column. I guess one could criticize the syntax for
specifyin
On Mon, Jun 04, 2012 at 10:29:22AM -0500, Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > COUNT(*) can't skip nulls because there is no specified column,
> > but why does COUNT(col) skip nulls --- again, inconsistent.
>
> I disagree -- one is counting rows, the other is counting rows with
>
Bruce Momjian wrote:
> I get your point about COUNT(*) really counting rows, not values,
> but why doesn't GROUP BY then skip nulls?
>
> WITH null_test (col1, col2) AS
> (
> SELECT 1, null
> UNION ALL
> SELECT null, null
> )
> SELECT COUNT(*), col2 FROM null_test group by
On Mon, Jun 04, 2012 at 11:26:20AM -0500, Kevin Grittner wrote:
> > I think the original complaint is that NULL != NULL in a WHERE
> > clause, but GROUP BY is able to group them together just fine.
>
> Whoa! I think I know what you meant, but that is a dangerously
> misleading misstatement. It
writes:
> It looks like calling xlst_process as follows causes a crash:
Hm, apparently xsltApplyStylesheet returns a NULL in this example,
and we're passing that on to xsltSaveResultToString which is not
expecting any such thing. I presume we need another error check
here, but what should the er
On Mon, 2012-06-04 at 11:56 -0400, Bruce Momjian wrote:
> I get your point about COUNT(*) really counting rows, not values, but
> why doesn't GROUP BY then skip nulls?
A while ago, I came to the conclusion that applying logic to extrapolate
the behavior of NULL is a bad idea:
http://thoughts.davi
On fre, 2012-06-01 at 21:26 -0700, Josh Kupershmidt wrote:
> It's too bad the clang
> doesn't understand our ereport(ERROR, ...) calls don't return to the
> caller, as those seem to account for a fair bit of the spurious
> warnings. I haven't seen anything which I'd call an outright bug,
> though t
I wrote:
> Hm, apparently xsltApplyStylesheet returns a NULL in this example,
> and we're passing that on to xsltSaveResultToString which is not
> expecting any such thing. I presume we need another error check
> here, but what should the error say exactly? Can we get any info
> more detailed tha
Shigeru Hanada writes:
> json_lex_string() misjudges that the token "ãã¼" contains naked
> (not-escaped) control character, because its first byte is 0xe3 and it's
> -29 for signed char interpreting, and it's less than 32. We need to
> cast to unsigned char (or use unsigned variable) here.
Ye
21 matches
Mail list logo
