On Fri, May 1, 2015 at 12:29 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, May 1, 2015 at 9:09 AM, Marko Tiikkaja wrote:
>>> We recently hit a similar case in our production environment. What was
>>> annoying about it is that there didn't seem to be a way for the application
>>> to fix t
Robert Haas writes:
> On Fri, May 1, 2015 at 9:09 AM, Marko Tiikkaja wrote:
>> We recently hit a similar case in our production environment. What was
>> annoying about it is that there didn't seem to be a way for the application
>> to fix the issue by itself, short of reconnecting; even DISCARD
Em sexta-feira, 1 de maio de 2015, Robert Haas
escreveu:
> On Fri, May 1, 2015 at 9:09 AM, Marko Tiikkaja > wrote:
> > On 2015-04-28 19:43, Robert Haas wrote:
> >> I guess
> >> the root of the problem is that PL/plgsql's cache invalidation logic
> >> only considers the pg_proc row's TID and xmin
On Fri, May 1, 2015 at 9:09 AM, Marko Tiikkaja wrote:
> On 2015-04-28 19:43, Robert Haas wrote:
>> I guess
>> the root of the problem is that PL/plgsql's cache invalidation logic
>> only considers the pg_proc row's TID and xmin when deciding whether to
>> recompile. For base types that's probably
On 2015-04-28 19:43, Robert Haas wrote:
I guess
the root of the problem is that PL/plgsql's cache invalidation logic
only considers the pg_proc row's TID and xmin when deciding whether to
recompile. For base types that's probably OK, but for composite
types, not so much.
Thoughts?
We recently
On Tue, Apr 28, 2015 at 3:59 PM, Tom Lane wrote:
> Robert Haas writes:
>> rhaas=# create table foo (a int);
>> CREATE TABLE
>> rhaas=# create or replace function test (x foo) returns int as $$begin
>> return x.b; end$$ language plpgsql;
>> CREATE FUNCTION
>> rhaas=# alter table foo add column b i
Robert Haas writes:
> rhaas=# create table foo (a int);
> CREATE TABLE
> rhaas=# create or replace function test (x foo) returns int as $$begin
> return x.b; end$$ language plpgsql;
> CREATE FUNCTION
> rhaas=# alter table foo add column b int;
> ALTER TABLE
> rhaas=# select test(null::foo);
> ERRO
On Tue, Apr 28, 2015 at 12:43 PM, Robert Haas wrote:
> I hate to use the term "bug" for what somebody's probably going to
> tell me is acceptable behavior, but that seems like a bug. I guess
> the root of the problem is that PL/plgsql's cache invalidation logic
> only considers the pg_proc row's
On 4/28/15 12:58 PM, Pavel Stehule wrote:
I hate to use the term "bug" for what somebody's probably going to
tell me is acceptable behavior, but that seems like a bug. I guess
the root of the problem is that PL/plgsql's cache invalidation logic
only considers the pg_proc row's TI
2015-04-28 19:43 GMT+02:00 Robert Haas :
> The following behavior surprised me, and a few other people at
> EnterpriseDB, and one of our customers:
>
> rhaas=# create table foo (a int);
> CREATE TABLE
> rhaas=# create or replace function test (x foo) returns int as $$begin
> return x.b; end$$ lang
The following behavior surprised me, and a few other people at
EnterpriseDB, and one of our customers:
rhaas=# create table foo (a int);
CREATE TABLE
rhaas=# create or replace function test (x foo) returns int as $$begin
return x.b; end$$ language plpgsql;
CREATE FUNCTION
rhaas=# alter table foo a
11 matches
Mail list logo
