On Tue, Sep 1, 2009 at 00:02, Jaime
Casanova wrote:
> Hi,
>
> pgsql 8.3.7 and 8.4.0
>
> when i issue an "immediate shutdown" the statistics on all tables disappear...
That is by design. Whenever the server goes into crash recovery on
startup, it will clean out the statistics. Since the statistics
Sheng Y. Cheng wrote:
> The Session 4.2.7. Aggregate Expressions in 8.3 document at
> http://www.postgresql.org/docs/8.3/static/sql-expressions.html states "The
> last form invokes the aggregate once for each input row regardless of null
> or non-null values." I am wondering if the result I saw fro
On Mon, Aug 31, 2009 at 07:26:59PM +0200, Pavel Stehule wrote:
> 2009/8/31 Sam Mason :
> > The more awkward case (to me anyway) is that the standard says (1,NULL)
> > IS NULL should evaluate to TRUE.
>
> what?
>
> only (NULL, NULL) IS NULL is true
Bah, sorry you're right! I was rattling my favo
2009/9/1 Heikki Linnakangas :
> I can see two possible interpretations for this:
>
> 1. The subquery pull-up code is broken, the transformation of a
> whole-row reference to ROW(...) is not valid.
>
> 2. The semantics of STRICT with row arguments is broken. It should be
> made consistent with IS NU
2009/9/1 Sam Mason :
> On Mon, Aug 31, 2009 at 07:26:59PM +0200, Pavel Stehule wrote:
>> 2009/8/31 Sam Mason :
>> > The more awkward case (to me anyway) is that the standard says (1,NULL)
>> > IS NULL should evaluate to TRUE.
>>
>> what?
>>
>> only (NULL, NULL) IS NULL is true
>
> Bah, sorry you're
The following bug has been logged online:
Bug reference: 5026
Logged by: Narendra Shah
Email address: narendra.s...@elitecore.com
PostgreSQL version: 8.4
Operating system: Windows 2003
Description:No buffer space available error. Does any other solution
exist other th
The following bug has been logged online:
Bug reference: 5027
Logged by: Dmitry
Email address: mas...@hsdesign.ru
PostgreSQL version: 8.3.5
Operating system: ALT Linux
Description:SQL query error?
Details:
Hello,
I try to make user rating by this query:
"BEGIN;
AL
Heikki Linnakangas writes:
> I can see two possible interpretations for this:
> 1. The subquery pull-up code is broken, the transformation of a
> whole-row reference to ROW(...) is not valid.
I think the problem is probably that we need a PlaceHolderVar wrapper
around the ROW() constructor.
> 2
The following bug has been logged online:
Bug reference: 5028
Logged by: Joseph Shraibman
Email address: j...@selectacast.net
PostgreSQL version: 8.3.7
Operating system: Linux
Description:CASE returns ELSE value always when type is "char"
Details:
[local]:playpen=>
On Tue, Sep 1, 2009 at 4:11 AM, Heikki
Linnakangas wrote:
> 2. The semantics of STRICT with row arguments is broken. It should be
> made consistent with IS NULL. Strict function should not be called if
> the argument is a row value with all NULL columns.
not just STRICT, but coalesce(), libpq 'is
On Tue, Sep 01, 2009 at 04:36:25PM +, Joseph Shraibman wrote:
> Description:CASE returns ELSE value always when type is "char"
I think it's just silently truncating the literal to a single character.
> [local]:playpen=> select c.relkind, CASE c.relkind WHEN 'r' THEN 'table'
> WHEN 'v'
It appears the problem is with the "char" being in the ELSE expression,
not being in the CASE expression
[local]:playpen=> select c.relkind, CASE c.relkind WHEN 'r' THEN 'table'
WHEN 'v' THEN 'view' WHEN 'i' THEN 'index' WHEN 'S' THEN 'sequence' WHEN
's' THEN 'special' WHEN 'c' THEN 'composi
Sam Mason wrote:
On Tue, Sep 01, 2009 at 04:36:25PM +, Joseph Shraibman wrote:
Description:CASE returns ELSE value always when type is "char"
I think it's just silently truncating the literal to a single character.
[local]:playpen=> select c.relkind, CASE c.relkind WHEN 'r' THEN
The following bug has been logged online:
Bug reference: 5029
Logged by: Alan Rubin
Email address: alanrubi...@yahoo.com
PostgreSQL version: unknown
Operating system: Windows XP
Description:Download Trouble
Details:
i'm trying to download postgresql-8.2.9-1.zip from
Alan Rubin wrote:
The following bug has been logged online:
Bug reference: 5029
Logged by: Alan Rubin
Email address: alanrubi...@yahoo.com
PostgreSQL version: unknown
Operating system: Windows XP
Description:Download Trouble
Details:
i'm trying to download postgre
I wrote:
> I think the problem is probably that we need a PlaceHolderVar wrapper
> around the ROW() constructor.
I looked into this a bit more. The issue is that flattening of
subqueries that are inside an outer join first puts PlaceHolderVars
around non-nullable output expressions of the subquer
Joseph Shraibman writes:
> So the type of what is in the ELSE clause determines the type of the output?
If all the other branches are unknown literals, yes.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscri
Tom Lane wrote:
> Joseph Shraibman writes:
>> So the type of what is in the ELSE clause determines the type of
>> the output?
>
> If all the other branches are unknown literals, yes.
What's the best place to look to get a handle on what the benefits are
of treating character string literals as
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Joseph Shraibman writes:
>>> So the type of what is in the ELSE clause determines the type of
>>> the output?
>>
>> If all the other branches are unknown literals, yes.
> What's the best place to look to get a handle on what the benefits are
> of
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Tom Lane wrote:
>>> Joseph Shraibman writes:
So the type of what is in the ELSE clause determines the type of
the output?
>>>
>>> If all the other branches are unknown literals, yes.
>
>> What's the best place to look to get a handle on
To reproduce:
1. initdb -D data
2. cat /dev/null > data/postgresql.conf
3. pg_ctl -w -D data start
I attached a quick patch that seems to do the trick. It appears that
fgets() will always return non-NULL if the size passed in is 1 (i.e.
maxlength in the caller is 0).
The patch also changes the s
On Tue, 2009-09-01 at 13:49 -0500, Kevin Grittner wrote:
> I figured that; I'm just trying to understand what seems to me like an
> odd wart on the type system. I figure I must be missing something
> important, so I'd kinda like to find out what that is.
If I understand your question, you're comp
I blithely opined:
> I believe BTW that there are related issues in other places where we
> expand composites into RowExprs. But the other places have been doing
> that for awhile. I think that for 8.4 our goals should be limited to
> not changing the behavior compared to prior releases.
So whil
Jeff Davis writes:
> I attached a quick patch that seems to do the trick. It appears that
> fgets() will always return non-NULL if the size passed in is 1 (i.e.
> maxlength in the caller is 0).
Huh, interesting corner case. I'd be inclined to fix by initializing
maxlength to 1 though.
Where's t
On Tue, 2009-09-01 at 22:01 -0400, Tom Lane wrote:
> Huh, interesting corner case. I'd be inclined to fix by initializing
> maxlength to 1 though.
>
> Where's the memory leak?
The xstrdup() on the zero-length string.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs
Jeff Davis writes:
> On Tue, 2009-09-01 at 22:01 -0400, Tom Lane wrote:
>> Where's the memory leak?
> The xstrdup() on the zero-length string.
Oh, I see. But actually, it's also clobbering memory like crazy (since
we'll run off the result[] array in no time). Surprising it doesn't
crash from t
Magnus Hagander writes:
> On Tue, Sep 1, 2009 at 00:02, Jaime
> Casanova wrote:
>> when i issue an "immediate shutdown" the statistics on all tables
>> disappear...
> That is by design. Whenever the server goes into crash recovery on
> startup, it will clean out the statistics. Since the statist
27 matches
Mail list logo
