Re: request for database identifier in the startup packet

2024-05-09 Thread David G. Johnston
On Thursday, May 9, 2024, Dave Cramer wrote: > Greetings, > > The JDBC driver is currently keeping a per connection cache of types in > the driver. We are seeing cases where the number of columns is quite high. > In one case Prevent fetchFieldMetaData() from being run when unnecessary. > · Issue

Is there an undocumented Syntax Check in Meson?

2024-05-09 Thread David G. Johnston
$subject Make has one: https://www.postgresql.org/docs/current/docguide-build.html#DOCGUIDE-BUILD-SYNTAX-CHECK This needs updating: https://www.postgresql.org/docs/current/docguide-build-meson.html I've been using "ninja html" which isn't shown here. Also, as a sanity check, running that

Re: Is there an undocumented Syntax Check in Meson?

2024-05-09 Thread David G. Johnston
On Thu, May 9, 2024 at 1:16 PM Andres Freund wrote: > Hi, > > On 2024-05-09 09:23:37 -0700, David G. Johnston wrote: > > This needs updating: > > https://www.postgresql.org/docs/current/docguide-build-meson.html > > You mean it should have a syntax target? Or that some

Re: Is there an undocumented Syntax Check in Meson?

2024-05-09 Thread David G. Johnston
On Thu, May 9, 2024 at 12:12 PM Dagfinn Ilmari Mannsåker wrote: > "David G. Johnston" writes: > > > I've been using "ninja html" which isn't shown here. > > The /devel/ version has a link to the full list of doc targets: > > > https://www.postg

Re: Document NULL

2024-05-03 Thread David G. Johnston
On Fri, May 3, 2024 at 1:14 AM jian he wrote: > On Fri, May 3, 2024 at 2:47 PM Laurenz Albe > wrote: > > > > On Thu, 2024-05-02 at 08:23 -0700, David G. Johnston wrote: > > > Version 2 attached. Still a draft, focused on topic picking and > overall structu

Re: Document NULL

2024-05-03 Thread David G. Johnston
On Fri, May 3, 2024 at 8:44 AM Tom Lane wrote: > "David G. Johnston" writes: > > On Fri, May 3, 2024 at 7:10 AM Peter Eisentraut > > wrote: > >> On 02.05.24 17:23, David G. Johnston wrote: > >>> I chose to add a new sect1 in the user g

Re: Document NULL

2024-05-03 Thread David G. Johnston
On Fri, May 3, 2024 at 7:10 AM Peter Eisentraut wrote: > On 02.05.24 17:23, David G. Johnston wrote: > > Version 2 attached. Still a draft, focused on topic picking and overall > > structure. Examples and links planned plus the usual semantic markup > stuff. > > > &

Document NULL

2024-05-01 Thread David G. Johnston
in its own file. David J. [1] https://www.postgresql.org/message-id/1859814.1714532025%40sss.pgh.pa.us From a068247e92e620455a925a0ae746adc225ae1339 Mon Sep 17 00:00:00 2001 From: "David G. Johnston" Date: Wed, 1 May 2024 07:45:48 -0700 Subject: [PATCH] Document NULL --- doc/src/sgm

Re: EXPLAN redundant options

2024-05-02 Thread David G. Johnston
On Thu, May 2, 2024 at 6:17 AM jian he wrote: > explain (verbose, verbose off, analyze on, analyze off, analyze on) > > I would just update this paragraph to note the last one wins behavior. "When the option list is surrounded by parentheses, the options can be written in any order. However,

Re: Document NULL

2024-05-02 Thread David G. Johnston
One easily made because we assume if you are here you "know" what data is, but there is still stuff to be discussed, if nothing else to establish a common understanding between us and our users. David J. From 7798121992154edab4768d7eab5a89be04730b2f Mon Sep 17 00:00:00 2001 From: &qu

Re: Proposal for CREATE OR REPLACE EVENT TRIGGER in PostgreSQL

2024-05-03 Thread David G. Johnston
On Friday, May 3, 2024, Peter Burbery wrote: > Dear pgsql-hackers, > > One-line Summary: > Proposal to introduce the CREATE OR REPLACE syntax for EVENT TRIGGER in > PostgreSQL. > > Business Use-case: > Currently, to modify an EVENT TRIGGER, one must drop and recreate it. This > proposal aims to

