quot; does not. Does anyone
know why, and/or is it possible for anyone else to reproduce the
problem?
Kind regards,
Jan Behrens
RIALIZABLE READ ONLY achieve that REPEATABLE READ READ ONLY
does not? And what is SERIALIZABLE READ ONLY DEFERRABLE for?
Any hints to make me better understand this issue are appreciated.
Kind regards,
Jan Behrens
On Thu, 26 Nov 2020 19:13:53 -0500
Mohamed Wael Khobalatte wrote:
> >
> > Thus, what does SERIALIZABLE READ ONLY achieve that REPEATABLE READ READ
> > ONLY does not? And what is SERIALIZABLE READ ONLY DEFERRABLE for?
> >
>
> There is a nice walkthrough of the "control" and "batches/details" scen
ree cases.
I wonder if this is a bug in the query planner, in the GiST facilities
of PostgreSQL, a problem of the "btree_gist" extension, or something
else? Can anyone help me?
Kind regards,
Jan Behrens
--
Public Software Group e. V.
Johannisstr. 12, 10117 Berlin, Germany
www.pub
On Mon, 03 Dec 2018 11:47:17 -0500
Tom Lane wrote:
> Jan Behrens writes:
>
> > However, the GiST index seems not to work as expected by me when
> > 64-bit integers are involved. I tried to create a minimal
> > proof-of-concept to demonstrate this. Consider the followin
rns multiple result sets?
These questions are relevant to me because it may have an effect on the
API design if a statement can return several result sets.
Kind regards,
Jan Behrens
of the
documentation.
https://www.postgresql.org/docs/16/errcodes-appendix.html
My current approach is to just set "*" as an error code, which doesn't
feel good:
https://github.com/JanBeh/neumond/blob/9889c5fc19dbb23dff483e4a1cb2e4ef3ab74085/pgeff.c#L332-L345
Maybe I'm just o
On Wed, 10 Apr 2024 19:02:48 -0400
Tom Lane wrote:
> Jan Behrens writes:
> > While writing a PostgreSQL client library for Lua supporting
> > Pipelining (using PQsendQueryParams), I have been wondering if there
> > are any single SQL commands that return multiple result se
fully-qualified types in the DECLARE
section only? Or do I need to provide full qualification also in the
code below (after SET search_path TO 'myschema')?
And bonus question: Is it documented somewhere?
Maybe not many people run into these issues because schemas and
functions aren't used as often in combination?
Kind Regards
Jan Behrens
On Fri, 3 Jan 2025 08:34:57 -0700
"David G. Johnston" wrote:
> On Friday, January 3, 2025, Jan Behrens wrote:
> >
> > I would like to know if the above example is correct. It seems overall
> > bulky, but I haven't found a better way, assuming that it c
ying on it. That non-reliance is all that
> really matters.
>
> David J.
But if I use "SET search_path FROM CURRENT", then the called function
won't know the search_path that is set at the caller's side (which is
what I need to make my interface nice to use).
I would prefer my current solution, but I would like to be sure that my
example (the one in my e-mail dated Fri, 3 Jan 2025 13:53:32 +0100) is
correct. I still am not sure about that.
Kind Regards,
Jan Behrens
y overall idea.
My problem is that I'm confused about WHEN EXACTLY I have to qualify
tables/types, etc. It is very hard to understand from reading (just) the
documentation.
Kind Regards,
Jan Behrens
On Sat, 4 Jan 2025 00:22:03 +0100
Jan Behrens wrote:
>
> -- Do I have to fully qualify types and operators from
> -- "myschema" here? Or is it safe to not
On Sat, 28 Dec 2024 00:40:09 +0100
Jan Behrens wrote:
> 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-CACHI
27;,
and '5.4'). To me, this behavior seems to be somewhat dangerous. Maybe it is
even considered a bug? Or is it documented somewhere? I remember running into
some problems like that in the past already, but unfortunately, I don't
remember details.
I suppose this is because there
formation about when to DETOAST and when not?
Also: Is my approach an idiomatic way to implement unary plus? Are there
pre-existing functions for that?
Many thanks in advance for your help and kind regards
Jan Behrens
On Wed, 1 Jan 2025 11:19:32 -0700
"David G. Johnston" wrote:
> On Wed, Jan 1, 2025 at 10:55 AM Jan Behrens wrote:
>
> > On Sat, 28 Dec 2024 00:40:09 +0100
> > Jan Behrens wrote:
> >
> > > On Fri, 27 Dec 2024 13:26:28 -0700
> > > "David
On Thu, 2 Jan 2025 13:48:29 +0100
Pavel Stehule wrote:
> čt 2. 1. 2025 v 13:15 odesílatel Jan Behrens
> napsal:
>
> > On Thu, 2 Jan 2025 12:40:59 +0100
> > Pavel Stehule wrote:
> >
> > > How can you identify unwanted usage of non qualified identifiers from
On Sat, 28 Dec 2024 00:40:09 +0100
Jan Behrens wrote:
> > Add qualification or attach a “set search_path” clause to “create
> > function”. Code stored in the server should not rely on the session
> > search_path.
> >
> > David J.
I have been trying to adjust som
On Fri, 3 Jan 2025 18:36:13 -0500
Isaac Morland wrote:
> On Fri, 3 Jan 2025 at 18:22, Jan Behrens wrote:
>
>
> > Instead, I plan to expect the function to receive a query string that
> > will get the data that is being processed by the function.
> >
> > That
On Sat, 4 Jan 2025 09:37:14 -0800
Adrian Klaver wrote:
> On 1/3/25 15:22, Jan Behrens wrote:
> > On Fri, 3 Jan 2025 13:56:02 -0800
> > Adrian Klaver wrote:
> >
> >> At this point I am lost as to what the overall goal of this is.
> >>
> >> Can y
ot possible and
will be rejected by PostgreSQL.
* It is a bit unclear how the exact behavior is when I set a
search_path from within the functions body (e.g. due to one of the two
scenarios above). There are some examples that show some quite
surprising behavior, at least if you don't fully understand the
plan caching mechanism that is used.
Kind regards,
Jan Behrens
On Thu, 2 Jan 2025 12:40:59 +0100
Pavel Stehule wrote:
> How can you identify unwanted usage of non qualified identifiers from
> wanted usage of non qualified identifiers? It is a common pattern for
> sharding. Using not qualified identifiers of operators, functions is common
> when you are using
t an expression. So does the "first
row gets used" rule also apply in my context, and why so?
For example, the following command results in an error:
SELECT (SELECT generate_series(1, 10));
ERROR: more than one row returned by a subquery used as an expression
Kind regards and thanks for your advice,
Jan Behrens
24 matches
Mail list logo
