On 2024-11-04 21:03 +0100, Daniel Gustafsson wrote:
> > On 4 Nov 2024, at 21:00, Bruce Momjian wrote:
>
> > Proposed patch attached.
>
> LGTM.
Seconded.
--
Erik
On 2024-11-04 16:13 +0100, Matthias van de Meent wrote:
> On Mon, 4 Nov 2024 at 15:41, Bruce Momjian wrote:
> >
> > Someone emailed me privately saying they were confused because they
> > thought pg_dump --no-comments would remove SQL comments, not the SQL
> > COMMENT commands. Is this something
On 2024-09-05 22:33 +0200, Erik Wienhold wrote:
> On 2024-07-27 02:45 +0200, Erik Wienhold wrote:
> > On 2024-07-12 16:49 +0200, Said Assemlal wrote:
> > > > My initial idea, while writing the patch, was that one could replace the
> > > > matview without populati
On 2024-10-09 09:52 +0200, Daniel Gustafsson wrote:
> Done, thanks for the report!
Thanks for pushing!
--
Erik
I wrote:
> I get this error when running pgindent with perl 5.40:
>
> Attempt to call undefined import method with arguments ("devnull") via
> package "File::Spec" (Perhaps you forgot to load the package?) at
> src/tools/pgindent/pgindent line 10.
> BEGIN failed--compilation aborted at s
I get this error when running pgindent with perl 5.40:
Attempt to call undefined import method with arguments ("devnull") via
package "File::Spec" (Perhaps you forgot to load the package?) at
src/tools/pgindent/pgindent line 10.
BEGIN failed--compilation aborted at src/tools/pgindent/pgi
On 2024-07-27 02:45 +0200, Erik Wienhold wrote:
> On 2024-07-12 16:49 +0200, Said Assemlal wrote:
> > > My initial idea, while writing the patch, was that one could replace the
> > > matview without populating it and then run the concurrent refresh, like
> > > thi
On 2024-07-30 08:30 +0200, Yugo NAGATA wrote:
> On Tue, 30 Jul 2024 01:36:55 +0200
> Erik Wienhold wrote:
>
> > On 2024-07-01 15:08 +0200, Yugo NAGATA wrote:
> > > I would like to propose to add a new field to psql's \dAo+ meta-command
> > > to show whether
On 2024-07-01 15:08 +0200, Yugo NAGATA wrote:
> I would like to propose to add a new field to psql's \dAo+ meta-command
> to show whether the underlying function of an operator is leak-proof.
+1 for making that info easily accessible.
> This idea is inspired from [1] that claims some indexes uses
in the docs that this
is intended to be used before a concurrent refresh.
Patch 0001 now covers all matview cases in psql's tab completion. I
missed some of them with v1.
--
Erik
>From a529a00af40be611e6bed49fe0341b7435a72930 Mon Sep 17 00:00:00 2001
From: Erik Wienhold
Date: Tue, 21 May
On 2024-07-25 22:29 +0200, Tom Lane wrote:
> Erik Wienhold writes:
> > Thanks, I didn't know that guideline. Both fixed in v6.
>
> This still isn't following our usual message style IMO. Here's a
> proposed v7 that outputs
>
> -ERROR: type stuff is not
On 2024-07-09 21:53 +0200, Tom Lane wrote:
> Well, that didn't take long: several animals are reporting
> different error text for one or both of those new test cases.
> [...snip...]
> At the moment I'm thinking that we should just remove those
> new test cases again.
+1
--
Erik
On 2024-07-07 22:43 +0200, Tom Lane wrote:
> As far as the errcontext changes go: I think we have to just bite
> the bullet and accept them. It looks like 2.13 has a completely
> different mechanism than prior versions for deciding when to issue
> XML_ERR_NOT_WELL_BALANCED. And it's not even clea
On 2024-07-06 20:43 +0200, Tom Lane wrote:
> One angle that ought to be considered is that some of this stuff may
> be flat-out bugs in 2.13.0. I see at
>
> https://gitlab.gnome.org/GNOME/libxml2/-/releases
>
> that both 2.13.1 and 2.13.2 contain fixes for "regressions" in 2.13.0.
> I'm disincli
On 2024-07-06 16:25 +0200, Tom Lane wrote:
> Erik Wienhold writes:
> > So, there must be breaking changes in 2.13.0:
> > https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.13.0
>
> Yeah, apparently --- I get what look like the same diffs with
> libxml2 2.13.0 recen
On 2024-07-06 11:57 +0200, Frank Streitzig wrote:
> >> My system is a Arch Linux.
> >> I get after upgrade the libxml2 package (from 2.12.7-1 to 2.13.1-1)
> >> test errors for xml:
> >>
> >> not ok 202 + xml 1464 ms
> >> [...snip...]
> >> # 1 of 222 tests fai
On 2024-07-04 22:18 +0200, Said Assemlal wrote:
> +1 for this feature.
Thanks!
> I noticed replacing the materialized view is blocking all reads. Is that
> expected ? Even if there is a unique index ?
That is expected because AccessExclusiveLock is acquired on the existing
matview. This is also
On 2024-07-05 15:33 +0200, Frank Streitzig wrote:
> My system is a Arch Linux.
> I get after upgrade the libxml2 package (from 2.12.7-1 to 2.13.1-1)
> test errors for xml:
>
> not ok 202 + xml 1464 ms
> [...snip...]
> # 1 of 222 tests failed.
> # The differen
On 2024-07-02 16:21 +0200, Tom Lane wrote:
> Erik Wienhold writes:
> > On 2024-07-02 10:45 +0200, Peter Eisentraut wrote:
> >> I had to revert the test case from the 0002 patch. It ended up running
> >> some
> >> build farm machines out of memory.
>
&
I wrote:
> Patch 0002 deprecates CREATE MATERIALIZED VIEW IF NOT EXISTS because it
> no longer seems necessary with patch 0001. Tom Lane commented[1] about
> the general dislike of IF NOT EXISTS, to which I agree, but maybe this
> was meant only in response to adding new commands.
One could also
On 2024-07-02 10:45 +0200, Peter Eisentraut wrote:
> On 02.07.24 10:14, Peter Eisentraut wrote:
> > I have committed your two v4 patches.
>
> I had to revert the test case from the 0002 patch. It ended up running some
> build farm machines out of memory.
dhole, morepork, and schnauzer. For exam
On 2024-07-02 10:14 +0200, Peter Eisentraut wrote:
> On 19.05.24 16:43, Erik Wienhold wrote:
> > On 2024-05-19 07:00 +0200, Alexander Lakhin wrote:
> > > I encountered anomalies that you address with this patch too.
> > > And I can confirm that it fixes most case
message-id/226806.1693430777%40sss.pgh.pa.us
[2]
https://wiki.postgresql.org/images/a/ad/Materialised_views_now_and_the_future-pgconfeu_2013.pdf#page=23
--
Erik
>From b9f96d4a8e806389bf33a96be6db3a57bccb48cf Mon Sep 17 00:00:00 2001
From: Erik Wienhold
Date: Tue, 21 May 2024 18:35:47 +0200
Subje
On 2024-06-04 13:21 +0200, Dean Rasheed wrote:
> Committed and back-patched to v16. Thanks for the report and patch.
Thanks for the review and push Dean.
--
Erik
On 2024-06-03 18:57 +0200, Tom Lane wrote:
> Erik Wienhold writes:
> > On 2024-06-03 00:15 +0200, Tom Lane wrote:
> >> The new bit of information that this bug report provides is that it's
> >> possible to get a TCL_ERROR result without Tcl having set errorInfo.
&
On 2024-06-03 00:15 +0200, Tom Lane wrote:
> The new bit of information that this bug report provides is that it's
> possible to get a TCL_ERROR result without Tcl having set errorInfo.
> That seems a tad odd, and it must happen only in weird corner cases,
> else we'd have heard of this decades ago
On 2024-06-02 14:32 +0200, Pierre Forstmann wrote:
> I understand that Tcl_GetVar should not be used any more and should be
> replaced by Tcl_GetStringResult
> (but I know nothing about Tcl internals)
>
> Following patch :
> diff postgres/src/pl/tcl/pltcl.c.orig postgres/src/pl/tcl/pltcl.c
> 1373c
On 2024-05-20 05:02 +0200, Tom Lane wrote:
> Erik Wienhold writes:
> > On 2024-05-20 03:26 +0200, jian he wrote:
> >> /* Check parameter number is in range */
> >> if (paramno <= 0 || paramno > MaxAllocSize / sizeof(Oid))
> >> ereport(ERROR, ...
&g
On 2024-05-20 03:26 +0200, jian he wrote:
> On Sun, May 19, 2024 at 10:43 PM Erik Wienhold wrote:
> >
> > On 2024-05-19 07:00 +0200, Alexander Lakhin wrote:
> > > I encountered anomalies that you address with this patch too.
> > > And I can confirm that it fixes
s beyond that limit.
--
Erik
>From 5382f725ac1ff99b5830e8ca04613467660afaa2 Mon Sep 17 00:00:00 2001
From: Erik Wienhold
Date: Tue, 14 May 2024 14:12:11 +0200
Subject: [PATCH v4 1/2] Fix overflow in parsing of positional parameter
Replace atol with pg_strtoint32_safe in the backend par
/www.postgresql.org/docs/current/error-style-guide.html#ERROR-STYLE-GUIDE-GRAMMAR-PUNCTUATION
>
> Detail and hint messages: Use complete sentences, and end each with a
> period. Capitalize the first word of sentences.
Thanks, I didn't know that guideline. Both fixed in v6.
--
Er
ht, even for minor fixes?
--
Erik
>From d3ad2971dcb8ab15fafe1a5c69a15e5994eac76d Mon Sep 17 00:00:00 2001
From: Erik Wienhold
Date: Tue, 14 May 2024 14:12:11 +0200
Subject: [PATCH v3 1/3] Fix overflow in parsing of positional parameter
Replace atol with pg_strtoint32_safe in the backend parser and with
strtoint in ECPG to
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 v4. Looks like American English prefers that comma and
> > > it&
on Sep 17 00:00:00 2001
From: Erik Wienhold
Date: Wed, 15 May 2024 02:43:12 +0200
Subject: [PATCH] plpgsql: fix parsing of integer range with underscores
Fix lexer rule "numericfail" that ensures that we parse 1_000..1_000 as
1000..1000 instead of failing with 'syntax error at or near &
On 2024-05-14 16:40 +0200, Tom Lane wrote:
> Dean Rasheed writes:
> > On Tue, 14 May 2024 at 07:43, Michael Paquier wrote:
> >> On Tue, May 14, 2024 at 05:18:24AM +0200, Erik Wienhold wrote:
> >>> Parameter $1_2 is taken as $1 because in rule {param} in scan.l we
d still
cares about readability to use underscores. But maybe users simply
expect that underscores are valid here as well.
--
Erik
>From 0f319818360cdd26e96198ea7fcaba1b8298f264 Mon Sep 17 00:00:00 2001
From: Erik Wienhold
Date: Tue, 14 May 2024 04:14:08 +0200
Subject: [PATCH] Fix par
On 2024-04-24 13:52 +0200, David E. Wheeler wrote:
> On Apr 24, 2024, at 05:51, Peter Eisentraut wrote:
>
> >A is classified as follows.
> >
> >Case:
> >
> >a) A that is a is a > path context variable>.
> >
> >b) A that begins with is a
> > .
> >
> >c) Ot
On 2024-04-13 00:20 +0200, Tom Lane wrote:
> Erik Wienhold writes:
> > I'm surprised that the lexer handles compound tokens. I'd expect to
> > find that in the parser, especially because of using the context-aware
> > plpgsql_ns_lookup to determine if we
On 2024-04-09 00:54 +0200, Tom Lane wrote:
> I poked at this and found that the failures occur when the patched
> code decides to trim an expression like "_r.v" to just "_r", naturally
> breaking the semantics completely. That happens because when
> plpgsql_yylex recognizes a compound token, it do
On 2024-04-08 21:29 +0200, Daniel Gustafsson wrote:
> Over in [0] I asked whether it would be worthwhile converting all our README
> files to Markdown, and since it wasn't met with pitchforks I figured it would
> be an interesting excercise to see what it would take (my honest gut feeling
> was tha
On 2024-04-07 18:13 +0200, David E. Wheeler wrote:
> A question about the behavior of the JSON Path parser. The docs[1]
> have this to say about numbers:
>
> > Numeric literals in SQL/JSON path expressions follow JavaScript
> > rules, which are different from both SQL and JSON in some minor
> >
I wrote:
> Attached v2 tries to do that.
Hit send too soon. Attached now.
--
Erik
>From 23a20a410dc92946141b6c6fa5100473eac482cf Mon Sep 17 00:00:00 2001
From: Erik Wienhold
Date: Sat, 6 Apr 2024 22:36:54 +0200
Subject: [PATCH v2] plpgsql: accept trailing line comment in CASE WHEN
Expr
On 2024-04-07 06:33 +0200, Tom Lane wrote:
> Erik Wienhold writes:
> > I'm surprised that the comment is not skipped by the scanner at this
> > point. Maybe because the parser just reads the raw expression between
> > WHEN and THEN with plpgsql_append_source_t
at this
point. Maybe because the parser just reads the raw expression between
WHEN and THEN with plpgsql_append_source_text via read_sql_construct.
How about the attached patch? It's a workaround by simply adding a line
feed character between the raw expression and the closing parenthesis.
-
On 2024-04-05 05:37 +0200, Tom Lane wrote:
> Erik Wienhold writes:
> > I'm trying to build Postgres with that older libedit version but can't
> > figure out what options to pass to ./configure so that it picks
> > /usr/local/lib/libedit.so instead of /usr/lib/li
On 2024-04-05 05:10 +0200, Tom Lane wrote:
> Erik Wienhold writes:
> > It works with the latest libedit 20230828-3.1. Have to check the NetBSD
> > source to find out what changed since 20181209-3.1.
>
> Yeah, the test is passing on mamba which is running the (just
> off
On 2024-04-05 04:37 +0200, Michael Paquier wrote:
> On Thu, Apr 04, 2024 at 10:31:24PM -0400, Tom Lane wrote:
> > Michael Paquier writes:
> >> This stuff is actually kind of funny on this host, "\echo :{?VERB\t"
> >> completes to something incorrect, as of:
> >> postgres=# \echo :\{\?VERBOSITY\}
>
On 2024-04-04 03:29 +0200, David G. Johnston wrote:
> 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.
> >
>
> You added my missing ( but dropped the comma aft
On 2024-03-31 15:22 +0200, Marcos Pegoraro wrote:
> This is my first patch, so sorry if I miss something.
Please make sure that tests are passing by running make check:
https://www.postgresql.org/docs/current/regress-run.html#REGRESS-RUN-TEMP-INST
The patch breaks src/test/regress/sql/plpgsql.sql
On 2024-03-29 04:27 +0100, Isaac Morland wrote:
> On Thu, 28 Mar 2024 at 20:38, Erik Wienhold wrote:
>
>
> > Of course the problem with using DROP and CREATE is that indexes and
> > privileges (anything else?) must also be restored. I haven't bothered
> > with t
r not using "stand-alone" here as well if it's the established
term.
--
Erik
>From e9a79e6d5e063098eed4f834b18d576089b38499 Mon Sep 17 00:00:00 2001
From: Erik Wienhold
Date: Fri, 8 Mar 2024 04:21:56 +0100
Subject: [PATCH v3] Document that typed tables rely on CREATE TYPE
CREA
g DROP and CREATE is that indexes and
privileges (anything else?) must also be restored. I haven't bothered
with that yet.
--
Erik
>From efb5e37d90b668011307b602655f28455d700635 Mon Sep 17 00:00:00 2001
From: Erik Wienhold
Date: Fri, 29 Mar 2024 01:08:35 +0100
Subject: [PATCH v1] psql: \ev and
On 2023-05-15 06:32 +0200, Kirk Wolak wrote:
> Personally I would appreciate it if \sv actually showed you the DDL.
> Oftentimes I will \ev something to review it, with syntax highlighting.
+1. I was just reviewing some matviews and was surprised that psql
lacks commands to show their definitions
On 2024-03-17 20:50 +0100, David E. Wheeler wrote:
> On Mar 17, 2024, at 15:12, Erik Wienhold wrote:
> > So I think it makes sense to reword the entire backslash part of the
> > paragraph and remove references to JSON entirely. The attached patch
> > does that and also
put' for
the second case ($.f$oo), however, looks as if the scanner identifies
'$oo' as a variable instead of contiuing the scan of identifier (f$oo)
for the member accessor. Looks like a bug to me because a variable
doesn't even make sense in that place.
What works though, besid
On 2024-03-09 02:42 +0100, David E. Wheeler wrote:
> On Mar 7, 2024, at 23:39, Erik Wienhold wrote:
>
> > I think you need to swap the examples. The text mentions the error case
> > first and the NULL case second.
>
> 🤦🏻♂️
>
> Thanks, fixed in the attached patch.
Thanks, LGTM.
--
Erik
Hi David,
On 2024-03-08 02:37 +0100, David E. Wheeler wrote:
> I’ve rebased the patch and, in an attempt to clarify this behavior,
> added a couple of examples to the docs for to_regtype. Updated patch
> attached.
On your latest addition:
> +). Failure to extract a valid potential
> +
I wrote:
> The attached v2 is a simpler patch that instead modifies the existing
> error message.
Forgot to attach v2.
--
Erik
>From 9ab6b625e8f93ae2957144ec7f0ba32cf8a3bb5b Mon Sep 17 00:00:00 2001
From: Erik Wienhold
Date: Fri, 8 Mar 2024 04:21:56 +0100
Subject: [PATCH v2] Docu
I wrote:
> The attached patch fixes the error message and also documents that
> requirement.
On second thought, adding a separate error message doesn't really make
sense. The attached v2 is a simpler patch that instead modifies the
existing error message.
--
Erik
# and I can add comment to the type
>
> hannuk=# COMMENT ON TYPE pair is 'A Shroedingers type';
> COMMENT
>
> # but \dT does not show it (second case)
>
> hannuk=# \dT pair
> List of data types
> Schema | Name | Description
> +--+---
On 2024-03-03 03:00 +0100, Steve Chavez wrote:
> psql has the :{?name} syntax for testing a psql variable existence.
>
> But currently doing \echo :{?VERB doesn't trigger tab completion.
>
> This patch fixes it. I've also included a TAP test.
Thanks. The code looks good, all tests pass, and the
On 2024-02-21 22:49 +0100, David E. Wheeler wrote:
> On Feb 21, 2024, at 16:43, Erik Wienhold wrote:
>
> > The docs still state that to_regtypemod() has a named parameter, which
> > is not the case per pg_proc.dat.
>
> Bah, I cleaned it up before but somehow put it back
On 2024-02-21 17:51 +0100, David E. Wheeler wrote:
> On Feb 21, 2024, at 11:18, Erik Wienhold wrote:
>
> > Thanks. But it's an applefile again, not a patch :P
>
> Let’s try that again.
Thanks.
> +to_regtypemod ( type
> text )
The docs still state tha
On 2024-02-21 16:14 +0100, David E. Wheeler wrote:
>
> V8 attached.
Thanks. But it's an applefile again, not a patch :P
--
Erik
On 2024-02-20 15:44 +0100, David E. Wheeler wrote:
> I’ve tweaked the comments and their order in v7, attached.
>
> This goes back to the discussion of the error raising of
> to_regtype[1], so I’ve incorporated the patch from that thread into
> this patch, and set up the docs for to_regtypemod() w
On 2024-02-19 23:59 +0100, David E. Wheeler wrote:
> On Feb 19, 2024, at 15:47, Tom Lane wrote:
>
> >> 1. Add a to_regtypmod() for those who just want the typemod.
> >
> > Seems like there's a good case for doing that.
>
> I’ll work on that.
See the patch I wrote for my benchmarks. But it's p
On 2024-02-18 20:00 +0100, Pavel Stehule wrote:
> The overhead of parse_type_and_format can be related to higher planning
> time. PL/pgSQL can assign composite without usage FROM clause.
Thanks, didn't know that this makes a difference. In that case both
variants are on par.
BEGIN;
scaling factor: 1
query mode: simple
number of clients: 1
number of threads: 1
maximum number of tries: 1
duration: 10 s
number of transactions actually processed: 270820
number of failed transactions: 0 (0.000%)
latency ave
Let me comment on some issues since I wrote the very first version of
parse_type() on which David's patch is based.
> On 2024-02-01 01:00 +0100, jian he wrote:
>
> cosmetic issue. Looking around other error handling code, the format
> should be something like:
> `
> if (get_call_result_type(fcin
On 2024-02-08 20:37 +0100, Jim Jones wrote:
> One thing I just noticed. The psql autocomplete feature does not suggest
> the new + option of \conninfo. For instance, when typing "\connin[TAB]"
> it automatically autocompletes to "\conninfo ". I guess it should also
> be included in this patch.
Mod
On 2024-02-07 05:13 +0100, Maiquel Grassi wrote:
> On Tue, Feb 06, 2024 at 09:45:54PM +, Maiquel Grassi wrote:
> > My initial idea has always been that they should continue to appear
> > because \conninfo+ should show all the things that \conninfo shows and
> > add more information. I t
On 2024-02-06 19:19 +0100, Nathan Bossart wrote:
> On Tue, Feb 06, 2024 at 05:27:01PM +, Maiquel Grassi wrote:
> > postgres=# \conninfo+
> > Current Connection Information
> >Attribute| Value
> > +
> > Database | postgres
> > User |
On 2024-02-04 20:20 +0100, David E. Wheeler wrote:
> On Feb 2, 2024, at 15:33, David E. Wheeler wrote:
>
> > Anyway, I’m happy to submit a documentation patch along the lines you
> > suggested.
>
> How’s this?
>
> --- a/doc/src/sgml/func.sgml
> +++ b/doc/src/sgml/func.sgml
> @@ -25460,11 +2546
On 2024-01-19 22:15 +0100, Tom Lane wrote:
> "David E. Wheeler" writes:
> > [ v7-0001-Improve-boolean-predicate-JSON-Path-docs.patch ]
>
> + \set json '{
>"track": {
> "segments": [
>{
>
> I find the textual change rather unwieldy, but the bigger problem is
> that this example d
On 2023-11-14 18:13 +0100, Kanmani Thamizhanban wrote:
> Good day! I'm not able to launch Postgres PGAdmin 4 in my MAC OS, I have
> tried with both versions 15 and 16, but nothing is working. It says that it
> has quit unexpectedly (screenshot attached). I have attached the bug report
> as well alo
On 2023-11-13 21:49 +0100, Tom Lane wrote:
> Patch pushed with minor adjustments, mainly rewriting some comments.
Thanks a lot!
--
Erik
On 2023-11-09 20:19 +0100, Tom Lane wrote:
> Laurenz Albe writes:
> > Thanks for the feedback. I'll set the patch to "ready for committer" then.
>
> So, just to clarify, we're settling on your v4 from [1]?
>
> [1]
> https://www.postgresql.org/message-id/d799f996f422231a99655f1223667d6d887e4c95
On 2023-11-08 13:23 +0100, Laurenz Albe wrote:
> I wonder how to proceed with this patch. The main disagreement is
> whether default privileges should be displayed as NULL (less invasive,
> but more confusing for beginners) or "(default)" (more invasive,
> but nicer for beginners).
Are there any
On 2023-10-24 00:58 +0200, David E. Wheeler wrote:
> On Oct 22, 2023, at 20:36, Erik Wienhold wrote:
>
> > That's an AppleSingle file according to [1][2]. It only contains the
> > resource fork and file name but no data fork.
>
> Ah, I had “Send large attachments w
On 2023-10-20 15:49 +0200, David Wheeler wrote:
> On Oct 19, 2023, at 23:49, Erik Wienhold wrote:
>
> > I don't even know what that represents, probably not some fancy file
> > compression.
That's an AppleSingle file according to [1][2]. It only contains the
resour
ieve Tom is against and I agree on that point).
I haven't thought off this yet. The attached v3 of my initial patch
does that. It also includes Laurenz' fix to no longer ignore \pset null
(minus the doc changes that suggest using \pset null to distinguish
between default and empty pr
gt; in "psql.sql" (not that it is very important).
I added some docs. There will be merge conflicts when combining with
your v5! Also moved the regression tests to psql.sql which is the right
place for testing meta commands.
--
Erik
>From 170ca82fa7b74cc9102582cdf48042131d5ae016 Mon
On 2023-10-20 05:20 +0200, David E. Wheeler wrote:
> On Oct 19, 2023, at 10:49 PM, Erik Wienhold wrote:
>
> > Just wanted to take a look at v5. But it's an applefile again :P
>
> I don’t get it. It was the other times too! Are you able to save it
> with a .patch suf
On 2023-10-19 15:39 +0200, David E. Wheeler wrote:
> On Oct 19, 2023, at 01:22, jian he wrote:
>
> Updated patch attached and also on GitHub.
>
>
> https://github.com/postgres/postgres/compare/master...theory:postgres:jsonpath-pred-docs
Just wanted to take a look at v5. But it's an applefil
On 2023-10-17 04:05 +0200, David G. Johnston wrote:
> Erik seems to favors (none)
Yes, with a slight favor for "(none)" because it's the least disruptive
to users who change \pset null to a non-blank string. The output of \dp
etc. would still look the same for default privileges.
But I'm also ok
On 2023-10-16 21:59 +0200, David E. Wheeler write:
> On Oct 15, 2023, at 23:03, Erik Wienhold wrote:
>
> > Your call but I'm not against including it in this patch because it
> > already touches the modes section.
>
> Okay, added, let’s just put all our cards on the
On 2023-10-16 17:56 +0200, Laurenz Albe write:
> David, how do you feel about this? I am wondering whether to set this patch
> "ready for committer" or not.
>
> There is Tom wondering upthread whether changing psql's behavior like that
> is too much of a compatibility break or not, but I guess it
On 2023-10-16 01:04 +0200, David E. Wheeler write:
> On Oct 14, 2023, at 19:51, Erik Wienhold wrote:
>
> > Thanks for putting this together. See my review at the end.
>
> Appreciate the speedy review!
You're welcome.
> >> Follow-ups I’d like to make:
> >
On 2023-10-14 22:40 +0200, David E. Wheeler write:
> Following up from a suggestion from Tom Lane[1] to improve the
> documentation of boolean predicate JSON path expressions, please find
> enclosed a draft patch to do so.
Thanks for putting this together. See my review at the end.
> It does thr
On 2023-10-14 06:16 +0200, Andrew Atkinson write:
>- When describing options for a command, changed to “option of” instead
>of “option to”
I think "option to" is not wrong (maybe less common). I've seen this
in other texts and took it as "the X option [that applies] to Y".
>- “system
On 2023-10-09 01:13 +0200, David E. Wheeler write:
> On Sep 12, 2023, at 21:00, Erik Wienhold wrote:
>
> >> I posted this question on Stack Overflow
> >> (https://stackoverflow.com/q/77046554/79202),
> >> and from the suggestion I got there, it seems that
On 2023-10-09 22:34 +0200, David G. Johnston write:
> On Mon, Oct 9, 2023 at 12:13 PM Tom Lane wrote:
> > Yeah. There is a lot of attraction in having \pset null affect these
> > displays just like all other ones. The fact that they act differently
> > now is a wart, not something we should repl
On 2023-10-09 10:29 +0200, Laurenz Albe write:
> On Sun, 2023-10-08 at 19:58 -0700, David G. Johnston wrote:
> > We probably should add the two terms to the glossary:
> >
> > empty privileges: all privileges explicitly revoked from the owner and
> > PUBLIC
> > (where applicable), and none otherwi
On 2023-10-09 09:54 +0200, Laurenz Albe write:
>
> I tinkered a bit with your documentation. For example, the suggestion to
> "\pset null" seemed to be in an inappropriate place. Tell me what you think.
+1 You're right to put that sentence right after the explanation of
empty privileges.
--
On 2023-10-08 06:14 +0200, Laurenz Albe write:
> On Sat, 2023-10-07 at 20:41 +0200, Erik Wienhold wrote:
> > > If you are happy enough with my patch, shall we mark it as ready for
> > > committer?
> >
> > I amended your patch to also document the effect of \pse
On 2023-10-07 14:29 +0200, Laurenz Albe write:
> On Sat, 2023-10-07 at 05:07 +0200, Erik Wienhold wrote:
> > On 2023-10-06 22:32 +0200, Laurenz Albe write:
> > > On Sun, 2023-09-17 at 21:31 +0200, Erik Wienhold wrote:
> > > > I wrote a patch to change psql's
On 2023-10-06 22:32 +0200, Laurenz Albe write:
> On Sun, 2023-09-17 at 21:31 +0200, Erik Wienhold wrote:
> > I wrote a patch to change psql's display of zero privileges after a user's
> > reported confusion with the psql output for zero vs. default privileges [1].
> &
On 2023-09-24 20:56 +0800, jacktby jacktby wrote:
> typedef struct TupleDescData
> {
> int natts; /* number of attributes
> in the tuple */
> Oid tdtypeid; /* composite type ID
> for tuple type */
> int32
On 18/09/2023 00:57 CEST Vik Fearing wrote:
> On 9/18/23 00:41, Erik Wienhold wrote:
> > On 18/09/2023 00:13 CEST David E. Wheeler wrote:
> >
> >> david=# select to_regtype('inteval second');
> >> ERROR: syntax error at or near "second
On 18/09/2023 00:13 CEST David E. Wheeler wrote:
> The docs for `to_regtype()` say, “this function will return NULL rather than
> throwing an error if the name is not found.” And it’s true most of the time:
>
> david=# select to_regtype('foo'), to_regtype('clam');
> to_regtype | to_regtype
> ---
1 - 100 of 106 matches
Mail list logo