Re: Document NULL

2024-05-11 Thread David G. Johnston
On Saturday, May 11, 2024, Thom Brown wrote: > > Sat, May 11, 2024, 16:34 David G. Johnston > wrote: > > My plan is to have a v4 out next week, without or without a review of this >> draft, but then the subsequent few weeks will probably be a bit quiet. >> > &g

Re: Document NULL

2024-05-11 Thread David G. Johnston
On Fri, May 3, 2024 at 9:00 AM David G. Johnston wrote: > On Fri, May 3, 2024 at 8:44 AM Tom Lane wrote: > >> Having said that, I reiterate my proposal that we make it a new >> > under DDL, before 5.2 Default Values which is the first >> place in ddl.sgml that assu

Re: PERIOD foreign key feature

2024-05-07 Thread David G. Johnston
On Tue, May 7, 2024 at 7:54 AM Bruce Momjian wrote: > In this commit: > > commit 34768ee3616 > Author: Peter Eisentraut > Date: Sun Mar 24 07:37:13 2024 +0100 > > Add temporal FOREIGN KEY contraints > > Add PERIOD clause to foreign key

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

2024-05-14 Thread David G. Johnston
On Tue, May 14, 2024 at 9:03 AM Robert Haas wrote: > On Tue, Apr 16, 2024 at 3:06 AM Pavel Luzanov > wrote: > > As for the Login column and its values. > > I'm not sure about using "Can" instead of "yes" to represent true. > > In other psql commands, boolean values are always shown as yes/no. >

Re: Postgres and --config-file option

2024-05-15 Thread David G. Johnston
On Wed, May 15, 2024 at 2:49 AM Peter Eisentraut wrote: > On 15.05.24 04:07, Michael Paquier wrote: > > Not sure that these additions in --help or the docs are necessary. > > The rest looks OK. > > > > -"You must specify the --config-file or -D invocation " > > +"You must specify the

Re: add function argument names to regex* functions.

2024-05-15 Thread David G. Johnston
On Wed, May 15, 2024 at 12:07 PM Robert Haas wrote: > On Wed, May 15, 2024 at 3:01 PM David G. Johnston > wrote: > > I think this confusion goes to show that replacing N with count doesn't > work. > > > > "replace_at" comes to mind as a better name. > >

Re: [PATCH] Add --syntax to postgres for SQL syntax checking

2024-05-15 Thread David G. Johnston
On Wed, May 15, 2024 at 12:18 PM wrote: > Tom Lane: > >> This is really what is missing for the ecosystem. A libpqparser for > >> tools to use: Formatters, linters, query rewriters, simple syntax > >> checkers... they are all missing access to postgres' own parser. > > > > To get to that, you'd

Re: add function argument names to regex* functions.

2024-05-15 Thread David G. Johnston
On Wed, May 15, 2024 at 1:19 PM Robert Haas wrote: > > So my point was: to me, N is more self-documenting than replace_at, > and less self-documenting than count or occurrence. > > If your mileage varies on that point, so be it! > > Maybe just "match" instead of "replace_match". Reading this it

Re: [PATCH] Add --syntax to postgres for SQL syntax checking

2024-05-15 Thread David G. Johnston
On Wed, May 15, 2024 at 12:35 PM Josef Šimánek wrote: > st 15. 5. 2024 v 21:33 odesílatel David G. Johnston > napsal: > > > Now, in my ideal world something like this could be made as an extension > so that it can work on older versions and not have to be maintained by > c

Re: add function argument names to regex* functions.

2024-05-15 Thread David G. Johnston
On Wed, May 15, 2024 at 12:52 PM Robert Haas wrote: > On Wed, May 15, 2024 at 3:25 PM David G. Johnston > wrote: > > The function replaces matches, not random characters. And if you are > reading the documentation I find it implausible that the wording I > suggested would

Re: add function argument names to regex* functions.

2024-05-15 Thread David G. Johnston
On Wed, May 15, 2024 at 12:07 PM Robert Haas wrote: > On Wed, May 15, 2024 at 3:01 PM David G. Johnston > wrote: > > I think this confusion goes to show that replacing N with count doesn't > work. > > > > "replace_at" comes to mind as a better name. > I

