Re: search_path for PL/pgSQL functions partially cached?

Hi > Maybe not many people run into these issues because schemas and > functions aren't used as often in combination? > I think schema and functions are common combinations. But when people have objects with the same name, then they are careful to be sure, so objects have really identical struct

Re: search_path for PL/pgSQL functions partially cached?

On Fri, 27 Dec 2024 13:26:28 -0700 "David G. Johnston" wrote: > > Or is it documented somewhere? > > https://www.postgresql.org/docs/current/plpgsql-implementation.html#PLPGSQL-PLAN-CACHING I can't find any notes regarding functions and schemas in that section. > Can someone explain to me what

Re: search_path for PL/pgSQL functions partially cached?

pá 27. 12. 2024 v 22:03 odesílatel Tom Lane napsal: > "David G. Johnston" writes: > > It is what it is - and if one is not careful one can end up writing > > hard-to-understand and possibly buggy code due to the various execution > > environments and caches involved. > > Yeah, I don't see this c

Re: search_path for PL/pgSQL functions partially cached?

"David G. Johnston" writes: > It is what it is - and if one is not careful one can end up writing > hard-to-understand and possibly buggy code due to the various execution > environments and caches involved. Yeah, I don't see this changing. The actual answer is that we have search_path-aware cac

Re: search_path for PL/pgSQL functions partially cached?

On 12/27/24 12:26, David G. Johnston wrote: On Friday, December 27, 2024, Jan Behrens > wrote: It seems that it matters *both* how the search_path was set during the *first* invocation of the function within a session *and* how it is set during the ac

Re: search_path for PL/pgSQL functions partially cached?

Hi pá 27. 12. 2024 v 21:26 odesílatel David G. Johnston < david.g.johns...@gmail.com> napsal: > On Friday, December 27, 2024, Jan Behrens wrote: >> >> >> It seems that it matters *both* how the search_path was set during the >> *first* invocation of the function within a session *and* how it is

Re: search_path for PL/pgSQL functions partially cached?

On Friday, December 27, 2024, Jan Behrens wrote: > > > It seems that it matters *both* how the search_path was set during the > *first* invocation of the function within a session *and* how it is set > during the actual call of the function. So even if there are just two > schemas involved, there

search_path for PL/pgSQL functions partially cached?

Hello, I'm experiencing some weird issues when running the following code in a psql session: CREATE TABLE "tbl" ("col" NUMERIC(15, 0)); CREATE FUNCTION "foo"() RETURNS TEXT LANGUAGE plpgsql AS $$ BEGIN RETURN '2.4'; END; $$; BEGIN; CREATE SCHEMA "myschema"; SET LOCAL sea

Re: Starting logical replication at arbitrary point that's available in WAL

On 12/27/24 13:20, Zhijie Hou (Fujitsu) wrote: On Friday, December 27, 2024 7:39 PM Alexander Uvizhev wrote: Hi, I'm doing a logical replication using streaming replication protocol and I'm trying to start a stream from a certain arbitrary point that's available in WAL. However, both CREATE_R

RE: Starting logical replication at arbitrary point that's available in WAL

On Friday, December 27, 2024 7:39 PM Alexander Uvizhev wrote: Hi, > I'm doing a logical replication using streaming replication protocol and > I'm trying to start a stream from a certain arbitrary point that's > available in WAL. However, both CREATE_REPLICATION_SLOT and > pg_create_logical_rep

Starting logical replication at arbitrary point that's available in WAL

Hi, I'm doing a logical replication using streaming replication protocol and I'm trying to start a stream from a certain arbitrary point that's available in WAL. However, both CREATE_REPLICATION_SLOT and pg_create_logical_replication_slot() create slot with nearly last LSN/XID. Is it possible