Re: [HACKERS] Allow INSTEAD OF DELETE triggers to modify the tuple for RETURNING

On Thu, Nov 2, 2023 at 12:24 PM Shlok Kyal wrote: > I went through the CFbot and found that docs build run is giving some > error (link: https://cirrus-ci.com/task/5712582359646208): > > Just wanted to make sure you are aware of the issue. I am now. Thanks! :-) Will try to keep an eye on the

Re: [HACKERS] Allow INSTEAD OF DELETE triggers to modify the tuple for RETURNING

Hi, Thank you for the feedback. Apparently it took me six years, but I've attached the latest version of the patch which I believe addresses all issues. I'll add it to the open commitfest. .m instead_of_delete_returning_v3.patch Description: Binary data

Re: Avoid unused value (src/fe_utils/print.c)

On Thu, Jul 6, 2023 at 5:37 PM Karina Litskevich wrote: > My point is, technically right now you won't see any difference in output > if you remove the line. Because if we get to that line the need_recordsep > is already true. However, understanding why it is true is complicated. That's > why if

Re: [PATCH] Implement INSERT SET syntax

On Wed, Mar 23, 2022 at 5:33 PM Tom Lane wrote: > > Justin Pryzby writes: > > You have to either include the pre-requisite patches as 0001, and your > > patch as > > 0002 (as I'm doing now), or name your patch something other than *.diff or > > *.patch, so cfbot doesn't think it's a new version

Re: Partial index "microvacuum"

On Wed, Sep 15, 2021 at 7:25 PM Peter Geoghegan wrote: > What about v14? There were significant changes to the > microvacuum/index deletion stuff in that release: > > https://www.postgresql.org/docs/14/btree-implementation.html#BTREE-DELETION Huh. Interesting. I'm sorry, I wasn't aware of this

Partial index "microvacuum"

So I've been looking at issues we used to have in production some time ago which eventually lead us to migrating away from partial indexes in some cases. In the end, I'm surprised how easy this (or at least a similar case) was to reproduce. The attached program does some UPDATEs where around

Re: UNIQUE null treatment option

On Fri, Aug 27, 2021 at 3:38 PM Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote: > In the SQL:202x draft, this > has been formalized by making this implementation-defined and adding > an option on unique constraint definitions UNIQUE [ NULLS [NOT] > DISTINCT ] to choose a behavior

Re: security_definer_search_path GUC

On Thu, Jun 3, 2021 at 7:30 PM Mark Dilger wrote: > > On Jun 3, 2021, at 9:03 AM, Pavel Stehule > wrote: > > > > I agree so some possibility of locking search_path or possibility to > control who and when can change it can increase security. This should be a > core feature. It's maybe more

Re: security_definer_search_path GUC

On Thu, Jun 3, 2021 at 9:14 AM Joel Jacobson wrote: > On Thu, Jun 3, 2021, at 00:55, Marko Tiikkaja wrote: > > They still show up everywhere when looking at "public". So this is only > slightly better, and a maintenance burden. > > > Good point. I find this annoy

Re: security_definer_search_path GUC

On Wed, Jun 2, 2021 at 11:32 PM Joel Jacobson wrote: > On Wed, Jun 2, 2021, at 18:36, Marko Tiikkaja wrote: > > The use case is: version upgrades. I want to be able to have a > search_path of something like 'pg_catalog, compat, public'. That way we > can provide compatibility ve

Re: security_definer_search_path GUC

On Wed, Jun 2, 2021 at 10:20 PM Alvaro Herrera wrote: > On 2021-Jun-02, Marko Tiikkaja wrote: > > > The use case is: version upgrades. I want to be able to have a > search_path > > of something like 'pg_catalog, compat, public'. That way we can provide > > comp

Re: security_definer_search_path GUC

On Wed, Jun 2, 2021 at 3:46 PM Joel Jacobson wrote: > If a database object is to be accessed unqualified by all users, isn't the > 'public' schema a perfect fit for it? How will it be helpful to create > different database objects in different schemas, if also adding all such > schemas to the

Re: security_definer_search_path GUC

On Sat, May 29, 2021 at 11:06 PM Joel Jacobson wrote: > Glad you bring this problem up for discussion, something should be done to > improve the situation. > > Personally, as I really dislike search_path and consider using it an > anti-pattern. > I would rather prefer a GUC to hard-code

security_definer_search_path GUC

Hi, Since writing SECURITY DEFINER functions securely requires annoying incantations[1], wouldn't it be nice if we provided a way for the superuser to override the default search path via a GUC in postgresql.conf? That way you can set search_path if you want to override the default, but if you

Re: how to correctly cast json value to text?

On Mon, May 3, 2021 at 12:24 PM Pavel Stehule wrote: > Is it possible to do this with built functionality? > > I miss the cast function for json scalar string value to string. > #>>'{}' .m

Re: [PATCH] Implement motd for PostgreSQL

Hi Joel On Fri, Apr 2, 2021 at 11:47 PM Joel Jacobson wrote: > PostgreSQL has since long been suffering from the lack of a proper UNIX > style motd (message of the day). > First of all, thanks for your work on this! I think this is an important feature to have, but I would love to see a way

Re: INSERT ON CONFLICT and RETURNING

There's prior art on this: https://commitfest.postgresql.org/15/1241/ .m

Re: Local visibility with logical decoding

On Mon, Jul 20, 2020 at 7:36 PM Antonin Houska wrote: > Marko Tiikkaja wrote: > > > It appears that when logical decoding sends out the data from the output > > plugin, it is not guaranteed that the decoded transaction's effects are > > visible on the source serve

Local visibility with logical decoding

Hi, It appears that when logical decoding sends out the data from the output plugin, it is not guaranteed that the decoded transaction's effects are visible on the source server. Is this the way it's supposed to work? If so, would doing something like this in the output plugin be reasonable?

Re: [PATCH] Implement INSERT SET syntax

On Fri, Nov 1, 2019 at 6:31 PM Robert Haas wrote: > On Sun, Aug 18, 2019 at 11:00 AM Tom Lane wrote: > > Perhaps the way to resolve Peter's objection is to make the syntax > > more fully like UPDATE: > > > > INSERT INTO target SET c1 = x, c2 = y+z, ... FROM tables-providing-x-y-z > > > > (with

Re: [PATCH] Implement INSERT SET syntax

On Wed, Jul 17, 2019 at 7:30 AM Gareth Palmer wrote: > Attached is a patch that adds the option of using SET clause to specify > the columns and values in an INSERT statement in the same manner as that > of an UPDATE statement. > Cool! Thanks for working on this, I'd love to see the syntax in

Re: New committer: David Rowley

On Thu, May 30, 2019 at 6:39 PM Magnus Hagander wrote: For those of you that have not read the minutes from the developer meeting ahead of pgcon (can be found at https://wiki.postgresql.org/wiki/PgCon_2019_Developer_Meeting), we'd like to announce here as well that David Rowley has joined the

Re: Follow-up on INSERT INTO ... SET ...

On Tue, Jan 29, 2019 at 6:26 PM Sven Berkvens-Matthijsse < s...@postgresql.berkvens.net> wrote: > On 29/01/2019 07.20, Tom Lane wrote: > > Looking at the thread, it seems like Marko lost interest for some > > reason, and never submitted a revised patch. > > That was my conclusion too, but I

Re: Early WIP/PoC for inlining CTEs

On Sat, Jan 26, 2019 at 12:22 AM Tom Lane wrote: > Therefore, I'm reversing my previous opinion that we should not have > an explicit NOT MATERIALIZED option. I think we should add that, and > the behavior ought to be: > > * No option given: inline if there's exactly one reference. > > * With

Re: fine tune v11 release notes

I like broccoli

Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack

On Fri, Jul 20, 2018 at 2:17 AM, Jeremy Schneider wrote: > I'd like to bump this old bug that Lloyd filed for more discussion. It > seems serious enough to me that we should at least talk about it. > > Anyone with simply the login privilege and the ability to run SQL can > instantly block all

Re: Two round for Client Authentication

On Thu, Jun 14, 2018 at 7:12 AM, Yinjie Lin wrote: > Currently I am reading and testing code about Client Authentication, but I > find that there are two progresses forked if I login using psql, while only > one progress is forked if using pgAdmin. > If psql finds the server asks for a

Re: Diagonal storage model

On Sun, Apr 1, 2018 at 3:48 PM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > I want to announce new model, "diagonal storage" which combines benefits > of both approaches. > The idea is very simple: we first store column 1 of first record, then > column 2 of second record, ... and so

get_actual_variable_range vs idx_scan/idx_tup_fetch, again

(Sorry for not continuing the thread in 54418d75.2000...@joh.to , but I don't have the original email anymore.) So I'm in the same pickle again. According to pg_stat_user_indexes an index is being used all the time. However, it's only being used by mergejoinscansel() to compare these two plans:

Re: Using scalar function as set-returning: bug or feature?

On Tue, Feb 13, 2018 at 12:30 PM, Tels wrote: > I'm not sure if you mean exactly the scenario as in the attached test > case, but this works in plpgsql, too, and would be a shame to lose. > > OTOH, one could also write: > > SELECT INTO ba, bb a,b FROM foo(1); >

Re: Using scalar function as set-returning: bug or feature?

On Fri, Feb 9, 2018 at 9:58 AM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > Attached please find patch reporting error in case of empty attribute list > for SELECT INTO > This is quite short-sighted. The better way to do this is to complain if the number of expressions is

Re: [HACKERS] INSERT .. ON CONFLICT DO SELECT [FOR ..]

On Thu, Nov 30, 2017 at 6:39 AM, Peter Geoghegan wrote: > On Wed, Nov 29, 2017 at 8:34 PM, Michael Paquier > wrote: > > The patch does not currently apply. I am noticing as well that Peter > > Geoghegan has registered himself as a reviewer a couple of