Re: add function argument names to regex* functions.

2024-05-15 Thread David G. Johnston
On Wed, May 15, 2024 at 11:46 AM Robert Haas wrote: > On Thu, Apr 4, 2024 at 9:55 AM jian he > wrote: > > in the regexp_replace explanation section. > > changing "N" to lower-case would be misleading for regexp_replace? > > so I choose "count". > > I don't see why that would be confusing for

Re: [PATCH] Add --syntax to postgres for SQL syntax checking

2024-05-15 Thread David G. Johnston
On Wed, May 15, 2024 at 1:00 PM Robert Haas wrote: > On Wed, May 15, 2024 at 3:28 PM Tom Lane wrote: > > Sorry: "make sense" was a poorly chosen phrase there. What I was > > doubting, and continue to doubt, is that 100% checking of what > > you can check without catalog access and 0% checking

Re: [PATCH] Add --syntax to postgres for SQL syntax checking

2024-05-15 Thread David G. Johnston
On Wed, May 15, 2024 at 6:35 PM David G. Johnston < david.g.johns...@gmail.com> wrote: > > If in core I would still want to expose this as say a contrib module > binary instead of hacking it into postgres. It would be our first server > program entry there. > > Sorry fo

Re: First draft of PG 17 release notes

2024-05-15 Thread David G. Johnston
On Wednesday, May 15, 2024, jian he wrote: > On Thu, May 9, 2024 at 12:04 PM Bruce Momjian wrote: > > > > I have committed the first draft of the PG 17 release notes; you can > > see the results here: > > > > https://momjian.us/pgsql_docs/release-17.html > > > > in section: E.1.2.

Re: commitfest.postgresql.org is no longer fit for purpose

2024-05-16 Thread David G. Johnston
On Thu, May 16, 2024 at 1:46 PM Melanie Plageman wrote: > > I should probably simply > withdraw and re-register them. My justification was that I'll lose > them if I don't keep them in the commitfest app. But, I could just, > you know, save them somewhere myself instead of polluting the >

Re: CREATE TABLE creates a composite type corresponding to the table row, which is and is not there

2024-05-16 Thread David G. Johnston
On Wed, May 15, 2024 at 8:46 AM Robert Haas wrote: > On Thu, Apr 4, 2024 at 12:41 AM Erik Wienhold wrote: > > Thanks, fixed in v4. Looks like American English prefers that comma and > > it's also more common in our docs. > > Reviewing this patch: > > - Creates a typed table, which takes

Re: commitfest.postgresql.org is no longer fit for purpose

2024-05-16 Thread David G. Johnston
On Thu, May 16, 2024 at 11:30 AM Robert Haas wrote: > Hi, > > The original intent of CommitFests, and of commitfest.postgresql.org > by extension, was to provide a place where patches could be registered > to indicate that they needed to be reviewed, thus enabling patch > authors and patch

Re: Postgres and --config-file option

2024-05-16 Thread David G. Johnston
On Thu, May 16, 2024 at 4:11 PM Michael Paquier wrote: > On Thu, May 16, 2024 at 11:57:10AM +0300, Aleksander Alekseev wrote: > > I propose my original v1 patch for correcting the --help output of > > 'postgres' too. I agree with the above comments that corresponding > > changes in v4 became

Re: confusing `case when` column name

2024-03-12 Thread David G. Johnston
On Tuesday, March 12, 2024, adjk...@126.com wrote: > > Nee we change the title of the case-when output column? > > Choosing either a or b as the label seems wrong and probably worth changing to something that has no meaning and encourages the application of a column alias. David J.

Re: REVOKE FROM warning on grantor

2024-03-14 Thread David G. Johnston
On Thursday, March 14, 2024, Étienne BERSAC wrote: > > However, I'd prefer if Postgres fails properly. Because the GRANT is > actually not revoked. This prevent ldap2pg to report an issue in > handling privileges on such roles. > > What do you think of make this warning an error ? > > The choice

Re: documentation structure

