[BUGS] BUG #5902: pl/pgsql plans are not invalidated on discard all

2011-02-28 Thread Ingmar Brouns 

The following bug has been logged online:

Bug reference:  5902
Logged by:  Ingmar Brouns
Email address:  swi...@gmail.com
PostgreSQL version: 9.0.3
Operating system:   Fedora 13
Description:pl/pgsql plans are not invalidated on discard all
Details: 

Hi,

I ran into the pl/pgsql Plan Invalidation and search_path bug that is on the
todo list

http://wiki.postgresql.org/wiki/Todo#PL.2FpgSQL

I was looking for a workaround to this problem, and figured that calling
'discard all', or 'discard plans' should do the trick. However, also after
discard all, the plpgsql function seems to be executed with the old plan. 


Kind regards,

Ingmar


example code

create schema a;
create schema b;
create table a.test_table(a integer);
create table b.test_table(b integer);
insert into a.test_table values(1);
insert into b.test_table values(2);

create or replace function public.foo() returns integer as
$$ 
declare 
retval integer;
begin
select * into retval from test_table;
return retval;
end;
$$ language plpgsql;

set search_path to a,public;
select public.foo();
set search_path to b,public;
select public.foo();

--this is the todo as known
--now lets discard the session state and try it again

DISCARD ALL;
DISCARD PLANS;
set search_path to b,public;
select public.foo();




output:

CREATE SCHEMA
CREATE SCHEMA
CREATE TABLE
CREATE TABLE
INSERT 0 1
INSERT 0 1
CREATE FUNCTION
SET
 foo 
-
   1
(1 row)

SET
 foo 
-
   1
(1 row)

DISCARD ALL
SET
 foo 
-
   1--The output is still (1) instead of (2)
(1 row)


  version   
   


 PostgreSQL 9.0.3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.4.4
20100630 (Red Hat 4.4.4-10), 32-bit

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5902: pl/pgsql plans are not invalidated on discard all

2011-02-28 Thread Tom Lane 
"Ingmar Brouns"  writes:
> Description:pl/pgsql plans are not invalidated on discard all

Yes they are.

> I ran into the pl/pgsql Plan Invalidation and search_path bug that is on the
> todo list

> http://wiki.postgresql.org/wiki/Todo#PL.2FpgSQL

> I was looking for a workaround to this problem, and figured that calling
> 'discard all', or 'discard plans' should do the trick.

That's not a solution because the plancache module intentionally
preserves the original search_path value while replanning.  This
may not be what you wished for, but it's operating as intended,
and changing it would break other use-cases that work today.

regards, tom lane

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5896: When server cannot be started, first it says that it couldn't be started and then Server Started

2011-02-28 Thread Kevin Grittner 
[rearranged to eliminate top-posting]
 
Nacho Mezzadra  wrote:
> Kevin Grittner  wrote:
>> "Nacho Mezzadra"  wrote:
>>
>>> could not start server
>>> PostgreSQL 8.3 started successfully
>>
>> That looks like a packaging problem.  The lines starting with
>> uppercase letters appear to have come from the service script,
>> not PostgreSQL itself.
 
> Meaning that I should fix the service script myself? It's not that
> i wouldn't do it, but just making sure what you are saying.
 
Sorry.  I don't remember you saying whose build you installed, so
I'm not sure whether the packager will be tracking this list.  If
not, you might want to look for another venue to raise the issue.
 
Of course, if you feel comfortable adjusting the script, you're in
good shape to work around it yourself.  If you go that route, you
might want to look at my attempt at an LSB-conforming script to see
if any of that is useful for you.  When I suggested this script
there were objections that it was too long and that most of that
logic really belonged in pg_ctl, so I just threw it into the Wiki in
case anyone finds it useful:
 
http://wiki.postgresql.org/wiki/Lsb_conforming_init_script
 
-Kevin

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5896: When server cannot be started, first it says that it couldn't be started and then Server Started

2011-02-28 Thread Nacho Mezzadra 
Meaning that I should fix the service script myself? It's not that i
wouldn't do it, but just making sure what you are saying.

Thanks and regards,
Nacho.-

On Tue, Feb 22, 2011 at 13:24, Kevin Grittner
 wrote:
> "Nacho Mezzadra"  wrote:
>
>> could not start server
>> PostgreSQL 8.3 started successfully
>
> That looks like a packaging problem.  The lines starting with
> uppercase letters appear to have come from the service script, not
> PostgreSQL itself.
>
> -Kevin
>

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #5903: Turkish encoding problem

2011-02-28 Thread Sarp Akal 

The following bug has been logged online:

Bug reference:  5903
Logged by:  Sarp Akal
Email address:  s...@dms-tech.com
PostgreSQL version: 9.0.2
Operating system:   Windows Server 2008 R2 x64
Description:Turkish encoding problem
Details: 

The server is setup for UTF8 encoding and collation and character type are
Turkish_Turkey.1254

The following code fails:

select lower('İ')  --> Lowercase of turkish capital I-with dot returns
exactly the same character.

select upper('ı')  --> Uppercase of turkish small i-without dot returns
exactly the same character.

select lower('I')  --> Lowercase of turkish capital I returns i where it
should be i-without dot.

select upper('i')  --> Uppercase of turkish small returns I where it should
be I-with dot.

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs