Re: proposal: schema variables

so 2. 11. 2024 v 6:46 odesílatel Laurenz Albe napsal: > On Tue, 2024-10-29 at 08:16 +0100, Pavel Stehule wrote: > > again, necessary rebase > > I have started looking at patch 5, and I have some questions and comments. > > - The commit message is headed "memory cleaning

Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)

ne 27. 10. 2024 v 18:42 odesílatel Tom Lane napsal: > I wrote: > > In the no-good-deed-goes-unpunished department: buildfarm member > > hamerkop doesn't like this patch [1]. The diffs look like > > ... > > So what I'd like to do to fix this is to change > > - if ((file = AllocateFile(filenam

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

Hi fresh rebase Regards Pavel From 0a1e5a4de6d45e2b4e0f047d4aa9dab5ddeb6b2d Mon Sep 17 00:00:00 2001 From: "ok...@github.com" Date: Sun, 16 Jun 2024 08:13:53 +0200 Subject: [PATCH 2/3] simply check of strict-expr-check on regress test This patch enable strict-expr-check by default to be possib

Re: proposal: schema variables

st 23. 10. 2024 v 6:11 odesílatel Laurenz Albe napsal: > I have gone over patch 3 from the set and worked on the comments. > > Apart from that, I have modified your patch as follows: > > > +/* > > + * pg_session_variables - designed for testing > > + * > > + * This is a function designed for test

Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)

út 22. 10. 2024 v 17:37 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > I'll mark this patch as ready for committer. > > Pushed then. Thanks for reviewing! > Thank you for this patch. It is really practical Regards Pavel > > regards, tom lane >

Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)

Hi pá 11. 10. 2024 v 19:39 odesílatel Pavel Stehule napsal: > > > pá 11. 10. 2024 v 18:08 odesílatel Tom Lane napsal: > >> Pavel Stehule writes: >> > I tested it and it is working nicely. I tested it against Orafce and I >> > found an interesting point.

Re: Wrong security context for deferred triggers?

so 19. 10. 2024 v 13:02 odesílatel Laurenz Albe napsal: > On Sat, 2024-10-19 at 06:17 +0200, Pavel Stehule wrote: > > Maybe we should document so the trigger is executed with the identity > used by DML command always, > > when the trigger function has no SECURITY DEFINER f

Re: [PATCH] Add some documentation on how to call internal functions

pá 18. 10. 2024 v 22:23 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > I'll mark this patch as ready for committer > > I spent a little time looking at this. I agree that it's better to > show conversion of the example function's arguments to and from

Re: Wrong security context for deferred triggers?

Hi pá 18. 10. 2024 v 15:24 odesílatel Laurenz Albe napsal: > On Fri, 2024-10-18 at 11:32 +0200, Pavel Stehule wrote: > > pá 18. 10. 2024 v 10:20 odesílatel Laurenz Albe < > laurenz.a...@cybertec.at> napsal: > > > On Fri, 2024-10-18 at 07:47 +0200, Pavel Stehule wr

Re: Wrong security context for deferred triggers?

pá 18. 10. 2024 v 10:20 odesílatel Laurenz Albe napsal: > On Fri, 2024-10-18 at 07:47 +0200, Pavel Stehule wrote: > > Without deeper checks I don't like using GetUserNameFromId for checking > the validity of a role. > > > > Maybe it is better to use

Re: Wrong security context for deferred triggers?

Hi pá 18. 10. 2024 v 7:22 odesílatel Laurenz Albe napsal: > On Wed, 2024-03-06 at 14:32 +0100, Laurenz Albe wrote: > > On Mon, 2023-11-06 at 18:29 +0100, Tomas Vondra wrote: > > > On 11/6/23 14:23, Laurenz Albe wrote: > > > > This behavior looks buggy to me. What do you think? > > > > I cannot

Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)

po 14. 10. 2024 v 5:38 odesílatel jian he napsal: > On Mon, Oct 14, 2024 at 1:13 AM Tom Lane wrote: > > > > Pavel Stehule writes: > > > so 12. 10. 2024 v 9:33 odesílatel jian he > > > > napsal: > > >> + /* > > >> + * If we have

Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)

so 12. 10. 2024 v 9:33 odesílatel jian he napsal: > On Wed, Oct 9, 2024 at 4:18 AM Tom Lane wrote: > > > > > In the attached v4 > > > in the upper code two branch, both will call CleanQuerytext > so in script_error_callback > > + /* > + * If we have a location (which, as said above, we really al

Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)

pá 11. 10. 2024 v 18:08 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > I tested it and it is working nicely. I tested it against Orafce and I > > found an interesting point. The body of plpgsql functions is not checked. > > Do you know the reason? > >

Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)

Hi út 8. 10. 2024 v 22:18 odesílatel Tom Lane napsal: > I wrote: > > ... There's still a question > > of whether reporting the whole script as the query is OK when > > we have a syntax error, but I have no good ideas as to how to > > make that terser. > > I had an idea about this: we can use a p

Re: [PATCH] Add some documentation on how to call internal functions

Hi st 9. 10. 2024 v 20:54 odesílatel Florents Tselai napsal: > Here's a v2 > - note on NULL args/returns > - ref PointerGetDatum > - used your example. Started adding some comments but don't think they're > really necessary. The reader gets the point as-is I think. > Now, I don't see any issue

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

čt 10. 10. 2024 v 2:02 odesílatel Michael Paquier napsal: > On Wed, Oct 09, 2024 at 04:24:27PM +0200, Daniel Gustafsson wrote: > > Fixed. > > -doublesleep = 2; > +doublesleep = pset.watch_interval; > > This forces the use of seconds as unit. The interval values I

Re: [PATCH] Add some documentation on how to call internal functions

st 9. 10. 2024 v 14:39 odesílatel Florents Tselai napsal: > > > On 9 Oct 2024, at 2:57 PM, Pavel Stehule wrote: > > Hi > > I am checking this patch > > čt 12. 9. 2024 v 11:42 odesílatel Florents Tselai < > florents.tse...@gmail.com> napsal: > >> Hi,

Re: [PATCH] Add some documentation on how to call internal functions

Hi I am checking this patch čt 12. 9. 2024 v 11:42 odesílatel Florents Tselai napsal: > Hi, > > The documentation on extending using C functions, > leaves a blank on how to call other internal Postgres functions. > This can leave first-timers hanging. > > I think it’d be helpful to spend some p

Re: SET ROLE and parameter status

Hi pá 4. 10. 2024 v 15:16 odesílatel Tatsuo Ishii napsal: > Sorry if this has been discussed before. > > I wonder why SET ROLE command does not produce a parameter status > message noticing the new current_user. Note that SET > SESSION_AUTHORIZATION command produces a parameter status message fo

Re: Get TupleDesc for extension-defined types

st 18. 9. 2024 v 16:25 odesílatel Florents Tselai napsal: > > > On Wed, Sep 18, 2024 at 1:09 PM Pavel Stehule > wrote: > >> Hi >> >> st 18. 9. 2024 v 9:04 odesílatel Florents Tselai < >> florents.tse...@gmail.com> napsal: >> >>> Co

Re: Get TupleDesc for extension-defined types

st 18. 9. 2024 v 9:04 odesílatel Florents Tselai napsal: > Correct me if I'm wrong, > but for an extension that defines composite types, > there's currently no easy way to get a TupleDesc, even for its own types. > > Something like > TupleDesc get_extension_type_tupledesc(const char *extname, con

Re: Get TupleDesc for extension-defined types

Hi st 18. 9. 2024 v 9:04 odesílatel Florents Tselai napsal: > Correct me if I'm wrong, > but for an extension that defines composite types, > there's currently no easy way to get a TupleDesc, even for its own types. > > Something like > TupleDesc get_extension_type_tupledesc(const char *extname,

Re: broken build - FC 41

Hi st 11. 9. 2024 v 9:54 odesílatel Daniel Gustafsson napsal: > > On 9 Sep 2024, at 15:20, Pavel Stehule wrote: > > > The question is why the missing header was not detected by configure? > > We don't test for every 3rd party header we include. If engines were >

Re: broken build - FC 41

po 9. 9. 2024 v 13:57 odesílatel Daniel Gustafsson napsal: > > On 9 Sep 2024, at 13:45, Pavel Stehule wrote: > > > echo 'Libs.private: -L/usr/lib64 -lpgcommon -lpgport -lssl -lm' > >>libpq.pc > > fe-secure-openssl.c:62:10: fatal error: openssl/en

Re: broken build - FC 41

po 9. 9. 2024 v 13:58 odesílatel Herbert J. Skuhra napsal: > On Mon, 09 Sep 2024 13:45:50 +0200, Pavel Stehule wrote: > > > > Hi > > > > I try new Fedora 41. Build fails > > > > echo 'Name: libpq' >>libpq.pc > > echo 'Desc

broken build - FC 41

Hi I try new Fedora 41. Build fails echo 'Name: libpq' >>libpq.pc echo 'Description: PostgreSQL libpq library' >>libpq.pc echo 'URL: https://www.postgresql.org/' >>libpq.pc echo 'Version: 18devel' >>libpq.pc echo 'Requires: ' >>libpq.pc echo 'Requires.private: libssl, libcrypto' >>libpq.pc echo '

Re: Undocumented functions

Hi so 7. 9. 2024 v 20:58 odesílatel Marcos Pegoraro napsal: > Some days ago Tom Lane said ... > > SELECT events & 4 != 0 AS can_upd, events & 8 != 0 AS can_ins, events & 16 > != 0 AS can_del FROM > pg_catalog.pg_relation_is_updatable('_pessoa'::regclass, false) t(events); > > Well, I didn't find

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

ne 16. 6. 2024 v 16:11 odesílatel Pavel Stehule napsal: > Hi, > > assigned patch try to solve issue reported by Mor Lehr (Missing semicolon > in anonymous plpgsql block does not raise syntax error). > > > https://www.postgresql.org/message-id/CALyvM2bp_CXMH_Gyq87pmHJRuZ

Re: Create syscaches for pg_extension

čt 5. 9. 2024 v 15:41 odesílatel Andrei Lepikhov napsal: > On 22/8/2024 03:49, Michael Paquier wrote: > > On Mon, Aug 19, 2024 at 03:21:30PM +0900, Michael Paquier wrote: > >> I won't hide that I've wanted that in the past.. > > > > And I have bumped into a case where this has been helpful today,

Re: broken devel package for rocky linux

Hi út 3. 9. 2024 v 12:38 odesílatel Devrim Gündüz napsal: > Hi Pavel, > > On Tue, 2024-09-03 at 12:34 +0200, Pavel Stehule wrote: > > Hi > > > > I try to install devel package > > > > [student@localhost ~]$ LANG=C sudo dnf install postgresql15-devel >

broken devel package for rocky linux

Hi I try to install devel package [student@localhost ~]$ LANG=C sudo dnf install postgresql15-devel Last metadata expiration check: 0:23:04 ago on Tue Sep 3 06:08:29 2024. Error: Problem: cannot install the best candidate for the job - nothing provides perl(IPC::Run) needed by postgresql15-de

Re: [PATCH] Add CANONICAL option to xmlserialize

čt 29. 8. 2024 v 23:54 odesílatel Jim Jones napsal: > > > On 29.08.24 20:50, Pavel Stehule wrote: > > > > I know, but theoretically, there can be some benefit for CANONICAL if > > pg supports bytea there. Lot of databases still use non utf8 encoding. > > >

Re: [PATCH] Add CANONICAL option to xmlserialize

út 27. 8. 2024 v 13:57 odesílatel Jim Jones napsal: > > > On 26.08.24 16:59, Pavel Stehule wrote: > > > > 1. what about behaviour of NO INDENT - the implementation is not too > > old, so it can be changed if we want (I think), and it is better to do > > early tha

Re: proposal: schema variables

Hi út 27. 8. 2024 v 16:52 odesílatel Laurenz Albe napsal: > time""On Tue, 2024-08-27 at 08:52 +0200, Pavel Stehule wrote: > > I can throw 200KB from another 300KB patch set which can be better for > review, but it > > can be harder to maintain this patch set.

Re: proposal: schema variables

Hi út 27. 8. 2024 v 8:15 odesílatel Laurenz Albe napsal: > On Thu, 2024-08-15 at 07:55 +0200, Pavel Stehule wrote: > > út 30. 7. 2024 v 21:46 odesílatel Laurenz Albe > napsal: > > > - A general reminder: single line comments should start with a lower > case > > &g

Re: [PATCH] Add CANONICAL option to xmlserialize

po 26. 8. 2024 v 16:30 odesílatel Jim Jones napsal: > > > On 26.08.24 14:15, Pavel Stehule wrote: > > I am not strongly against enhancing XMLSERIALIZE, but it can be nice > > to see some wider concept first. Currently the state looks just random > > - and I didn&#

Re: [PATCH] Add CANONICAL option to xmlserialize

po 26. 8. 2024 v 13:28 odesílatel Jim Jones napsal: > > > On 26.08.24 12:30, Pavel Stehule wrote: > > I think so there should be specified the target of CANONICAL - it is a > > partial replacement of NO INDENT or it produces format just for > > comparing? The CANON

Re: [PATCH] Add CANONICAL option to xmlserialize

po 26. 8. 2024 v 11:32 odesílatel Jim Jones napsal: > Hi Pavel > > On 25.08.24 20:57, Pavel Stehule wrote: > > > > There is unwanted white space in the patch > > > > -<-><--><-->xmlFreeDoc(doc); > >

maybe buggy implementation of NO INDENT in xmlserialize

Hi I checked our implementation of xmlserialize, and it looks like there are few issues. 1. It doesn't conform to SQL/XML - there is some overlap with the proposed CANONICAL flag, but not full. 2. There is significantly different behaviour of NO INDENT on Oracle and other db, that implements it.

Re: [PATCH] Add CANONICAL option to xmlserialize

ne 25. 8. 2024 v 20:57 odesílatel Pavel Stehule napsal: > Hi > > so 24. 8. 2024 v 7:40 odesílatel Jim Jones > napsal: > >> >> On 19.06.24 10:59, Jim Jones wrote: >> > On 09.02.24 14:19, Jim Jones wrote: >> >> v9 attached with rebase due to chang

Re: [PATCH] Add CANONICAL option to xmlserialize

Hi so 24. 8. 2024 v 7:40 odesílatel Jim Jones napsal: > > On 19.06.24 10:59, Jim Jones wrote: > > On 09.02.24 14:19, Jim Jones wrote: > >> v9 attached with rebase due to changes done to primnodes.h in 615f5f6 > >> > > v10 attached with rebase due to changes in primnodes, parsenodes.h, and > > gr

Re: Add llvm version into the version string

st 21. 8. 2024 v 12:20 odesílatel Dmitry Dolgov <9erthali...@gmail.com> napsal: > In many jit related bug reports, one of the first questions is often > "which llvm version is used". How about adding it into the > PG_VERSION_STR, similar to the gcc version? > +1 Pave

Re: Create syscaches for pg_extension

út 13. 8. 2024 v 16:13 odesílatel Jelte Fennema-Nio napsal: > Shared libraries of extensions might want to invalidate or update their > own caches whenever a CREATE/ALTER/DROP EXTENSION command is run for > their extension (in any backend). Right now this is non-trivial to do > correctly and effi

Re: Restricting Direct Access to a C Function in PostgreSQL

ne 11. 8. 2024 v 15:34 odesílatel Ayush Vatsa napsal: > Thanks for the responses. > > > I would go with the GRANT approach. Make my_func() a > SECURITY DEFINER function, and revoke access to my_func_extended() for > all other roles. > This sounds reasonable, and can be one of the options. > > > D

Re: Restricting Direct Access to a C Function in PostgreSQL

ne 11. 8. 2024 v 14:08 odesílatel Heikki Linnakangas napsal: > On 11/08/2024 12:41, Pavel Stehule wrote: > > ne 11. 8. 2024 v 9:23 odesílatel Ayush Vatsa > <mailto:ayushvatsa1...@gmail.com>> napsal: > > > > Hi PostgreSQL Community, > > > >

Re: Restricting Direct Access to a C Function in PostgreSQL

Hi ne 11. 8. 2024 v 9:23 odesílatel Ayush Vatsa napsal: > Hi PostgreSQL Community, > > I have a scenario where I am working with two functions: one in SQL and > another in C, where the SQL function is a wrapper around C function. Here’s > an example: > > CREATE OR REPLACE FUNCTION my_func(IN inp

Re: proposal: schema variables

čt 1. 8. 2024 v 13:22 odesílatel Laurenz Albe napsal: > On Thu, 2024-08-01 at 08:12 +0200, Pavel Stehule wrote: > > fresh rebase + fix format in doc > > Thanks! > > I'm curious, but too lazy to build the patch now, so I'm asking: > what did you do about this e

Re: proposal: schema variables

y patchset > > Thanks, > > Erik Rijkers > > > > > Op 8/1/24 om 08:12 schreef Pavel Stehule: > > Hi > > > > fresh rebase + fix format in doc > > > > Regards > > > > Pavel > > >

Re: proposal: schema variables

st 31. 7. 2024 v 8:57 odesílatel Laurenz Albe napsal: > On Wed, 2024-07-31 at 08:41 +0200, Pavel Stehule wrote: > > Probably you didn't attach new files - the second patch is not complete. > Or you didn't make changes there? > > Hm. What is missing? >

Re: proposal: schema variables

út 30. 7. 2024 v 21:46 odesílatel Laurenz Albe napsal: > This is my review of the second patch in the series. > > Again, I mostly changed code comments and documentation. > > Noteworthy remarks: > > - A general reminder: single line comments should start with a lower case > letter and have to p

Re: proposal: schema variables

út 23. 7. 2024 v 23:41 odesílatel Laurenz Albe napsal: > On Tue, 2024-07-23 at 16:34 +0200, Laurenz Albe wrote: > > CREATE VARIABLE command: > > > > This is buggy: > > > > CREATE VARIABLE str AS text NOT NULL DEFAULT NULL; > > > > Ugh. > > > > SELECT str; > > ERROR: null value is

Re: Wrong security context for deferred triggers?

po 8. 7. 2024 v 14:36 odesílatel Laurenz Albe napsal: > On 7/8/24 04:14, Joseph Koshakow wrote: > > Given the above and the fact that the patch is a breaking change, my > > vote would still be to keep the current behavior and update the > > documentation. Though I'd be happy to be overruled by so

Re: Send duration output to separate log files

Hi st 10. 7. 2024 v 17:58 odesílatel Greg Sabino Mullane napsal: > Please find attached a patch to allow for durations to optionally be sent > to separate log files. In other words, rather than cluttering up our > postgres202007.log file with tons of output from > log_min_duration_statement, dur

Re: [PATCH] GROUP BY ALL

Hi st 24. 7. 2024 v 10:57 odesílatel Jelte Fennema-Nio napsal: > On Mon, 22 Jul 2024 at 22:55, David Christensen wrote: > > I see that there'd been some chatter but not a lot of discussion about > > a GROUP BY ALL feature/functionality. There certainly is utility in > > such a construct IMHO.

Re: Custom explain options

Hi po 22. 7. 2024 v 17:08 odesílatel Konstantin Knizhnik napsal: > > On 16/01/2024 5:38 pm, Tomas Vondra wrote: > > By "broken" you mean that you prefetch items only from a single leaf > > page, so immediately after reading the next one nothing is prefetched. > Correct? > > > Yes, exactly. It me

Re: proposal: schema variables

po 22. 7. 2024 v 10:23 odesílatel Laurenz Albe napsal: > Thanks for the updated patch and the fixes! > > On Mon, 2024-07-22 at 08:37 +0200, Pavel Stehule wrote: > > > > --- a/doc/src/sgml/ref/pg_restore.sgml > > > > +++ b/doc/src/sgml/ref/pg_restore.sgml >

Re: why there is not VACUUM FULL CONCURRENTLY?

Hi ne 21. 7. 2024 v 17:13 odesílatel Kirill Reshke napsal: > Hi! > I'm interested in the vacuum concurrently feature being inside the > core, so will try to review patch set and give valuable feedback. For > now, just a few little thoughts.. > > > > One more thing is about pg_squeeze background

Re: Improving PL/Tcl's error context reports

Hi čt 4. 7. 2024 v 21:42 odesílatel Tom Lane napsal: > I wrote: > > Pavel Stehule writes: > >> PLpgSQL uses more often function signature > >> (2024-07-04 19:49:20) postgres=# select bx(0); > >> ERROR: division by zero > >> CONTEXT: PL/pgSQL

Re: Improving PL/Tcl's error context reports

čt 4. 7. 2024 v 19:36 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > čt 4. 7. 2024 v 17:27 odesílatel Heikki Linnakangas > > napsal: > >> What happens if you rename a function? I guess the error context will > >> still print the old name, but that&#x

Re: Improving PL/Tcl's error context reports

Hi > Hmm, could we do something with tcl namespaces to allow having two > procedures with the same name? E.g. create a separate namespace, based > on the OID, for each procedure. I wonder how the stack trace would look > like then. > I didn't do full test, but I think so tcl uses for error messa

Re: Improving PL/Tcl's error context reports

čt 4. 7. 2024 v 17:27 odesílatel Heikki Linnakangas napsal: > On 05/06/2024 20:42, Tom Lane wrote: > > While working on commit b631d0149, I got a bee in my bonnet about > > how unfriendly PL/Tcl's error CONTEXT reports are: > > > > * The context reports expose PL/Tcl's internal names for the Tcl

Re: Extension using Meson as build system

ne 30. 6. 2024 v 15:39 odesílatel Junwang Zhao napsal: > On Sun, Jun 30, 2024 at 9:31 PM Pavel Stehule > wrote: > > > > > > > > ne 30. 6. 2024 v 15:28 odesílatel Junwang Zhao > napsal: > >> > >> On Sun, Jun 30, 2024 at 9:20 PM Pavel Stehul

Re: Extension using Meson as build system

ne 30. 6. 2024 v 15:28 odesílatel Junwang Zhao napsal: > On Sun, Jun 30, 2024 at 9:20 PM Pavel Stehule > wrote: > > > > Hi > > > > ne 30. 6. 2024 v 15:17 odesílatel Junwang Zhao > napsal: > >> > >> Hi hackers, > >> > >&

Re: Extension using Meson as build system

Hi ne 30. 6. 2024 v 15:17 odesílatel Junwang Zhao napsal: > Hi hackers, > > Is there any extension that uses meson as build systems? > I'm starting a extension project that written in c++, cmake is my > initial choice as the build system, but since PostgreSQL has adopted > Meson, so I'm wonderi

Re: cfbot update: Using GitHub for patch review

pá 21. 6. 2024 v 17:55 odesílatel Nathan Bossart napsal: > On Fri, Jun 21, 2024 at 04:36:13PM +0200, Jelte Fennema-Nio wrote: > > I recently got write access to the cfbot repo[1] and machine from > > Thomas. And I deployed a few improvements this week. The most > > significant one is that it is n

Re: ON ERROR in json_query and the like

pá 21. 6. 2024 v 6:01 odesílatel Amit Langote napsal: > On Fri, Jun 21, 2024 at 10:01 AM David G. Johnston > wrote: > > On Thu, Jun 20, 2024 at 5:22 PM Amit Langote > wrote: > >> > >> > >> Soft error handling *was* used for catching cast errors in the very > >> early versions of this patch (lon

Re: ON ERROR in json_query and the like

pá 21. 6. 2024 v 2:22 odesílatel Amit Langote napsal: > On Fri, Jun 21, 2024 at 1:11 AM David G. Johnston > wrote: > > On Thu, Jun 20, 2024 at 2:19 AM Amit Langote > wrote: > >> On Mon, Jun 17, 2024 at 10:07 PM Markus Winand > wrote: > >> > > On 17.06.2024, at 08:20, Amit Langote > wrote: > >

Re: ON ERROR in json_query and the like

po 17. 6. 2024 v 15:07 odesílatel Markus Winand napsal: > > > On 17.06.2024, at 08:20, Amit Langote wrote: > > > > Hi, > > > > (apologies for not replying to this thread sooner) > > > > On Tue, May 28, 2024 at 6:57 PM Pavel Stehule > wrote: >

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

ne 16. 6. 2024 v 19:36 odesílatel Marcos Pegoraro napsal: > Em dom., 16 de jun. de 2024 às 12:11, Pavel Stehule < > pavel.steh...@gmail.com> escreveu: > >> I don't follow this idea - when it does not make sense, then why do you >> use it? It can be a s

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

ne 16. 6. 2024 v 16:43 odesílatel Marcos Pegoraro napsal: > Em dom., 16 de jun. de 2024 às 11:37, Pavel Stehule < > pavel.steh...@gmail.com> escreveu: > >> >> What is the expected benefit? Generally PL/pgSQL has very strict syntax - >> and using double semicol

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

r; > begin > var_x = 99;; > delete from x where x = var_x; > end; $$; > ERROR: syntax error at or near ";" > LINE 1: do $$ declare var_x integer; begin var_x = 99;; delete from ... > > Atenciosamente, > > > > > Em dom., 16 de jun. de 2024 às 11:12, Pa

proposal: plpgsql, new check for extra_errors - strict_expr_check

Hi, assigned patch try to solve issue reported by Mor Lehr (Missing semicolon in anonymous plpgsql block does not raise syntax error). https://www.postgresql.org/message-id/CALyvM2bp_CXMH_Gyq87pmHJRuZDEhV40u9VP8rX=canet2w...@mail.gmail.com by introducing a new extra error check. With this check

Re: strange context message in spi.c?

Hi čt 13. 6. 2024 v 20:56 odesílatel Daniel Gustafsson napsal: > > On 13 Jun 2024, at 19:21, Pavel Stehule wrote: > > > Is the message "SQL expression ..." for RAW_PLPGSQL_EXPR correct? > > That indeed seems incorrect. > > > Should there be a "P

strange context message in spi.c?

Hi I am found strange switch: <--><-->switch (carg->mode) <--><-->{ <--><--><-->case RAW_PARSE_PLPGSQL_EXPR: <--><--><--><-->errcontext("SQL expression \"%s\"", query); <--><--><--><-->break; <--><--><-->case RAW_PARSE_PLPGSQL_ASSIGN1: <--><--><-->case RAW_PARSE_PLPGSQL_ASSIGN2: <--><--><-->case

Re: Schema variables - new implementation for Postgres 15

> 6. Oracle > > Oracle PL/SQL allows the use of package variables. PL/SQL is +/- ADA > language - and package variables are "global" variables. They are not > directly visible from SQL, but Oracle allows reduced syntax for functions > without arguments, so you need to write a wrapper > > CREATE OR

Re: Schema variables - new implementation for Postgres 15

Hi > You can see, the RDBMS allows different types of session variables, > different implementations. Usually one system allows more implementation of > session variables. There is a possibility of emulation implementation > between RDBMS, but security setting is possible only in Oracle or DB2. >

Re: Schema variables - new implementation for Postgres 15

ne 2. 6. 2024 v 23:31 odesílatel Peter Eisentraut napsal: > > On 25.05.24 12:50, Pavel Stehule wrote: > > It looks odd - It is not intuitive, it introduces new inconsistency > > inside Postgres, or with solutions in other databases. No other database > > has a similar ru

Re: [PATCH] psql: \dn+ to show size of each schema (and \dA+ for AMs)

po 3. 6. 2024 v 16:10 odesílatel Justin Pryzby napsal: > On Thu, May 30, 2024 at 10:59:06AM -0700, David Christensen wrote: > > Hi Justin, > > > > Thanks for the patch and the work on it. In reviewing the basic > > feature, I think this is something that has utility and is worthwhile > > at the

Re: Schema variables - new implementation for Postgres 15

pá 31. 5. 2024 v 15:49 odesílatel Wolfgang Walther napsal: > Pavel Stehule: > > When you write RAISE NOTICE '%', x, then PLpgSQL parser rewrite it to > > RAISE NOTICE '%', SELECT $1 > > > > There is no parser just for expressions. > > That

Re: Schema variables - new implementation for Postgres 15

> > > > >> In this case you could still write: >> >> RAISE NOTICE '% %', x, (SELECT a,b FROM y); >> >> (assuming only x is a variable here) >> > no - y was a composite variable. When you write RAISE NOTICE '%', x, then PLpgSQL parser rewrite it to RAISE NOTICE '%', SELECT $1 There is no parser ju

Re: Schema variables - new implementation for Postgres 15

pá 31. 5. 2024 v 15:29 odesílatel Wolfgang Walther napsal: > Pavel Stehule: > > The session variables can be used in queries, but should be used in > > PL/pgSQL expressions, and then the mandatory usage in FROM clause will > > do lot of problems and unreadable code like &g

Re: Schema variables - new implementation for Postgres 15

pá 31. 5. 2024 v 15:02 odesílatel Pavel Stehule napsal: > > > pá 31. 5. 2024 v 13:37 odesílatel Wolfgang Walther < > walt...@technowledgy.de> napsal: > >> Pavel Stehule: >> > But in this case you could make variables and tables share the same >&g

Re: Schema variables - new implementation for Postgres 15

pá 31. 5. 2024 v 13:37 odesílatel Wolfgang Walther napsal: > Pavel Stehule: > > But in this case you could make variables and tables share the same > > namespace, i.e. forbid creating a variable with the same name as an > > already existing table. > > >

Re: Schema variables - new implementation for Postgres 15

pá 31. 5. 2024 v 13:10 odesílatel Wolfgang Walther napsal: > Pavel Stehule: > > 2. But my main argument is, it is not really safe - it solves Peter's > > use case, but if I use a reverse example of Peter's case, I still have a > > problem. > > > > I

Re: Schema variables - new implementation for Postgres 15

pá 31. 5. 2024 v 11:46 odesílatel Dmitry Dolgov <9erthali...@gmail.com> napsal: > > On Tue, May 28, 2024 at 05:18:02PM GMT, Pavel Stehule wrote: > > > > I propose another variants. First we can introduce pseudo function VAR( > ). > > The argument should be se

Re: Schema variables - new implementation for Postgres 15

Hi so 25. 5. 2024 v 3:29 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > we can introduce special safe mode started by > > set enable_direct_variable_read to off; > > and allowing access to variables only by usage dedicated function > > (supported by par

Re: ON ERROR in json_query and the like

út 28. 5. 2024 v 11:29 odesílatel Markus Winand napsal: > Hi! > > I’ve noticed two “surprising” (to me) behaviors related to > the “ON ERROR” clause of the new JSON query functions in 17beta1. > > 1. JSON parsing errors are not subject to ON ERROR >Apparently, the functions expect JSONB so th

Re: why memoize is not used for correlated subquery

út 28. 5. 2024 v 9:48 odesílatel David Rowley napsal: > On Tue, 28 May 2024 at 19:31, Pavel Stehule > wrote: > > My question is - does memoize support subqueries? And can be enhanced to > support this exercise without LATERAL and optimization fences? > > It's onl

why memoize is not used for correlated subquery

Hi I am playing with examples for P2D2, and I found few issues related to memoize 1. I use dataset https://pgsql.cz/files/obce.sql - it is data about czech population Dictionary - "obec" -> "village", "pocet_muzu" -> "number_of_men", "pocet_zen" -> "number_of_woman", "okres" -> "district", "naze

Re: DISCARD ALL does not force re-planning of plpgsql functions/procedures

ne 26. 5. 2024 v 21:27 odesílatel Jelte Fennema-Nio napsal: > On Sun, 26 May 2024 at 19:39, Tom Lane wrote: > > Hm, should it be? That's hard-won knowledge, and I'm not sure there > > is a good reason to believe it's no longer applicable. > > I think for DISCARD ALL it would probably make sense

Re: Schema variables - new implementation for Postgres 15

so 25. 5. 2024 v 10:24 odesílatel napsal: > Pavel Stehule: > > Sure there is more possibilities, but I don't want to lost the > > possibility to write code like > > > > CREATE TEMP VARIABLE _x; > > > > LET _x = 'hello'; > &

Re: Schema variables - new implementation for Postgres 15

so 25. 5. 2024 v 3:29 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > we can introduce special safe mode started by > > set enable_direct_variable_read to off; > > and allowing access to variables only by usage dedicated function > > (supported by par

Re: Schema variables - new implementation for Postgres 15

Hi st 22. 5. 2024 v 19:25 odesílatel Tom Lane napsal: > Peter Eisentraut writes: > > On 18.05.24 13:29, Alvaro Herrera wrote: > >> I want to note that when we discussed this patch series at the dev > >> meeting in FOSDEM, a sort-of conclusion was reached that we didn't want > >> schema variable

Re: Schema variables - new implementation for Postgres 15

> > > > >> >> As far as I can see now, it's a major design flaw that could keep the >> patch from being accepted. Fortunately there are few good proposals how >> to address this, folks are genuinely trying to help. What do you think >> about trying some of them out, as an alternative approach, to c

Re: Schema variables - new implementation for Postgres 15

Hi pá 24. 5. 2024 v 13:32 odesílatel Dmitry Dolgov <9erthali...@gmail.com> napsal: > > On Wed, May 22, 2024 at 08:44:28PM +0200, Pavel Stehule wrote: > > st 22. 5. 2024 v 19:25 odesílatel Tom Lane napsal: > > > > > Peter Eisentraut writes: > > >

Re: Schema variables - new implementation for Postgres 15

Hi st 22. 5. 2024 v 16:14 odesílatel Dmitry Dolgov <9erthali...@gmail.com> napsal: > > On Wed, May 22, 2024 at 02:37:49PM +0200, Peter Eisentraut wrote: > > On 18.05.24 13:29, Alvaro Herrera wrote: > > > I want to note that when we discussed this patch series at the dev > > > meeting in FOSDEM, a

Re: Schema variables - new implementation for Postgres 15

st 22. 5. 2024 v 14:37 odesílatel Peter Eisentraut napsal: > On 18.05.24 13:29, Alvaro Herrera wrote: > > I want to note that when we discussed this patch series at the dev > > meeting in FOSDEM, a sort-of conclusion was reached that we didn't want > > schema variables at all because of the fact

Re: Schema variables - new implementation for Postgres 15

st 22. 5. 2024 v 20:21 odesílatel napsal: > Alvaro Herrera: > > Perhaps the solution to all this is to avoid having the variables be > > implicitly present in the range table of all queries. Instead, if you > > need a variable's value, then you need to add the variable to the FROM > > clause; >

Re: Schema variables - new implementation for Postgres 15

st 22. 5. 2024 v 19:25 odesílatel Tom Lane napsal: > Peter Eisentraut writes: > > On 18.05.24 13:29, Alvaro Herrera wrote: > >> I want to note that when we discussed this patch series at the dev > >> meeting in FOSDEM, a sort-of conclusion was reached that we didn't want > >> schema variables at

  1   2   3   4   5   6   7   8   9   10   >