2024-03-21 Thread David G. Johnston
On Wed, Mar 20, 2024 at 9:43 AM Robert Haas wrote: > On Tue, Mar 19, 2024 at 5:39 PM Andrew Dunstan > wrote: > > +many for improving the index. > > Here's a series of four patches. I reviewed the most recent set of 5 patches. > Taken together, they cut down the > number of numbered chapters

Re: documentation structure

2024-03-21 Thread David G. Johnston
On Thu, Mar 21, 2024 at 11:30 AM Robert Haas wrote: > > My second thought is that the stuff from "VII. Internals" that I > categorized as reference material should move into section "VI. > Reference". I think we should also consider moving appendix F, > "Additional Supplied Modules and

Re: REVOKE FROM warning on grantor

2024-03-16 Thread David G. Johnston
On Sat, Mar 16, 2024 at 1:00 PM Étienne BERSAC wrote: > > > The choice of warning is made because after the command ends the > > grantmin question does not exist. The revoke was a no-op and the > > final state is as the user intended. > > > Sorry, can you explain me what's the grantmin question

Re: documentation structure

2024-03-22 Thread David G. Johnston
On Fri, Mar 22, 2024 at 7:10 AM Robert Haas wrote: > > That's actually what we had in chapter > 18, "Installation from Source Code on Windows", since removed. But for > some reason we decided that on non-Windows platforms, it needed a > whole new chapter rather than an extra sentence in the

Re: documentation structure

2024-03-22 Thread David G. Johnston
On Fri, Mar 22, 2024 at 11:19 AM Robert Haas wrote: > On Fri, Mar 22, 2024 at 1:35 PM Bruce Momjian wrote: > > But that all seems like a separate question from why we have the > statistic collector views in a completely different part of the > documentation from the rest of the system views. My

Re: documentation structure

2024-03-22 Thread David G. Johnston
On Fri, Mar 22, 2024, 09:32 Robert Haas wrote: > > > I notice that you say that the "Installation" section should "cover > the architectural overview and point people to where they can find the > stuff they need to install PostgreSQL in the various ways available to > them" so maybe you're not

Re: Reports on obsolete Postgres versions

2024-04-03 Thread David G. Johnston
On Tue, Apr 2, 2024 at 1:47 PM Bruce Momjian wrote: > On Tue, Apr 2, 2024 at 11:34:46AM +0200, Magnus Hagander wrote: > > Okay, I changed "superseded" to "old", and changed "latest" to > "current", patch attached. > > I took a pass at this and found a few items of note. Changes on top of

Re: CREATE TABLE creates a composite type corresponding to the table row, which is and is not there

