Re: Performance issues with v18 SQL-language-function changes

Hi st 16. 4. 2025 v 19:43 odesílatel Tom Lane napsal: > Bruce Momjian writes: > > On Mon, Apr 14, 2025 at 10:38:29AM -0400, Robert Haas wrote: > >> I agree that we should do something about this. I haven't reviewed > >> your patches but the approach sounds broadly reasonable. > > > Yep, we went

Re: pg_dump --if-exists --clean when drop index that is partition of a partitioned index

út 15. 4. 2025 v 8:52 odesílatel jian he napsal: > On Tue, Apr 15, 2025 at 1:45 PM Pavel Stehule > wrote: > >> > >> seems pretty easy to fix. > >> we only need dropStmt when IndxInfo->parentidx oid is invalid. > >> >

Re: pg_dump --if-exists --clean when drop index that is partition of a partitioned index

út 15. 4. 2025 v 7:33 odesílatel jian he napsal: > On Mon, Apr 14, 2025 at 2:09 PM Pavel Stehule > wrote: > > > > Hi > > > > po 14. 4. 2025 v 7:54 odesílatel jian he > napsal: > >> > >> hi. > >> > >> CREATE TABLE tp(c int,

Re: FmgrInfo allocation patterns (and PL handling as staged programming)

Hi út 15. 4. 2025 v 2:32 odesílatel Chapman Flack napsal: > On 04/06/25 22:37, Tom Lane wrote: > > Here's a draft patch to fix the bogus dependencies. As given this'd > > only be okay for HEAD, since I doubt we can get away with changing > > ProcedureCreate()'s signature in stable branches ...

Re: Performance issues with v18 SQL-language-function changes

Hi po 14. 4. 2025 v 16:38 odesílatel Robert Haas napsal: > On Sun, Apr 13, 2025 at 3:23 PM Tom Lane wrote: > > create function fx(p_summa bigint) returns text immutable strict > > return ltrim(to_char(p_summa, '999 999 999 999 999 999 999 999')); > > > > explain analyze select fx(i) from genera

Re: pg_dump --if-exists --clean when drop index that is partition of a partitioned index

Hi po 14. 4. 2025 v 7:54 odesílatel jian he napsal: > hi. > > CREATE TABLE tp(c int, a int, b int) PARTITION BY RANGE (b); > CREATE TABLE tp_1(c int, a int, b int); > ALTER TABLE tp ATTACH PARTITION tp_1 FOR VALUES FROM (0) TO (1); > CREATE INDEX t_a_idx ON tp_1(a); > CREATE INDEX tp_a_idx ON tp

Re: Allow default \watch interval in psql to be configured

st 26. 3. 2025 v 13:24 odesílatel Daniel Gustafsson napsal: > > On 26 Mar 2025, at 10:12, Pavel Stehule wrote: > > > yes, it is ok after this change > > Thanks for confirming, committed. > Thank you Pavel > > -- > Daniel Gustafsson > >

Re: psql suggestion "select " offers nothing, can we get functions like "\df "

Hi čt 3. 4. 2025 v 20:17 odesílatel Tom Lane napsal: > Kirk Wolak writes: > > But "select " does nothing. > > What would you have it offer? Every single column and function name > in the database? Seems unlikely to be very helpful. > > postgres=# select count(distinct attname) from pg_attri

Re: Add partial :-variable expansion to psql \copy

Hi út 1. 4. 2025 v 12:00 odesílatel Christoph Berg napsal: > Re: Fabien Coelho > > (1) it seems that is the only command which is really full SQL hidden in > a > > backslash command > > Perhaps this form could be improved by changing `\copy (select) to file` > to something like `select \gcopy (t

Re: SQLFunctionCache and generic plans

Hi > We get substantial wins on all of fx, fx3, fx4. fx2 is the > case that gets inlined and never reaches functions.c, so the > lack of change there is expected. What I found odd is that > I saw a small speedup (~6%) on fx5 and fx6; those functions > are in plpgsql so they really shouldn't cha

Re: Allow default \watch interval in psql to be configured

st 26. 3. 2025 v 9:05 odesílatel Daniel Gustafsson napsal: > > On 26 Mar 2025, at 08:42, Pavel Stehule wrote: > > > The reason is probably my LANG=cs_CZ.UTF8. When I switched to LANG=C, > then tests passed. > > > > The main problem is in numeric format. Czech uses

Re: Allow default \watch interval in psql to be configured

st 26. 3. 2025 v 7:59 odesílatel Pavel Stehule napsal: > Hi > > út 25. 3. 2025 v 20:09 odesílatel Daniel Gustafsson > napsal: > >> > On 24 Mar 2025, at 13:42, Ashutosh Bapat >> wrote: >> >> > LGTM. I think this is RFC. Updated CF entry. >> &

Re: Allow default \watch interval in psql to be configured

Hi út 25. 3. 2025 v 20:09 odesílatel Daniel Gustafsson napsal: > > On 24 Mar 2025, at 13:42, Ashutosh Bapat > wrote: > > > LGTM. I think this is RFC. Updated CF entry. > > Thanks all for review, committed. > > regress tests fails now in my make[2]: Vstupuje se do adresáře „/home/pavel/src/post

Re: wrong error message related to unsupported feature

čt 20. 3. 2025 v 22:30 odesílatel Pavel Stehule napsal: > Hi > > út 18. 3. 2025 v 21:33 odesílatel Álvaro Herrera > napsal: > >> On 2025-Mar-18, Pavel Stehule wrote: >> >> > Maybe I found a bug >> > >> > (2025-03-18 19:28:06) postgres=# cre

Re: wrong error message related to unsupported feature

Hi út 18. 3. 2025 v 21:33 odesílatel Álvaro Herrera napsal: > On 2025-Mar-18, Pavel Stehule wrote: > > > Maybe I found a bug > > > > (2025-03-18 19:28:06) postgres=# create table foo(a int constraint gzero > > check(a > 10) NOT ENFORCED); > > CREATE T

wrong error message related to unsupported feature

Hi I am playing with new features in Postgres 18. Maybe I found a bug (2025-03-18 19:28:06) postgres=# create table foo(a int constraint gzero check(a > 10) NOT ENFORCED); CREATE TABLE (2025-03-18 19:29:37) postgres=# insert into foo values(0); INSERT 0 1 (2025-03-18 19:29:49) postgres=# insert

Re: Re: proposal: schema variables

Hi po 17. 3. 2025 v 21:53 odesílatel Marcos Pegoraro napsal: > Em seg., 17 de mar. de 2025 às 15:33, Pavel Stehule < > pavel.steh...@gmail.com> escreveu: > >> I was asked for sending a reduced patchset >> > > Would be good to explain what this reduced patchset i

Re: Prune partitions by ScalarArrayOpExpr with an array parameter (partkey = ANY($1))

po 17. 3. 2025 v 14:28 odesílatel Andrei Lepikhov napsal: > Hi, > > As I see, initial pruning doesn't work in the case when a > ScalarArrayOpExpr contains a parameter as the RHS of the expression, > like following: > > partkey = ANY($1) > > As colleagues say, it is quite typical to use stored pro

Re: SQLFunctionCache and generic plans

Hi I am checking last patches Maybe interesting change is the change of error message context QUERY: SELECT public.dep_req2() || ' req3b'. -CONTEXT: SQL function "dep_req3b" during startup +CONTEXT: SQL function "dep_req3b" statement 1 almost all SQL functions have just one statement, so s

Re: Send multiple statements to pg server at once

Hi út 11. 3. 2025 v 8:23 odesílatel Andy Fan napsal: > > > Hi, > > I want to simulate a case where server receive "SELECT 1;SELECT 2;" at > once, so when executing exec_simple_query, the query_string is > "SELECT 1;SELECT 2;" However I found it is not easy to simulate, does > anyone has a sugge

Re: SQLFunctionCache and generic plans

Hi čt 6. 3. 2025 v 9:57 odesílatel Alexander Pyhalov napsal: > Hi. > > Tom Lane писал(а) 2025-02-27 23:40: > > Alexander Pyhalov writes: > >> Now sql functions plans are actually saved. The most of it is a > >> simplified version of plpgsql plan cache. Perhaps, I've missed > >> something. > > >

possible ALTER TABLE ALTER COLUMN TYPE enhancing - safe mode

Hi Our customer reported an issue related to quiet precision lost when ALTER TABLE ALTER COLUMN was executed. The ALTER TABLE ALTER COLUMN TYPE is sometimes safe (2025-03-04 08:02:32) postgres=# create table t1(a varchar(10)); CREATE TABLE (2025-03-04 08:02:43) postgres=# INSERT INTO t1 VALUES('

Re: proposal - plpgsql - support standard syntax for named arguments for cursors

út 4. 3. 2025 v 0:04 odesílatel Tom Lane napsal: > Pavel Stehule writes: > >> po 24. 2. 2025 v 21:05 odesílatel Gilles Darold > >> napsal: > >>> I think it could be ready to be committed. > > Pushed with a docs/test correction: this also affects the sy

Re: SQLFunctionCache and generic plans

Hi pá 28. 2. 2025 v 7:29 odesílatel Pavel Stehule napsal: > Hi > > čt 27. 2. 2025 v 21:45 odesílatel Tom Lane napsal: > >> Pavel Stehule writes: >> > čt 27. 2. 2025 v 20:52 odesílatel Tom Lane napsal: >> >> So taken together, our results are all over

Re: SQLFunctionCache and generic plans

Hi čt 27. 2. 2025 v 21:45 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > čt 27. 2. 2025 v 20:52 odesílatel Tom Lane napsal: > >> So taken together, our results are all over the map, anywhere > >> from 7% speedup to 7% slowdown. My usual rule of thumb is th

Re: SQLFunctionCache and generic plans

čt 27. 2. 2025 v 20:52 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > čt 27. 2. 2025 v 13:25 odesílatel Alexander Pyhalov < > > a.pyha...@postgrespro.ru> napsal: > >>> Unfortunately, there is about 5% slowdown for inlined code, and for > >>>

Re: proposal: plpgsql, new check for extra_errors - strict_expr_check

Hi čt 27. 2. 2025 v 16:33 odesílatel Gilles Darold napsal: > Le 07/02/2025 à 23:00, Pavel Stehule a écrit : > > Hi > > > > I rewrote this patch. Instead of enhancing the main SQL parser, it > > does post parser checks of the parse tree. > > > > Now t

Re: proposal - plpgsql - support standard syntax for named arguments for cursors

Hi út 25. 2. 2025 v 6:32 odesílatel Pavel Stehule napsal: > Hi > > po 24. 2. 2025 v 21:05 odesílatel Gilles Darold > napsal: > >> Review: >> >> This patch claims to add SQL/PSM named arguments syntax to cursors and >> this what it does exactly. >&g

Re: SQLFunctionCache and generic plans

čt 27. 2. 2025 v 13:25 odesílatel Alexander Pyhalov < a.pyha...@postgrespro.ru> napsal: > Pavel Stehule писал(а) 2025-02-26 22:34: > > hI > > > > I can confirm 60% speedup for execution of function fx and fx3 - both > > functions are very primitive, so for real c

Re: SQLFunctionCache and generic plans

hI I can confirm 60% speedup for execution of function fx and fx3 - both functions are very primitive, so for real code the benefit can be higher Unfortunately, there is about 5% slowdown for inlined code, and for just plpgsql code too. I tested fx4 create or replace function fx4(int) returns i

Re: proposal - plpgsql - support standard syntax for named arguments for cursors

Hi po 24. 2. 2025 v 21:05 odesílatel Gilles Darold napsal: > Review: > > This patch claims to add SQL/PSM named arguments syntax to cursors and > this what it does exactly. > > It compiles without error with master current code and all tests > passed successfully. > > I think it could be ready

Re: psql \dh: List High-Level (Root) Tables and Indexes

po 24. 2. 2025 v 6:16 odesílatel Tom Lane napsal: > "David G. Johnston" writes: > > How about: > > \pset partition_roots_only 'true' > > FWIW, I don't especially love this idea. None of our existing > \d-type commands use pset parameters for filtering, and I don't > see a reason to believe that

Re: Proposal: pg_is_volatile function

Hi > What we have speculated about in the past is extending EXPLAIN > so that it can be applied to ALTER TABLE and other complicated > utility commands, and then for ALTER TABLE one bit of info it would > give you is whether a table rewrite (or even a table scan) is > required. Obviously, that's

broken munhttps://github.com/munin-monitoring/contrib/issues/1483in plugins for PostgreSQL 17

Hi Can somebody contact munin maintainers? The some plugins for PostgreSQL are particulari broken for PostgreSQL 15, but almost worked. When we migrated to PostgreSQL 17, then two plugins were fully broken. https://github.com/munin-monitoring/contrib/issues/1483 Unfortunately, the munin doesn't

Re: Proposal: pg_is_volatile function

Hi čt 20. 2. 2025 v 13:48 odesílatel Andrew Farries napsal: > I'd like to propose a new function `pg_is_volatile` that would test and > return > the volatility of its argument expression. Example uses of the function > would > be: > > pg_is_volatile(1) -> false > pg_is_volatile(random()) -> true

Re: missing assert in makeString

st 19. 2. 2025 v 19:05 odesílatel Andres Freund napsal: > Hi, > > On 2025-02-19 01:48:53 -0500, Tom Lane wrote: > > Pavel Stehule writes: > > > I investigated the crashes in "xmlnamespaces to xmlelement" patch and > it > > > looks like there was

Re: missing assert in makeString

Hi st 19. 2. 2025 v 7:48 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > I investigated the crashes in "xmlnamespaces to xmlelement" patch and it > > looks like there was a badly used makeString function. The argument > should > > not be null, elsew

missing assert in makeString

Hi I investigated the crashes in "xmlnamespaces to xmlelement" patch and it looks like there was a badly used makeString function. The argument should not be null, elsewhere serialization to string fails - and deserialization doesn't support this case. https://cirrus-ci.com/task/6543809942650880

Re: Is pgAdmin the only front-end to PostgreSQL debugger ? And is "a working pl/pgsql debugger" something core should care to maintain ?

Hi pá 14. 2. 2025 v 0:37 odesílatel Hannu Krosing napsal: > On Thu, Feb 13, 2025 at 8:10 PM Pavel Stehule > wrote: > > > > Hi > > > > čt 13. 2. 2025 v 18:00 odesílatel Hannu Krosing > napsal: > >> > >> Hallo PostgreSQL Hackers, > >

Re: Is pgAdmin the only front-end to PostgreSQL debugger ? And is "a working pl/pgsql debugger" something core should care to maintain ?

Hi čt 13. 2. 2025 v 18:00 odesílatel Hannu Krosing napsal: > Hallo PostgreSQL Hackers, > > > We recently discovered an error where pgAdmin fails when stepping into > nested function calls ( > https://github.com/pgadmin-org/pgadmin4/issues/8443 ). > > So while waiting for this to be fixed I would

Re: proposal - plpgsql - support standard syntax for named arguments for cursors

Hi so 8. 2. 2025 v 22:25 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > so 8. 2. 2025 v 20:25 odesílatel Tom Lane napsal: > >> Is there any reason to think that that's actually in the standard? > > > I think the possibility to use named a

Re: proposal - plpgsql - support standard syntax for named arguments for cursors

so 8. 2. 2025 v 22:25 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > so 8. 2. 2025 v 20:25 odesílatel Tom Lane napsal: > >> Is there any reason to think that that's actually in the standard? > > > I think the possibility to use named arguments in OPE

Re: proposal - plpgsql - support standard syntax for named arguments for cursors

Hi so 8. 2. 2025 v 20:25 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > I propose to enhancing to ANSI/SQL standard syntax for named arguments > > `argname => value` > > Is there any reason to think that that's actually in the standard? > I poked

Re: proposal - plpgsql - support standard syntax for named arguments for cursors

Hi so 8. 2. 2025 v 11:27 odesílatel Japin Li napsal: > On Sat, 08 Feb 2025 at 16:34, Julien Rouhaud wrote: > > Hi, > > > > On Sat, Feb 08, 2025 at 07:47:23AM +0100, Pavel Stehule wrote: > >> Hi > >> > >> when I worked on strict expr check pat

proposal - plpgsql - support standard syntax for named arguments for cursors

Hi when I worked on strict expr check patch I found so syntax for named arguments of cursors supports only our legacy proprietary syntax `argname := value` https://www.postgresql.org/docs/current/plpgsql-cursors.html I propose to enhancing to ANSI/SQL standard syntax for named arguments `argnam

Re: proposal: plpgsql, new check for extra_errors - strict_expr_check

Hi I rewrote this patch. Instead of enhancing the main SQL parser, it does post parser checks of the parse tree. Now the patch is significantly less invasive (changes are just in plpgsql - mostly in grammar), and it is smaller (without regress tests it has half size). This patch allows the detec

Re: problems with extensions compiling after upgrade to fc42 (and gcc15)

st 5. 2. 2025 v 21:55 odesílatel Peter Eisentraut napsal: > On 05.02.25 21:31, Pavel Stehule wrote: > > I found a problem with compilation of plpgsql_check when I upgraded my > > fedora. > > > > plpgsql_check cannot be compiled (against PostgreSQL 15-). The >

problems with extensions compiling after upgrade to fc42 (and gcc15)

Hi I found a problem with compilation of plpgsql_check when I upgraded my fedora. plpgsql_check cannot be compiled (against PostgreSQL 15-). The compilation fails rc/expr_walk.c:84:66: warning: passing argument 2 of ‘query_tree_walker’ from incompatible pointer type [-Wincompatible-pointer-types

Re: SQLFunctionCache and generic plans

Hi I did multiple benchmarking, and still looks so the proposed patch doesn't help and has significant overhead testcase: create or replace function fx(int) returns int as $$ select $1 + $1; $$ language sql immutable; create or replace function fx2(int) returns int as $$ select 2 * $1; $$ langua

Re: SQLFunctionCache and generic plans

po 3. 2. 2025 v 17:00 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > Did you do some performance checks? > > This is a good question to ask ... > > > I tried some worst case > > > CREATE OR REPLACE FUNCTION fx(int) > > RETURNS int AS $$ > >

Re: SQLFunctionCache and generic plans

Hi čt 30. 1. 2025 v 9:50 odesílatel Alexander Pyhalov napsal: > Alexander Pyhalov писал(а) 2025-01-29 17:35: > > Tom Lane писал(а) 2025-01-17 21:27: > >> Alexander Pyhalov writes: > >>> I've rebased patch on master. Tests pass here. > >> > >> The cfbot still doesn't like it; my guess is that yo

Re: Add XMLNamespaces to XMLElement

po 27. 1. 2025 v 14:57 odesílatel Umar Hayat napsal: > Pavel and Jim, > If that's the case, it looks good to me. > Just wanted to highlight potential issues and implementation > differences compared to other databases. > It is correct. Every Time there will be some differences - DB2 has an abs

Re: XMLDocument (SQL/XML X030)

so 25. 1. 2025 v 15:10 odesílatel Chapman Flack napsal: > On 01/25/25 02:16, Pavel Stehule wrote: > > because the function does nothing, then it is useless to convert input to > > XML and force detosting > > > > Maybe the body of the function should be just &g

Re: XMLDocument (SQL/XML X030)

so 25. 1. 2025 v 12:45 odesílatel Jim Jones napsal: > > On 25.01.25 11:50, Pavel Stehule wrote: > > you still forces detoasting (inside PG_GETARG_XML_P) > > > Ah, ok .. I overlooked it. You meant _DATUM instead of _XML_P > > Fixed in v8. > now it is ok. I&#

Re: XMLDocument (SQL/XML X030)

so 25. 1. 2025 v 9:10 odesílatel Jim Jones napsal: > > On 25.01.25 08:16, Pavel Stehule wrote: > > because the function does nothing, then it is useless to convert input > > to XML and force detosting > > Right. Fixed in v7 attached. > I don't see +Dat

Re: XMLDocument (SQL/XML X030)

pá 24. 1. 2025 v 23:11 odesílatel Jim Jones napsal: > > On 24.01.25 22:01, Chapman Flack wrote: > > It seems to me the key connection there is that the ISO SQL standard > > defines XMLDOCUMENT by equivalence to what `document { $expr }` means > > in the W3 XML Query standard. > > > It seems I mis

Re: XMLDocument (SQL/XML X030)

pá 24. 1. 2025 v 14:48 odesílatel Jim Jones napsal: > > On 24.01.25 13:48, Pavel Stehule wrote: > > Lot of users use XML functions without XMLDOCUMENT now. The doc should to > > help with a reply to question where and when I need (I can) use this > > function. This sho

Re: XMLDocument (SQL/XML X030)

pá 24. 1. 2025 v 13:21 odesílatel Jim Jones napsal: > > On 24.01.25 12:31, Pavel Stehule wrote: > > I don't know what it means - `function returns a document node` in the > > context of Postgres implementation of XML. > > I miss the information so it retu

Re: XMLDocument (SQL/XML X030)

pá 24. 1. 2025 v 9:12 odesílatel Jim Jones napsal: > Hi > > On 24.01.25 07:28, Pavel Stehule wrote: > > I think documentation should be strongly enhanced. This is probably > > the hardest part of this patch - explain well what this function does > > and what it does

Re: XMLDocument (SQL/XML X030)

čt 23. 1. 2025 v 16:06 odesílatel Jim Jones napsal: > Hi > > On 23.01.25 07:50, Pavel Stehule wrote: > > I think so in this form (just forward input to output) I have no > > objection. > > > > There is a benefit with a) possible zero work with migration from db2

Re: XMLDocument (SQL/XML X030)

Hi čt 23. 1. 2025 v 16:06 odesílatel Jim Jones napsal: > Hi > > On 23.01.25 07:50, Pavel Stehule wrote: > > I think so in this form (just forward input to output) I have no > > objection. > > > > There is a benefit with a) possible zero work with migration

Re: XMLDocument (SQL/XML X030)

čt 23. 1. 2025 v 0:55 odesílatel Jim Jones napsal: > Hi Chapman & Robert > > Many thanks for the input > > On 22.01.25 22:35, Chapman Flack wrote: > > On 01/22/25 13:41, Robert Treat wrote: > >> So even if we are following the spec (which I think technically we may > >> not be), > > There are def

Re: Add XMLNamespaces to XMLElement

Hi út 21. 1. 2025 v 11:45 odesílatel Umar Hayat napsal: > On Tue, 21 Jan 2025 at 04:04, Jim Jones wrote: > > > > Hi Umar > > > > On 20.01.25 17:19, Umar Hayat wrote: > > > Hi Jim & Pavel, > > > Sorry for getting back a bit late on this. Few more case you might > > > need consider: > > > > > > A

Re: Re: proposal: schema variables

Hi po 20. 1. 2025 v 8:56 odesílatel Álvaro Herrera napsal: > On 2025-Jan-17, Bruce Momjian wrote: > > > Is this really something we are considering applying, since it has been > > around for years? I am unclear on that and we had better know if we are > > going to continue reviewing this. > > T

Re: Fwd: Re: proposal: schema variables

pá 17. 1. 2025 v 16:35 odesílatel Bruce Momjian napsal: > On Fri, Jan 17, 2025 at 04:32:07PM +0100, Pavel Stehule wrote: > > This discussion was around 2017 when I wrote a proposal and I hadn't a > feeling > > 2017 is seven years ago so it would be good to get cu

