Re: Psql meta-command conninfo+

On Thursday, October 3, 2024, Hunaid Sohail wrote: > > > Authenticated User: The name of the user returned by PQuser(), indicating > the user who initiated or authenticated the current database connection. > Session User: The session user's name, which is initially the same as the > authenticated

Re: Enhance create subscription reference manual

On Wednesday, October 2, 2024, Peter Smith wrote: > ` > - "subscription's failover option" > Feels like this one refers to the stored catalog value, which is neither a parameter nor an option but an attribute. Though in some cases we are using “property” as well. An in this usage option sorta

Re: Enhance create subscription reference manual

On Wednesday, October 2, 2024, Peter Smith wrote: > > > You can see how confused the current docs are because "failover" is > called by both terms even within the same paragraph! [1] > - "failover parameter specified in the subscription" > - "subscription's failover option" > > ~~~ > > What to do

Re: general purpose array_sort

On Sat, Sep 28, 2024 at 7:05 PM Junwang Zhao wrote: > On Sat, Sep 28, 2024 at 10:41 PM jian he > wrote: > > > > dir can have only two potential values, make it > > as a boolean would be more easier? > > you didn't mention information: "by default, it will sort by > > ascending order; the sort c

Re: How to send patch with so many files changes?

On Tue, Sep 24, 2024 at 5:37 PM Tony Wayne wrote: > > On Wed, Sep 25, 2024 at 6:02 AM Tony Wayne > wrote: > >> >> I am new in contributing to postgres. I have a doubt regarding if we want >> to send a patch which has an extension and also has changes in pg source >> also,what's the way to do it?

Re: How to send patch with so many files changes?

On Tue, Sep 24, 2024 at 5:32 PM Tony Wayne wrote: > > This is the 1st version of the idea,if it goes well 🤞 we can move the > changes from extension to pg. > > If you are saying you are planning to add something to the contrib directly then you should just post the patch(es) that do it. Your abi

Re: Why mention to Oracle ?

On Fri, Sep 20, 2024 at 5:37 AM Marcos Pegoraro wrote: > Why PostgreSQL DOCs needs to show or compare the Oracle way of doing > things ? > > I understand that on page Porting from Oracle PL/SQL is ok to mention > Oracle, but there are other places where it's not needed. Or, if it's ok to > mentio

Re: Add contrib/pg_logicalsnapinspect

On Monday, September 16, 2024, shveta malik wrote: > On Tue, Sep 17, 2024 at 10:18 AM shveta malik > wrote: > > > > Thanks for addressing the comments. I have not started reviewing v4 > > yet, but here are few more comments on v3: > > > > I just noticed that when we pass NULL input, both the new

Re: Add system column support to the USING clause

On Friday, September 13, 2024, David G. Johnston wrote: > > Link to PR on GitHub: https://github.com/hilltracer/postgres/pull/3 >> > > You apparently missed the note on GitHub that says we don’t work with pull > requests. Patches are to be submitted directly to the mailing

Re: Add system column support to the USING clause

On Friday, September 13, 2024, Denis Garsh wrote: > > > The patch adds support for system columns in JOIN USING clause. > Definitely not high on my list of oversights to fix. Resorting to the ON clause for the rare query that would need to do such a thing isn’t that costly. But as the patch exi

Re: Mutable foreign key constraints

On Thursday, September 12, 2024, Tom Lane wrote: > > A possible objection is that if anybody has such a setup and > hasn't noticed a problem because they never change their > timezone setting, they might not appreciate us breaking it. > So I certainly wouldn't propose back-patching this. But > m

Re: Accept invalidation messages before the query starts inside a transaction

On Wednesday, September 11, 2024, Andrei Lepikhov wrote: > > > I don't know whether to classify this as a bug. > > [1] https://www.postgresql.org/docs/16/mvcc-caveats.html > > Seems we need to add another sentence to that final paragraph. Something like: However, once an object is accessed withi

Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options

On Wednesday, September 11, 2024, Tatsuo Ishii wrote: > > test=# SELECT row_number() IGNORE NULLS OVER w FROM t1 WINDOW w AS (ORDER > BY i); > row_number > > 1 > 2 > (2 rows) > > The t1 table only contains NULL rows. By using IGNORE NULLS, I think > it's no wonde

Re: DOCS - pg_replication_slot . Fix the 'inactive_since' description

On Sun, Sep 8, 2024, 18:55 Peter Smith wrote: > Saying "The time..." is fine, but the suggestions given seem backwards to > me: > - The time this slot was inactivated > - The time when the slot became inactive. > - The time when the slot was deactivated. > > e.g. It is not like light switch. So,

Re: Role Granting Issues in PostgreSQL: Need Help

On Wednesday, September 4, 2024, Muhammad Imtiaz wrote: > > 1. Create a role with specific permissions > > CREATE ROLE rep_admin WITH LOGIN CREATEDB CREATEROLE REPLICATION; > > List of roles > Role name | Attributes >

Re: DOCS - pg_replication_slot . Fix the 'inactive_since' description

On Tuesday, September 3, 2024, Kyotaro Horiguchi wrote: > At Tue, 3 Sep 2024 10:43:14 +0530, Amit Kapila > wrote in > > On Mon, Sep 2, 2024 at 9:14 AM shveta malik > wrote: > > > > > > On Mon, Sep 2, 2024 at 5:47 AM Peter Smith > wrote: > > > > > > > > > > > > To summarize, the current de

Re: Doc: fix the note related to the GUC "synchronized_standby_slots"

On Monday, August 26, 2024, Amit Kapila wrote: > On Mon, Aug 26, 2024 at 6:38 PM Zhijie Hou (Fujitsu) > wrote: > > > > On Monday, August 26, 2024 5:37 PM Amit Kapila > wrote: > > > > > > On Mon, Aug 26, 2024 at 1:30 PM wrote: > > > > > > > > When I read the following documentation related to t

Re: Non-trivial condition is only propagated to one side of JOIN

On Sunday, August 25, 2024, Tobias Hoffmann wrote: > > 3) Problematic example: > > # EXPLAIN SELECT * FROM tbl1 JOIN tbl2 ON tbl2.site_id = tbl1.site_id > WHERE tbl1.site_id = 1 OR tbl1.site_id IS NULL; The “is null” predicate in this query is doing nothing as your next comment alludes to; you

Re: slru bank

On Thu, Aug 22, 2024 at 7:27 PM Tom Lane wrote: > "David G. Johnston" writes: > > On Thu, Aug 22, 2024 at 7:07 PM 席冲(宜穆) > wrote: > >> In SlruSelectLRUPage(), Why do we need to traverse all slots to find > that > >> a page already has a buf

Re: slru bank

On Thu, Aug 22, 2024 at 7:07 PM 席冲(宜穆) wrote: > In SlruSelectLRUPage(), Why do we need to traverse all slots to find that > a page already has a buffer assigned? Why not find it > from the [bankstart,bankend]? > > Only the bank is searched, both of the logic loops are bounded by: for (int slotn

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, Aug 20, 2024 at 10:46 AM Jacob Champion < jacob.champ...@enterprisedb.com> wrote: > On Tue, Aug 20, 2024 at 10:42 AM David G. Johnston > wrote: > > Semantic versioning guidelines are not something we are following, > especially here. > > I understand; the pro

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, Aug 20, 2024 at 10:31 AM Jacob Champion < jacob.champ...@enterprisedb.com> wrote: > If we decide we can't, then so be it -- things will > break either way -- but it's still strange to me that we'd be okay > with literally zero forward compatibility and still call that a "minor > version".

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, Aug 20, 2024 at 10:03 AM Jacob Champion < jacob.champ...@enterprisedb.com> wrote: > On Tue, Aug 20, 2024 at 7:26 AM Jelte Fennema-Nio > wrote: > > In practical terms I think that means for a minor version bump the > > format of the StartupMessage cannot be changed. Changing anything else

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, Aug 20, 2024 at 9:44 AM Robert Haas wrote: > On Tue, Aug 20, 2024 at 12:42 PM David G. Johnston > wrote: > > I'm wondering why we are indicating that minor versions of the protocol > are even a real thing. > > Because that concept is already a part of

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, Aug 20, 2024 at 9:02 AM Robert Haas wrote: > Yes. And the major * 1 + minor convention is used in other places > already, for PG versions, so it might already be familiar to some > people. > I'm wondering why we are indicating that minor versions of the protocol are even a real thing

Re: SPI_connect, SPI_connect_ext return type

On Sat, Aug 10, 2024 at 9:29 AM Tom Lane wrote: > "David G. Johnston" writes: > > On Saturday, August 10, 2024, Tom Lane wrote: > >> That would break a lot of code (much of it not under our control) to > >> little purpose; it would also fo

Re: SPI_connect, SPI_connect_ext return type

On Saturday, August 10, 2024, Tom Lane wrote: > Stepan writes: > > Hi, hackers! If you look at the code in the src/backend/executor/spi.c > file, > > you will see the SPI_connect function familiar to many there, which > > internally simply calls SPI_connect_ext. The return type is int, at the >

Re: can we mark upper/lower/textlike functions leakproof?

On Fri, Aug 2, 2024 at 6:58 AM Joe Conway wrote: > On 8/2/24 09:48, Jacob Champion wrote: > > On Thu, Aug 1, 2024 at 6:03 PM Robert Haas > wrote: > >> > >> On Thu, Aug 1, 2024 at 4:45 PM Jacob Champion > >> wrote: > >> > Would it provide enough value for effort to explicitly mark leaky > >> > p

Casts from jsonb to other types should cope with json null

On Thursday, August 1, 2024, Tom Lane wrote: > Maciek Sakrejda writes: > > Oddly, it looks like you only get a null if you use the '->>' > > operator. With '->' and a subsequent cast to text, you get the string > > "null": > > > maciek=# select (('{"a":null}'::jsonb)->'a')::text; > > text > > -

Re: Lack of possibility to specify CTAS TAM

On Wednesday, July 31, 2024, David G. Johnston wrote: > On Wednesday, July 31, 2024, Kirill Reshke wrote: >> >> >> The same storage specification feature can actually be supported for >> CTAE (like CTAS but execute) and CREATE MATERIALIZED VIEW. >> >> &g

Re: Lack of possibility to specify CTAS TAM

On Wednesday, July 31, 2024, Kirill Reshke wrote: > > > The same storage specification feature can actually be supported for > CTAE (like CTAS but execute) and CREATE MATERIALIZED VIEW. > > On a related note, the description here seems outdated. https://www.postgresql.org/docs/current/runtime-co

Re: Lack of possibility to specify CTAS TAM

On Wednesday, July 31, 2024, Kirill Reshke wrote: > I have noticed $subj while working with other unrelated patches. > The question is, why there is no CREATE TABLE AS USING > (some_access_method)? The syntax is documented… CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TAB

Re: Help Needed with Including External SQL Script in Extension Script

On Friday, July 26, 2024, Ayush Vatsa wrote: > > I wanted to modify the SQL script of an extension by creating multiple > objects within it. > My aim is to make minimal changes to the existing script. To achieve this, > I have created an > external script and am attempting to run it within the ext

Re: How to check if issue is solved?

On Thursday, July 25, 2024, Mohab Yaser wrote: > I wrote a simple script to get all issues from the pgsql-bugs list that > are reported by the form (basically getting just the issues without any > replies to them) and now while searching through these issues I can't know > directly whether it is

Re: Protocol question regarding Portal vs Cursor

On Thursday, July 25, 2024, Dave Cramer wrote: May not make a difference but… > 2024-07-25 15:55:39 FINEST org.postgresql.core.v3.QueryExecutorImpl > sendSimpleQuery FE=> SimpleQuery(query="declare C_3 CURSOR WITHOUT HOLD > FOR SELECT * FROM testsps WHERE id = 2") > You named the cursor c_3 (

Re: [PATCH] GROUP BY ALL

On Tue, Jul 23, 2024 at 9:48 AM David Christensen wrote: > > Sure, not everything that makes things easier is strictly necessary; > we could require `CAST(field AS text)` instead of `::text`, Probably should have...being standard and all. Though syntactic sugar is quite different from new beha

Re: [PATCH] GROUP BY ALL

On Mon, Jul 22, 2024 at 1:55 PM 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. > > Still need some docs; just throwing this out there and getting some

Re: documentation structure

On Fri, Jul 19, 2024 at 5:47 PM Tatsuo Ishii wrote: > >> IMO the file name should match the ID of the sect1 element with the > leading > >> "functions-" removed, naming the directory "functions". Thus when > viewing > >> the web page the corresponding sgml file is determinable. > > > > I'd go fo

Re: behavior of GROUP BY with VOLATILE expressions

On Fri, Jul 19, 2024 at 2:21 PM Paul George wrote: > Great, thanks for the links and useful past discussions! I figured I > wasn't the first to stumble across this, and it's interesting to see the > issue arise with ORDER BY [VOLATILE FUNC] as well. > > My question was not so much about changing

Re: documentation structure

On Fri, Jul 19, 2024 at 1:01 PM Tatsuo Ishii wrote: > > Do we want to use a "func-" prefix on the file names? I could > > imagine dispensing with that as unnecessary; > > If we don't use the prefix and we generate new file names from sect1 > tag, we could have file name collision: for example, j

Re: behavior of GROUP BY with VOLATILE expressions

On Fri, Jul 19, 2024 at 7:20 AM Paul George wrote: > > I wanted to surface a discussion in [1] regarding the expected behavior of > GROUP BY with VOLATILE expressions. There seems to be a discrepancy between > how volatile functions (RANDOM(), also confirmed with TIMEOFDAY()) and > subqueries are

How can udf c function return table, not the rows?

On Thursday, July 18, 2024, Wen Yi wrote: > > > pg_get_functiondef > -- > > In my expectations, it should be: > > oid | pg_get_functiondef > > --+--

Re: documentation structure

On Thu, Jul 18, 2024 at 8:06 PM Tatsuo Ishii wrote: > > I'm opposed to having a separate file for every function. I think > > breaking up func.sgml into one piece per sect1 is about right. If that > > proves cumbersome still we can look at breaking it up further, but > > let's start with that. >

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Tue, Jul 16, 2024 at 1:16 PM Tom Lane wrote: > Joe Conway writes: > > So you are proposing we add STATIC to VOLATILE/STABLE/IMMUTABLE (in the > > third position before IMMUTABLE), give it IMMUTABLE semantics, mark > > builtin functions that deserve it, and document with suitable caution > > s

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Tue, Jul 16, 2024 at 11:57 AM Joe Conway wrote: > > > There are two alternative philosophies: > > > > A. By choosing to use a Unicode-based function, the user has opted in > > to the Unicode stability guarantees[2], and it's fine to update Unicode > > occasionally in new major versions as long

Re: Things I don't like about \du's "Attributes" column

On Tue, Jul 16, 2024 at 8:00 AM Robert Haas wrote: > I'm starting to have some doubts about whether this effort is really > worthwhile. It seems like what we have right now is a patch which uses > both more horizontal space and more vertical space than the current > implementation, without (IMHO)

Re: Duplicate unique key values in inheritance tables

On Monday, July 15, 2024, David Rowley wrote: > On Tue, 16 Jul 2024 at 12:45, Richard Guo wrote: > > As a workaround for this issue, I'm considering whether we can skip > > checking functional dependency on primary keys for inheritance > > parents, given that we cannot guarantee uniqueness on th

Re: Can't find bugs to work on

On Fri, Jul 12, 2024 at 8:44 AM Tom Lane wrote: > > As this example shows, it's now standard for PG commit log messages > to include a link to the relevant email thread, so all you need > is the message-ID of the first message in the thread to search > the commit log with. > > Cross-posting my co

Re: Is it possible to create a cursor with hold using extended query protocol

On Wed, Jul 10, 2024 at 8:29 AM Dave Cramer wrote: > > On Wed, 10 Jul 2024 at 11:04, David G. Johnston < > david.g.johns...@gmail.com> wrote: > >> On Wednesday, July 10, 2024, Dave Cramer wrote: >> >>> Greetings, >>> >>> There are su

Re: Is it possible to create a cursor with hold using extended query protocol

On Wednesday, July 10, 2024, Dave Cramer wrote: > Greetings, > > There are suggestions that you can use extended query to fetch from a > cursor, however I don't see how you can bind values to the cursor ? > > PostgreSQL: Documentation: 16: FETCH >

Re: array_in sub function ReadArrayDimensions error message

allowed %d”, ndim, (int) MaxArraySize But while that message fits the code aren’t we supposed to be checking, after processing all dimensions, whether the combined number of cells is greater than MaxArraySize? Obviously if any one dimension is the whole thing will be, so this specific check and er

Re: array_in sub function ReadArrayDimensions error message

On Tue, Jul 9, 2024 at 8:59 AM Tom Lane wrote: > "David G. Johnston" writes: > > > I'd add a hint if the first symbol is [ and we fail to get to the point > of > > actually seeing the equal sign or the first subsequent unquoted symbol > is a > > com

Re: array_in sub function ReadArrayDimensions error message

On Tue, Jul 9, 2024 at 8:31 AM Tom Lane wrote: > > Here again, the problem is not a missing "=", it's invalid > syntax somewhere before that. > > Another thing we could consider doing here (and similarly > for your original case) is > > DETAIL: Expected "=" not "," after array dimensions. > > Th

Re: ❓ JSON Path Dot Precedence

On Mon, Jul 8, 2024 at 9:12 AM David E. Wheeler wrote: > On Jul 8, 2024, at 12:05, David G. Johnston > wrote: > > > Does the standard even have a separate type here or is that our > implementation detail invention? > > Sorry, separate type for what? > > We creat

Re: ❓ JSON Path Dot Precedence

On Mon, Jul 8, 2024 at 8:27 AM David E. Wheeler wrote: > Hi, following up on some old threads. > > > On Apr 10, 2024, at 16:44, David E. Wheeler > wrote: > > > > That makes sense, thanks. It’s just a little odd to me that the > resulting path isn’t a query at all. To Erik’s point: what path can

Re: Should we document how column DEFAULT expressions work?

On Fri, Jul 5, 2024 at 2:11 PM Bruce Momjian wrote: > > If I remove the 'now()' mention in the docs, patch attached, I am > concerned people will be confused whether it is the removal of the > single quotes or the use of "()" which causes insert-time evaluation, > and they might try 'now()'. > >

Re: Should we document how column DEFAULT expressions work?

On Fri, Jul 5, 2024 at 1:55 PM Bruce Momjian wrote: > On Fri, Jul 5, 2024 at 04:50:32PM -0400, Tom Lane wrote: > > Bruce Momjian writes: > > > Also interestingly, "now" without quotes requires parentheses to make > it > > > a function call: > > > > I'm not sure why you find that surprising, or

Re: Unknown annotation '-cim' in source code

On Wed, Jul 3, 2024 at 8:46 PM Steve Lau wrote: > > While reading the source code, I noticed comments like "-cim 9/10/89". I > think this might be an annotation by a developer to indicate the commit > time, but from the commit history (using git), they does not seem to match. > It's the initials

Re: Should we document how column DEFAULT expressions work?

On Sun, Jun 30, 2024 at 7:52 PM David Rowley wrote: > If that's the case, maybe a tiny step towards what Peter proposed is > just to make trailing punctuation fail for timestamp special values in > v18. > > I'm game. If anyone is using the ambiguous spelling it is probably to their benefit to hav

Re: Should we document how column DEFAULT expressions work?

On Sun, Jun 30, 2024 at 7:52 PM David Rowley wrote: > On Mon, 1 Jul 2024 at 13:41, David G. Johnston > wrote: > > I presume the relatively new atomic SQL functions pose a similar hazard. > > Do you have an example of this? > > create function testnow() returns timesta

Re: Should we document how column DEFAULT expressions work?

On Sun, Jun 30, 2024 at 5:47 PM David Rowley wrote: > On Mon, 1 Jul 2024 at 12:16, David G. Johnston > wrote: > > > > On Sun, Jun 30, 2024 at 4:55 PM David Rowley > wrote: > >> > >> > >> I'd like to know what led someone down the path of do

Re: Should we document how column DEFAULT expressions work?

On Sun, Jun 30, 2024 at 4:55 PM David Rowley wrote: > > I'd like to know what led someone down the path of doing something > like DEFAULT 'now()'::timestamp in a CREATE TABLE. Could it be a > faulty migration tool that created these and people copy them thinking > it's a legitimate syntax? > > My

Doc: Move standalone backup section, mention -X argument

A documentation comment came in [1] causing me to review some of our backup documentation and I left the current content and location of the standalone backups was odd. I propose to move it to a better place, under file system backups. Adding to commitfest. David J. [1] https://www.postgresql.o

Re: SQL/JSON query functions context_item doc entry and type requirement

On Thursday, June 20, 2024, David G. Johnston wrote: > >> > >> > > As for table 9.16.3 - it is unwieldy already. Lets try and make the >> core syntax shorter, not longer. We already have precedence in the >> subsequent json_table section - give each major

Re: Is missing LOGIN Event on Trigger Firing Matrix ?

On Thu, Jun 27, 2024 at 12:39 PM Andrew Dunstan wrote: > On 2024-06-27 Th 2:40 PM, Marcos Pegoraro wrote: > > create event trigger ... on login is now available but it is not shown on > DOCs or is it in another page ? > > https://www.postgresql.org/docs/devel/event-trigger-matrix.html > doesn't h

Re: Custom type's modifiers

On Thu, Jun 27, 2024 at 8:49 AM Marthin Laubscher wrote: > > I suppose when a cast is involved it goes via the external format as well, > right? > A cast between two types is going to accept a concrete instance of the input type, in memory, as its argument and then produces a concrete instance o

Re: Should we document how column DEFAULT expressions work?

On Tuesday, June 25, 2024, James Coleman wrote: > Hello, > > It's possible I'm the only one who's been in this situation, but I've > multiple times found myself explaining to a user how column DEFAULT > expressions work: namely how the quoting on an expression following > the keyword DEFAULT cont

Re: [PATCH] Add ACL (Access Control List) acronym

On Wed, Jun 26, 2024 at 8:47 AM Nathan Bossart wrote: > On Wed, Jun 26, 2024 at 07:58:55AM -0700, David G. Johnston wrote: > > On Wed, Jun 26, 2024 at 7:52 AM Joel Jacobson wrote: > >> Want me to fix that or will the committer handle that? > >> > >>

Re: [PATCH] Add ACL (Access Control List) acronym

On Wed, Jun 26, 2024 at 7:52 AM Joel Jacobson wrote: > On Wed, Jun 26, 2024, at 02:59, David G. Johnston wrote: > > Though there was no comment on the fact we should be linking to: > > > > https://en.wikipedia.org/wiki/Access-control_list > > > > not: >

Re: Wrong security context for deferred triggers?

On Wed, Jun 26, 2024 at 2:02 AM Laurenz Albe wrote: > > I think that we should have some consensus about the following before > we discuss syntax: > > - Does anybody depend on the current behavior and would be hurt if > my current patch went in as it is? > > - Is this worth changing at all or h

Re: Should we document how column DEFAULT expressions work?

On Tue, Jun 25, 2024 at 10:12 PM Tom Lane wrote: > David Rowley writes: > > If people don't properly understand these special timestamp input > > values, then maybe the documentation in [1] needs to be improved. At > > the moment the details are within parentheses. Namely "(In particular, > > n

Re: Should we document how column DEFAULT expressions work?

On Tue, Jun 25, 2024 at 9:50 PM David Rowley wrote: > On Wed, 26 Jun 2024 at 13:31, David G. Johnston > wrote: > > I'd suggest adding to: > > > > DEFAULT default_expr > > The DEFAULT clause assigns a default data value for the column whose > column definiti

Re: Should we document how column DEFAULT expressions work?

On Tue, Jun 25, 2024 at 4:11 PM Tom Lane wrote: > James Coleman writes: > > On Tue, Jun 25, 2024 at 4:59 PM Tom Lane wrote: > >> Uh ... what? I recall something about that with respect to certain > >> features such as nextval(), but you're making it sound like there > >> is something generic g

Re: [PATCH] Add ACL (Access Control List) acronym

On Mon, Jun 24, 2024 at 10:11 PM Michael Paquier wrote: > On Tue, Jun 25, 2024 at 12:20:20AM +0200, Joel Jacobson wrote: > > Thanks, much better. New version attached. > > + The PostgreSQL documentation, and code, > refers > + to the specifications within the ACL as "privileges". This

Re: [PATCH] Add ACL (Access Control List) acronym

On Tue, Jun 25, 2024 at 5:30 PM Michael Paquier wrote: > On Tue, Jun 25, 2024 at 11:55:03AM -0500, Nathan Bossart wrote: > > On Tue, Jun 25, 2024 at 08:10:24AM +0200, Joel Jacobson wrote: > > > On Tue, Jun 25, 2024, at 07:11, Michael Paquier wrote: > > >> v1 is fine without the "privileges list"

Re: psql (PostgreSQL) 17beta2 (Debian 17~beta2-1.pgdg+~20240625.1534.g23c5a0e) Failed to retrieve data from the server..

On Tue, Jun 25, 2024 at 5:36 PM André Verwijs wrote: > psql (PostgreSQL) 17beta2 (Debian 17~beta2-1.pgdg+~20240625.1534.g23c5a0e) > column "daticulocale" does not exist > LINE 5: datconnlimit, daticulocale, daticurules, datcollversion, > ^ > HINT: Perhaps you meant to reference the column "db.d

Re: improve predefined roles documentation

On Tue, Jun 25, 2024 at 1:19 PM Nathan Bossart wrote: > On Tue, Jun 25, 2024 at 04:04:03PM -0400, Robert Haas wrote: > > Looking at this again, how happy are you with the way you've got > > several roles per instead of one for each? I realize > > that was probably part of the intent of the chang

Doc Rework: Section 9.16.13 SQL/JSON Query Functions

Hey! Lots of SQL/JSON threads going about. This one is less about technical correctness and more about usability of the documentation. Though in writing this I am finding some things that aren't quite clear. I'm going to come back with those on a follow-on post once I get a chance to make my se

Re: improve predefined roles documentation

On Mon, Jun 24, 2024 at 2:53 PM Nathan Bossart wrote: > On Mon, Jun 24, 2024 at 02:44:33PM -0400, Robert Haas wrote: > > > I don't know what to do about pg_database_owner. I almost wonder if > > that should be moved out of the table and documented as a special > > case. Or maybe some more wordsmi

Re: [PATCH] Add ACL (Access Control List) acronym

On Mon, Jun 24, 2024 at 1:49 PM Joel Jacobson wrote: > How about? > > + > + The linked page uses "permissions" while we consistently use the > synonym > + "privileges", to describe the contents of the list. For avoidance of > + doubt and clarity, these two terms are equivalent

Re: [PATCH] Add ACL (Access Control List) acronym

On Mon, Jun 24, 2024 at 12:46 PM Joel Jacobson wrote: > On Mon, Jun 24, 2024, at 18:02, David G. Johnston wrote: > > > The page we link to uses "permissions" while we consistently use > > "privileges" to describe the contents of the list. This seems like an

Re: [PATCH] Add ACL (Access Control List) acronym

On Mon, Jun 24, 2024 at 8:44 AM Nathan Bossart wrote: > On Mon, Jun 24, 2024 at 02:32:27PM +0200, Joel Jacobson wrote: > > This patch is based on a suggestion from a separate thread [1]: > > > > On Mon, Jun 24, 2024, at 01:46, Michael Paquier wrote: > >> Rather unrelated to this patch, still this

Re: Proposal: Division operator for (interval / interval => double precision)

On Sun, Jun 23, 2024 at 5:57 PM Gurjeet Singh wrote: > Is there a desire to have a division operator / that takes dividend > and divisor of types interval, and results in a quotient of type > double precision. [...] > ('365 days'::interval / '3 days'::interval) => 121 > ('365 days'::interval % '

Re: Unable parse a comment in gram.y

On Saturday, June 22, 2024, Tatsuo Ishii wrote: > >>> * As func_expr but does not accept WINDOW functions directly (they > >>> * can still be contained in arguments for functions etc.) > > > >> The "but" is required, add a comma before it. It could also be written > a > >> bit more verbosely: >

Re: Unable parse a comment in gram.y

On Sat, Jun 22, 2024 at 9:02 PM Tatsuo Ishii wrote: > I was unable to parse a comment in src/backend/parser/gram.y around line > 11364: > > /* > * As func_expr but does not accept WINDOW functions directly (they > * can still be contained in arguments for functions etc.) > * Use this when wind

Re: Wrong security context for deferred triggers?

On Sat, Jun 22, 2024 at 7:21 PM Joseph Koshakow wrote: > On Sat, Jun 22, 2024 at 6:23 PM David G. Johnston < > david.g.johns...@gmail.com> wrote: > > > except invoker and triggerer are the same entity > > Maybe "executor" would have been a better term than

Re: Wrong security context for deferred triggers?

On Sat, Jun 8, 2024 at 2:37 PM Joseph Koshakow wrote: > > Something like > `SECURITY INVOKER | SECURITY TRIGGERER` (modeled after the modifiers in > `CREATE FUNCTION`) that control which role is used. > I'm inclined toward this option (except invoker and triggerer are the same entity, we need ow

Re: ON ERROR in json_query and the like

On Thursday, June 20, 2024, Markus Winand wrote: > > > > On 21.06.2024, at 06:46, David G. Johnston > wrote: > >> > > > > > 2 also has the benefit of being standard conforming while 1 does not. > > Why do you think so? Do you have any references or i

Re: ON ERROR in json_query and the like

On Thursday, June 20, 2024, Pavel Stehule wrote: > > > 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: >> >> > > By the standard, it is implementation-defined whether JSON pa

Re: minor doc issue in 9.16.2.1.1. Boolean Predicate Check Expressions

On Thu, Jun 20, 2024 at 7:30 PM jian he wrote: > "predicate check expressions return the single three-valued result of > the predicate: true, false, or unknown." > "unknown" is wrong, because `select 'unknown'::jsonb;` will fail. > here "unknown" should be "null"? see jsonb_path_query doc entry a

Re: improve predefined roles documentation

On Tue, Jun 18, 2024 at 9:52 AM Nathan Bossart wrote: > On Mon, Jun 17, 2024 at 02:10:22PM -0400, Robert Haas wrote: > > On Thu, Jun 13, 2024 at 3:48 PM Nathan Bossart > wrote: > >> I think we could improve matters by abandoning the table and instead > >> documenting these roles more like we doc

Re: ON ERROR in json_query and the like

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 (long before I got involved and the > infrastructure you mention got added). It was taken out after Pavel > said [1] that he didn't like prod

Re: SQL/JSON query functions context_item doc entry and type requirement

On Thu, Jun 20, 2024 at 9:01 AM jian he wrote: > On Thu, Jun 20, 2024 at 5:46 PM Amit Langote > wrote: > > > > On Thu, Jun 20, 2024 at 1:03 AM David G. Johnston > > wrote: > > > On Wed, Jun 19, 2024 at 8:29 AM jian he > wrote: > > >> >

Re: ON ERROR in json_query and the like

On Thu, Jun 20, 2024 at 2:19 AM Amit Langote wrote: > Hi, > > On Mon, Jun 17, 2024 at 10:07 PM Markus Winand > wrote: > > > On 17.06.2024, at 08:20, Amit Langote wrote: > > > Agree that the documentation needs to be clear about this. I'll update > > > my patch at [1] to add a note next to table

Re: SQL/JSON query functions context_item doc entry and type requirement

On Wed, Jun 19, 2024 at 8:29 AM jian he wrote: > On Mon, Jun 17, 2024 at 9:05 PM Chapman Flack wrote: > > > > Hi, > > > > On 06/17/24 02:43, Amit Langote wrote: > > > context_item expression can be a value of > > > any type that can be cast to jsonb. This includes types > > > such as char, text

Re: Extension security improvement: Add support for extensions with an owned schema

On Wed, Jun 19, 2024 at 8:19 AM Jelte Fennema-Nio wrote: > Because part of it would > only be relevant once we support upgrading from PG18. So for now the > upgrade_code I haven't actually run. > Does it apply against v16? If so, branch off there, apply it, then upgrade from the v16 branch to

Re: Document NULL

On Tuesday, June 18, 2024, Tom Lane wrote: > Yugo NAGATA writes: > > On Tue, 18 Jun 2024 20:56:58 -0700 > > "David G. Johnston" wrote: > >> But it is neither a keyword nor an identifier. > > The lexer would be quite surprised by your claim that NULL is

Re: Document NULL

On Tue, Jun 18, 2024 at 8:34 PM Yugo NAGATA wrote: > > It may be a trivial thing but I am not sure we need to mention case > insensitivity > here, because all keywords and unquoted identifiers are case-insensitive in > PostgreSQL and it is not specific to NULL. > But it is neither a keyword nor

Re: Document NULL

On Sat, May 11, 2024 at 11:00 AM David G. Johnston < david.g.johns...@gmail.com> wrote: > Though I haven’t settled on a phrasing I really like. But I’m trying to > avoid a parenthetical. > > Settled on this: The cardinal rule, a null value is neither equal nor unequ

Re: create role manual

On Sat, Jun 15, 2024 at 7:25 PM Tatsuo Ishii wrote: >The rules for which initial >role membership options are enabled described below in the >IN ROLE, ROLE, and >ADMIN clauses. > > Maybe we need "are" in front of "described"? > > Agreed. David J.

  1   2   3   4   5   6   7   8   9   10   >