2024-04-03 Thread David G. Johnston
On Thu, Mar 28, 2024 at 8:02 PM Erik Wienhold wrote: > Thanks, that sounds better. I incorporated that with some minor edits > in the attached v3. > Looks good. You added my missing ( but dropped the comma after "i.e." diff --git a/doc/src/sgml/ref/create_table.sgml

Re: documentation structure

2024-04-05 Thread David G. Johnston
On Fri, Apr 5, 2024 at 9:18 AM Robert Haas wrote: > On Fri, Apr 5, 2024 at 12:15 PM David G. Johnston > wrote: > > Here is a link to my attempt at this a couple of years ago. It > basically "abuses" refentry. > > > > > https://www.postgresql.org/m

Re: documentation structure

2024-04-05 Thread David G. Johnston
On Fri, Apr 5, 2024 at 9:01 AM Robert Haas wrote: > > > The rendering can be adjusted to some degree, but then we also need to > > make sure any new chunking makes sense in other chapters. (And it might > > also change a bunch of externally known HTML links.) > > I looked into this and I'm

Re: CREATE TABLE creates a composite type corresponding to the table row, which is and is not there

2024-03-28 Thread David G. Johnston
On Thu, Mar 7, 2024 at 9:29 PM Erik Wienhold wrote: > I wrote: > > The attached v2 is a simpler patch that instead modifies the existing > > error message. > > Forgot to attach v2. > > For consideration for the doc portion. The existing wording is too imprecise for my liking and just tacking on

Re: Possibility to disable `ALTER SYSTEM`

2024-03-27 Thread David G. Johnston
On Wed, Mar 27, 2024 at 10:12 AM Isaac Morland wrote: > On Wed, 27 Mar 2024 at 13:05, Greg Sabino Mullane > wrote: > >> The purpose of the setting is to prevent accidental >>> modifications via ALTER SYSTEM in environments where >> >> >> The emphasis on 'accidental' seems a bit heavy here, and

Re: Possibility to disable `ALTER SYSTEM`

2024-03-27 Thread David G. Johnston
On Wed, Mar 27, 2024 at 3:13 PM Bruce Momjian wrote: > On Wed, Mar 27, 2024 at 06:09:02PM -0400, Bruce Momjian wrote: > > On Wed, Mar 27, 2024 at 11:05:55AM -0400, Robert Haas wrote: > > > On Wed, Mar 27, 2024 at 10:43 AM Jelte Fennema-Nio > wrote: > > > > Alright, changed the GUC name to

Re: Possibility to disable `ALTER SYSTEM`

2024-03-27 Thread David G. Johnston
On Wed, Mar 27, 2024 at 3:18 PM David G. Johnston < david.g.johns...@gmail.com> wrote: > On Wed, Mar 27, 2024 at 3:13 PM Bruce Momjian wrote: > >> On Wed, Mar 27, 2024 at 06:09:02PM -0400, Bruce Momjian wrote: >> > On Wed, Mar 27, 2024 at 11:05:55AM -0400, Robert Haa

Re: Possibility to disable `ALTER SYSTEM`

2024-03-27 Thread David G. Johnston
On Wed, Mar 27, 2024 at 5:43 PM David G. Johnston < david.g.johns...@gmail.com> wrote: > > This section is also the main entry point for users into the configuration > subsystem and hasn't been updated to reflect this new feature. That seems > like an oversight that nee

Re: Possibility to disable `ALTER SYSTEM`

2024-03-27 Thread David G. Johnston
On Wed, Mar 27, 2024 at 5:17 PM Bruce Momjian wrote: > On Thu, Mar 28, 2024 at 12:43:29AM +0100, Jelte Fennema-Nio wrote: > > + xreflabel="allow_alter_system"> > > + allow_alter_system (boolean) > > + > > + allow_alter_system configuration > parameter > > + > > +

Re: Extension for PostgreSQL WIP

2024-03-24 Thread David G. Johnston
On Sun, Mar 24, 2024 at 5:49 AM ShadowGhost wrote: > Cast_jsonb_to_hstore WIP > v1 > This extension add function that can cast jsonb to hstore. > That link to my github where does my extension lie > https://github.com/antuanviolin/cast_jsonb_to_hstore > If you are intending to submit this to

Re: Reports on obsolete Postgres versions

2024-04-04 Thread David G. Johnston
On Thu, Apr 4, 2024 at 11:23 AM Bruce Momjian wrote: > On Wed, Apr 3, 2024 at 06:01:41PM -0700, David G. Johnston wrote: > > > > The PostgreSQL Global Development Group supports a major version for 5 > years > > -after its initial release. After its five year annive

Re: Better error messages for %TYPE and %ROWTYPE in plpgsql

2024-02-26 Thread David G. Johnston
On Mon, Feb 26, 2024 at 6:54 PM Andy Fan wrote: > > "David G. Johnston" writes: > > > On Mon, Feb 26, 2024 at 5:46 PM Andy Fan wrote: > > > > > Per recent discussion[1], plpgsql returns fairly unhelpful "syntax > > > error&q

Re: Better error messages for %TYPE and %ROWTYPE in plpgsql

2024-02-26 Thread David G. Johnston
On Mon, Feb 26, 2024 at 5:46 PM Andy Fan wrote: > > Per recent discussion[1], plpgsql returns fairly unhelpful "syntax > > error" messages when a %TYPE or %ROWTYPE construct references a > > nonexistent object. Here's a quick little finger exercise to try > > to improve that. > > Looks this

Re: PG catalog

2024-05-24 Thread David G. Johnston
On Thursday, May 23, 2024, Karki, Sanjay wrote: > > I need to grant select on privilege in pg_catalog to user so I can connect > via Toad Data point , > > Users can already select from the tables in pg_catalog, grant able privileges not required or allowed. Of course, some specific data is

Re: pgsql: Add more SQL/JSON constructor functions

2024-05-28 Thread David G. Johnston
On Monday, May 27, 2024, Alvaro Herrera wrote: > On 2024-May-27, Alvaro Herrera wrote: > > > > JSON_SERIALIZE() > > I just noticed this behavior, which looks like a bug to me: > > select json_serialize('{"a":1, "a":2}' returning varchar(5)); > json_serialize > > {"a": > > I

Re: commitfest.postgresql.org is no longer fit for purpose

2024-05-17 Thread David G. Johnston
On Friday, May 17, 2024, Joe Conway wrote: > > I wrote: > >> Namely, the week before commitfest I don't actually know if I will have >> the time during that month, but I will make sure my patch is in the >> commitfest just in case I get a few clear days to work on it. Because if it >> isn't

Re: CREATE TABLE creates a composite type corresponding to the table row, which is and is not there

2024-05-17 Thread David G. Johnston
On Fri, May 17, 2024 at 4:57 PM Erik Wienhold wrote: > On 2024-05-16 17:47 +0200, David G. Johnston wrote: > > On Wed, May 15, 2024 at 8:46 AM Robert Haas > wrote: > > > > > On Thu, Apr 4, 2024 at 12:41 AM Erik Wienhold wrote: > > > > Thanks, fixed in v

Re: doc regexp_replace replacement string \n does not explained properly

2024-05-20 Thread David G. Johnston
On Monday, May 20, 2024, jian he wrote: > hi. > > https://www.postgresql.org/docs/current/functions- > matching.html#FUNCTIONS-POSIX-REGEXP > > > If there is a match, > the source string is returned with the replacement string substituted > for the matching substring. > This happens

Re: Patch bug: Fix jsonpath .* on Arrays

2024-06-04 Thread David G. Johnston
On Tuesday, June 4, 2024, David E. Wheeler wrote: > Hackers, > > The behavior of the .* jpiAnyKey jsonpath selector seems incorrect. > > ``` > select jsonb_path_query('[1,2,3]', '$.*'); > jsonb_path_query > -- > (0 rows) > > select jsonb_path_query('[1,2,3,{"b": [3,4,5]}]',

Re: Explicit specification of index ensuring uniqueness of foreign columns

2024-05-31 Thread David G. Johnston
On Friday, May 31, 2024, Tom Lane wrote: > Kaiting Chen writes: > > I'd like to resurrect a subset of my proposal in [1], specifically that: > > The FOREIGN KEY constraint syntax gains a [ USING INDEX index_name ] > clause > > optionally following the referenced column list. > > ... > >

Re: improve predefined roles documentation

2024-06-13 Thread David G. Johnston
On Thu, Jun 13, 2024 at 12:48 PM Nathan Bossart wrote: > I think we could improve matters by abandoning the table and instead > documenting these roles more like we document GUCs, i.e., each one has a > section below it where we can document it in as much detail as we want. > > One of the main

Re: jsonpath: Missing Binary Execution Path?

2024-06-13 Thread David G. Johnston
On Thursday, June 13, 2024, Chapman Flack wrote: > On 06/13/24 21:24, David G. Johnston wrote: > > I'm content that the operators in the 'filter operators' table need to be > > within filter but then I cannot reconcile why this example worked: > > > > david=# select js

Re: jsonpath: Missing Binary Execution Path?

2024-06-13 Thread David G. Johnston
On Thursday, June 13, 2024, Chapman Flack wrote: > On 06/13/24 21:46, David G. Johnston wrote: > >>> david=# select jsonb_path_query('1', '$ >= 1'); > >> > >> Good point. I can't either. No way I can see to parse that as > >> a . > > >

Re: jsonpath: Missing Binary Execution Path?

2024-06-13 Thread David G. Johnston
On Thu, Jun 13, 2024 at 6:10 PM Chapman Flack wrote: > On 06/13/24 16:43, David E. Wheeler wrote: > > Paging Mr. Eisentraut! > > I'm not Mr. Eisentraut, but I have at last talked my way into some > access to the standard, so ... > > Note 487 emphasizes that JSON path predicates "are not

Re: Document NULL

2024-06-17 Thread David G. Johnston
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

2024-06-15 Thread David G. Johnston
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.

Re: ON ERROR in json_query and the like

2024-06-12 Thread David G. Johnston
On Wednesday, June 12, 2024, Markus Winand wrote: > > > 10.14 SR 1: The declared type of the simply contained > in the immediately contained in the item> shall be a string type or a JSON type. > It might be best to think of it as two separate functions, overloaded: > >

Re: ON ERROR in json_query and the like

2024-06-12 Thread David G. Johnston
On Tuesday, May 28, 2024, Markus Winand wrote: > > 2. EMPTY [ARRAY|OBJECT] ON ERROR implies ERROR ON EMPTY > >17beta1=# SELECT JSON_QUERY('[]', '$[*]' EMPTY ARRAY ON ERROR) a; > a > > [] >(1 row) > >As NULL ON EMPTY is implied, it should give the same result as >

Re: Shouldn't jsonpath .string() Unwrap?

2024-06-12 Thread David G. Johnston
On Sat, Jun 8, 2024 at 3:50 PM David E. Wheeler wrote: > Hackers, > > Most of the jsonpath methods auto-unwrap in lax mode: > > david=# select jsonb_path_query('[-2,5]', '$.abs()'); > jsonb_path_query > -- > 2 > 5 > (2 rows) > > The obvious exceptions are size() and type(),

Re: Document NULL

2024-06-18 Thread David G. Johnston
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

2024-06-19 Thread David G. Johnston
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: Extension security improvement: Add support for extensions with an owned schema

2024-06-19 Thread David G. Johnston
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: SQL/JSON query functions context_item doc entry and type requirement

2024-06-19 Thread David G. Johnston
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,

Re: Wrong security context for deferred triggers?

2024-06-22 Thread David G. Johnston
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?

2024-06-22 Thread David G. Johnston
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

Re: Unable parse a comment in gram.y

2024-06-22 Thread David G. Johnston
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

Re: ON ERROR in json_query and the like

2024-06-20 Thread David G. Johnston
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

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

2024-06-20 Thread David G. Johnston
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

Re: ON ERROR in json_query and the like

2024-06-20 Thread David G. Johnston
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 o

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

2024-06-20 Thread David G. Johnston
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

2024-06-20 Thread David G. Johnston
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

Re: improve predefined roles documentation

2024-06-20 Thread David G. Johnston
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

Re: ON ERROR in json_query and the like

2024-06-20 Thread David G. Johnston
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 J

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

2024-06-23 Thread David G. Johnston
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: [PATCH] Add ACL (Access Control List) acronym

2024-06-24 Thread David G. Johnston
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

2024-06-24 Thread David G. Johnston
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

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

2024-06-24 Thread David G. Johnston
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

Re: improve predefined roles documentation

2024-06-24 Thread David G. Johnston
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

Re: Should we document how column DEFAULT expressions work?

2024-06-26 Thread David G. Johnston
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

Re: Unable parse a comment in gram.y

2024-06-23 Thread David G. Johnston
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: >

Doc Rework: Section 9.16.13 SQL/JSON Query Functions

2024-06-25 Thread David G. Johnston
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

Re: Should we document how column DEFAULT expressions work?

2024-06-30 Thread David G. Johnston
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

Re: Should we document how column DEFAULT expressions work?

2024-06-30 Thread David G. Johnston
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 doin

Re: Should we document how column DEFAULT expressions work?

2024-06-30 Thread David G. Johnston
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? > >

Re: Should we document how column DEFAULT expressions work?

2024-06-30 Thread David G. Johnston
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: Is missing LOGIN Event on Trigger Firing Matrix ?

2024-06-27 Thread David G. Johnston
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

Re: Custom type's modifiers

2024-06-27 Thread David G. Johnston
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

Re: Should we document how column DEFAULT expressions work?

2024-06-25 Thread David G. Johnston
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

Re: Should we document how column DEFAULT expressions work?

2024-06-26 Thread David G. Johnston
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, > >

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

2024-06-25 Thread David G. Johnston
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: improve predefined roles documentation

2024-06-25 Thread David G. Johnston
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

<    6   7   8   9   10   11   12   >