Fwd: Re: proposal: schema variables

Hi pá 17. 1. 2025 v 15:39 odesílatel Bruce Momjian napsal: > On Fri, Jan 17, 2025 at 03:28:55PM +0100, Pavel Stehule wrote: > > Dne pá 17. 1. 2025 15:16 uživatel Bruce Momjian > napsal: > > Is this really something we are considering applying, since it has > been >

Re: Re: proposal: schema variables

Hi pá 17. 1. 2025 v 14:41 odesílatel Bruce Momjian napsal: > On Fri, Jan 17, 2025 at 08:18:20AM +0100, Pavel Stehule wrote: > > Hi > > > > fix oid collision > > What is the purpose of continually posting this patch to the email > lists? > The people still do a

Re: Add XMLNamespaces to XMLElement

Hi st 15. 1. 2025 v 21:35 odesílatel Jim Jones napsal: > Hi Umar, Hi Pavel, > > On 26.12.24 14:46, Jim Jones wrote: > > The idea of NO DEFAULT is pretty much to free an element (and its > > children) from a previous DEFAULT in the same scope. > > > > SELECT > > xmlserialize(DOCUMENT > > xm

Re: XMLDocument (SQL/XML X030)

st 15. 1. 2025 v 22:05 odesílatel Jim Jones napsal: > Hi Pavel > > On 14.01.25 09:14, Pavel Stehule wrote: > > I did some research and the design of this document is different > > > > 1. Oracle doesn't support this > > 2. DB2 has different implementa

Re: XMLDocument (SQL/XML X030)

Hi út 14. 1. 2025 v 8:11 odesílatel Jim Jones napsal: > Hi, > > I'd like to propose the implementation of XMLDocument (SQL/XML X030).It > basically returns an XML document from a given XML expression, e.g. > > SELECT >xmldocument( > xmlelement(NAME foo, >xmlattributes(42 AS att)

Re: proposal: plpgsql, new check for extra_errors - strict_expr_check

Hi fresh rebase Regards Pavel From 4e582d825af9d3463be332a90b9e959980480293 Mon Sep 17 00:00:00 2001 From: "ok...@github.com" Date: Wed, 12 Jun 2024 21:34:05 +0200 Subject: [PATCH 1/3] use strict rules for parsing PL/pgSQL expressions Originally the rule PLpgSQL_Expr allows almost all SQL clau

Re: why there is not VACUUM FULL CONCURRENTLY?

Hi čt 9. 1. 2025 v 14:35 odesílatel Alvaro Herrera napsal: > On 2024-Dec-11, Antonin Houska wrote: > > > Oh, it was too messy. I think I was thinking of too many things at once > (such > > as locking the old heap, the new heap and the new heap's TOAST). Also, > one > > thing that might have cont

Re: Re: proposal: schema variables

ne 5. 1. 2025 v 17:11 odesílatel jian he napsal: > + /* > + * The arguments of EXECUTE are evaluated by a direct expression > + * executor call. This mode doesn't support session variables yet. > + * It will be enabled later. > + */ > + if (pstate->p_hasSessionVariables) > + elog(ERROR, "session

Re: Re: proposal: schema variables

Hi ne 5. 1. 2025 v 5:52 odesílatel jian he napsal: > diff --git a/src/include/nodes/primnodes.h b/src/include/nodes/primnodes.h > index 9c2957eb546..624858db301 100644 > --- a/src/include/nodes/primnodes.h > +++ b/src/include/nodes/primnodes.h > @@ -361,6 +361,9 @@ typedef struct Const > * of

Re: Add XMLNamespaces to XMLElement

gt; xmlnamespaces(DEFAULT 'http:/x.y/ns1'), > xmlelement(NAME "foo", > xmlnamespaces(NO DEFAULT)) > ) AS text INDENT); > > xmlserialize > -- > + > + > > (1 row) > >

Re: SQLFunctionCache and generic plans

Hi út 31. 12. 2024 v 16:36 odesílatel Alexander Pyhalov < a.pyha...@postgrespro.ru> napsal: > Hi. > > >> What should we do with "pre-parsed" SQL functions (when prosrc is > >> empty)? How should we create cached plans when we don't have raw > >> parsetrees? > >> Currently we can create cached pla

Re: Re: proposal: schema variables

Hi >> + { >> + /* the last field of list can be star too */ >> + Assert(IsA(field2, A_Star)); >> + >> + /* >> + * In this case, the field1 should be variable name. But >> + * direct unboxing of composite session variables is not >> + * supported now, and then we don't need to try lookup >> + * re

Re: Re: proposal: schema variables

Hi so 28. 12. 2024 v 11:35 odesílatel jian he napsal: > hi. > > src9=# select 'XLogRecPtr'::regtype; > ERROR: type "xlogrecptr" does not exist > LINE 1: select 'XLogRecPtr'::regtype; >^ > so > + varcreate_lsn XLogRecPtr > should be > varcreate_lsn pg_lsn > ? > done > > also >

Re: Re: proposal: schema variables

Hi pá 27. 12. 2024 v 16:20 odesílatel jian he napsal: > hi. > > + if (!OidIsValid(varid)) > + AcceptInvalidationMessages(); > + else if (OidIsValid(varid)) > + LockDatabaseObject(VariableRelationId, varid, 0, AccessShareLock); > > we can change it to > + if (!OidIsValid(varid)) > + AcceptInvalid

Re: cannot to compile extension by meson on windows

pá 27. 12. 2024 v 9:50 odesílatel Vladlen Popolitov < v.popoli...@postgrespro.ru> napsal: > Pavel Stehule писал(а) 2024-12-01 20:52: > > Hi > > > > Did somebody test compilation of any extension on the WIN platform by > > using meson? > > > > I prepa

Re: Add XMLNamespaces to XMLElement

Hi so 21. 12. 2024 v 0:51 odesílatel Jim Jones napsal: > Hi, > > I'd like to propose the implementation of the XMLNamespaces option for > XMLElement. > > XMLNAMESPACES(nsuri AS nsprefix) > XMLNAMESPACES(DEFAULT default-nsuri) > XMLNAMESPACES(NO DEFAULT) > > * nsprefix: Namespace's p

Re: OLEDB provider for PostgreSQL

Hi pá 13. 12. 2024 v 15:22 odesílatel Zaid Shabbir napsal: > Hello, > > I am looking for an OLEDB provider for PostgreSQL 16 or later. I found one > link, but it seems that it does not support PostgreSQL 16+ and, > additionally, it is not free. > > PostgreSQL: PostgreSQL Native OLEDB Provider (P

Re: proposal: schema variables

Hi st 20. 11. 2024 v 21:14 odesílatel Dmitry Dolgov <9erthali...@gmail.com> napsal: > > On Tue, Nov 19, 2024 at 08:14:01PM +0100, Pavel Stehule wrote: > > Hi > > > > I wrote POC of VARIABLE(varname) syntax support > > Thanks, the results look good. I&

Re: cannot to compile extension by meson on windows

ne 1. 12. 2024 v 22:24 odesílatel Pavel Stehule napsal: > > > ne 1. 12. 2024 v 21:16 odesílatel Pavel Stehule > napsal: > >> >> >> ne 1. 12. 2024 v 21:06 odesílatel Pavel Stehule >> napsal: >> >>> >>> >>> ne 1. 12. 2024

Re: cannot to compile extension by meson on windows

ne 1. 12. 2024 v 21:16 odesílatel Pavel Stehule napsal: > > > ne 1. 12. 2024 v 21:06 odesílatel Pavel Stehule > napsal: > >> >> >> ne 1. 12. 2024 v 19:23 odesílatel Andres Freund >> napsal: >> >>> Hi, >>> >>> On 2024

Re: cannot to compile extension by meson on windows

ne 1. 12. 2024 v 21:06 odesílatel Pavel Stehule napsal: > > > ne 1. 12. 2024 v 19:23 odesílatel Andres Freund > napsal: > >> Hi, >> >> On 2024-12-01 19:11:05 +0100, Pavel Stehule wrote: >> > ne 1. 12. 2024 v 19:05 odesílatel Andres Freund >>

Re: cannot to compile extension by meson on windows

ne 1. 12. 2024 v 19:23 odesílatel Andres Freund napsal: > Hi, > > On 2024-12-01 19:11:05 +0100, Pavel Stehule wrote: > > ne 1. 12. 2024 v 19:05 odesílatel Andres Freund > napsal: > > > If it fails due to libintl you're likely missing the libintl headers > tha

Re: cannot to compile extension by meson on windows

ne 1. 12. 2024 v 19:05 odesílatel Andres Freund napsal: > Hi, > > On 2024-12-01 18:52:48 +0100, Pavel Stehule wrote: > > Did somebody test compilation of any extension on the WIN platform by > using > > meson? > > > > I prepared meson.build > > ht

cannot to compile extension by meson on windows

Hi Did somebody test compilation of any extension on the WIN platform by using meson? I prepared meson.build https://github.com/orafce/orafce/blob/master/meson.build I tested it successfully on Linux. But it fails on Windows - a lot of compilation fails on missing libintl.h DOCDIR = C:/PROGRA~

Re: how to get MAJORVERSION in meson

so 30. 11. 2024 v 16:42 odesílatel jian he napsal: > On Fri, Nov 29, 2024 at 7:09 PM Pavel Stehule > wrote: > > > > > > > > pá 29. 11. 2024 v 10:42 odesílatel Pavel Stehule < > pavel.steh...@gmail.com> napsal: > >> > >> Hi > >>

Re: how to get MAJORVERSION in meson

pá 29. 11. 2024 v 10:42 odesílatel Pavel Stehule napsal: > Hi > > I tried to add meson support to plpgsql_check. As template I used > https://raw.githubusercontent.com/petere/plsh/refs/heads/meson/meson.build > > Unfortunately, for tests I need to know MAJORVERSION. In makefil

how to get MAJORVERSION in meson

Hi I tried to add meson support to plpgsql_check. As template I used https://raw.githubusercontent.com/petere/plsh/refs/heads/meson/meson.build Unfortunately, for tests I need to know MAJORVERSION. In makefile I use ifndef MAJORVERSION MAJORVERSION := $(basename $(VERSION)) endif Is there some

Re: proposal: schema variables

st 20. 11. 2024 v 21:14 odesílatel Dmitry Dolgov <9erthali...@gmail.com> napsal: > > On Tue, Nov 19, 2024 at 08:14:01PM +0100, Pavel Stehule wrote: > > Hi > > > > I wrote POC of VARIABLE(varname) syntax support > > Thanks, the results look good. I'm sti

Re: proposal: schema variables

st 20. 11. 2024 v 15:15 odesílatel Marcos Pegoraro napsal: > Em qua., 20 de nov. de 2024 às 10:52, Pavel Stehule < > pavel.steh...@gmail.com> escreveu: > >> COMMIT can be a little bit messy. TRANSACTION END is more intuitive, I >> think. >> >>> > E

Re: proposal: schema variables

Hi st 20. 11. 2024 v 14:29 odesílatel Marcos Pegoraro napsal: > Em ter., 19 de nov. de 2024 às 16:15, Pavel Stehule < > pavel.steh...@gmail.com> escreveu: > >> I wrote POC of VARIABLE(varname) syntax support >> > > Not related with POC of VARIABLE but seeing yo

Re: Using Expanded Objects other than Arrays from plpgsql

ago I tried to compress what I learned about expanded > objects into a dummy extension that just provides the necessary > boilerplate. It wasn't great but a start: > > https://github.com/michelp/pgexpanded > > Pavel Stehule indicated this might be a good example to

Re: proposal: schema variables

so 16. 11. 2024 v 15:56 odesílatel Wolfgang Walther napsal: > Dmitry Dolgov: > > This sounds to me like an argument against allowing name clashing between > > variables and tables. It makes even more sense, since session variables > are in > > many ways similar to tables. > > +1 > It doesn't hel

Re: proposal: schema variables

so 16. 11. 2024 v 23:07 odesílatel Pavel Stehule napsal: > > > so 16. 11. 2024 v 18:13 odesílatel Wolfgang Walther < > walt...@technowledgy.de> napsal: > >> Pavel Stehule: >> > (global (temp)) table can hold 0, 1 or more rows (and rows are always >>

Re: proposal: schema variables

so 16. 11. 2024 v 23:49 odesílatel Pavel Stehule napsal: > > > so 16. 11. 2024 v 15:27 odesílatel Dmitry Dolgov <9erthali...@gmail.com> > napsal: > >> > On Sat, Nov 16, 2024 at 07:10:31AM GMT, Pavel Stehule wrote: >> >> Sorry, got distracted. Let me tr

Re: proposal: schema variables

so 16. 11. 2024 v 15:27 odesílatel Dmitry Dolgov <9erthali...@gmail.com> napsal: > > On Sat, Nov 16, 2024 at 07:10:31AM GMT, Pavel Stehule wrote: > > Sorry, got distracted. Let me try to answer step by step. > > > > As far as I recall, last time this topic

  1   2   3   4   5   6   7   8   9   10   >