ch
> point in them.
+1 for removing it entirely and including this prominently in the
release notes.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
which means that I think a lot
> of the commentary around SubscriptingRef is misleading. But I do
> not have a better word to suggest offhand. Thoughts?
Would this be something more along the lines of a "dependent type," or
is that adding too much baggage?
Best,
David.
Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
>From 04059e68ffcd8cf4052ccb6a013f0cf2e0095eb8 Mon Sep 17 00:00:00 2001
From: David Fetter
Date: Wed, 16 Dec 2020 13:17:32 -0800
Subject: [PATCH v1] Implem
On Wed, Dec 16, 2020 at 05:30:13PM -0500, Tom Lane wrote:
> David Fetter writes:
> > We have \gset to set some parameters, but not ones in the environment,
> > so I fixed this with a new analogous command, \gsetenv.
>
> In view of the security complaints we just had about \g
k at it as a
feature psql users might appreciate having. As the author, I obviously
see it that way, but again as the author, it's not for me to make that
call.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
On Sun, Dec 20, 2020 at 01:07:12PM -0500, Tom Lane wrote:
> David Fetter writes:
> > On Sun, Dec 20, 2020 at 02:26:14PM +0100, Fabien COELHO wrote:
> >> SELECT 'Calvin' AS foo \gset
> >> \setenv FOO :foo
> >> \! echo $FOO
> >> Calvin
>
&g
On Sun, Dec 20, 2020 at 10:42:40PM +0200, Heikki Linnakangas wrote:
> On 20/12/2020 21:05, David Fetter wrote:
> > We have plenty of ways to spawn shells and cause havoc, and we
> > wouldn't be able to block them all even if we decided to put a bunch
> > of pretty onero
On Sun, Dec 27, 2020 at 09:53:13AM -0800, Zhihong Yu wrote:
> Hi,
>
> This is not an ideal way to index multirages, but something we can
> easily have.
What sort of indexing improvements do you have in mind?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Hi,
Per request, I'd like to see about surfacing $Subject to SQL.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
>From 28c9b7acad605197a8a242ff929bcce6f3100c91 Mon Sep 17
On Wed, Dec 30, 2020 at 05:27:04PM +0100, Daniel Verite wrote:
> David Fetter wrote:
>
> +Datum
> +byteapopcount(PG_FUNCTION_ARGS)
> +{
> + bytea *t1 = PG_GETARG_BYTEA_PP(0);
> + int len, result;
> +
> + len = VARSIZE_ANY_EXHDR(t1);
&
change at runtime) some kind of
cryptographic policy, as SSH and TLS do. While I see this as a worthy
goal, it's a much bigger lift than an optional argument or two to
initdb, and requires a lot more discussion than it's had to date.
Best,
David.
--
David Fetter http://fetter.org/
Pho
On Wed, Dec 30, 2020 at 08:24:06PM +0100, David Fetter wrote:
> On Mon, Sep 07, 2020 at 11:57:58AM +0900, Michael Paquier wrote:
> > On Thu, Jul 02, 2020 at 04:02:21PM +0200, Daniel Gustafsson wrote:
> > > The CF Patch Tester consider this patch to be malformed and is unab
On Wed, Dec 30, 2020 at 09:32:26PM +0200, Krasiyan Andreev wrote:
> Hi, after latest committed patches about multirange datatypes, I get a
> compilation error,
Oh, right. I'd been meaning to send a patch to fix that. Here it is.
Best,
David.
--
David Fetter http://fetter.org/
Phone:
On Wed, Dec 30, 2020 at 03:00:17PM -0500, Tom Lane wrote:
> David Fetter writes:
> > On Wed, Dec 30, 2020 at 08:24:06PM +0100, David Fetter wrote:
> >> On Mon, Sep 07, 2020 at 11:57:58AM +0900, Michael Paquier wrote:
> >>> I have looked at the patch of this th
Please find attached :)
This could probably use a lot of filling in, but having it in the
actual documentation beats needing to know folklore even to know
that the capability is there.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating
to make it possible
to parallelize dumps of large tables by working separately on each
underlying file, of which there could be quite a few for a large one.
Will try to understand the suggestions upthread better and implement
same.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 23
s
step = (target > 0) - (target < 0);
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
he new
> names are a bit more aligned to the existing names.
Thanks! I'm looking forward to making use of this :)
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
n now and
the end of the CF to review the patch, work on it, etc, and the CF bot
will be testing it against the changing code base to ensure people
know if such a change causes it to need a rebase.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
> + -e class="parameter">pattern
> + --extension= class="parameter">pattern
> +
> +
> +Dump only extensions matching +class="parameter">pattern. When this option is not
> +specified, all non-system extensions in the target database will be
> +dumped. Multiple schemas can be selected by writing multiple
I think this should read "Multiple extensions".
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
YY') - to_timestamp('1752', '');
?column?
══
366 days
(1 row)
I'd like to imagine nobody will ever go mucking with the calendar to
the extent the British did that year, but one never knows.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
t serve requests from the parts that execute
queries also goes a long way toward things we've wanted for quite
awhile like admission control systems and/or seamless zero-downtime
upgrades.
Separately, as the folks at AWS and elsewhere have mentioned, being
able to pretend at some level to be a
e a little too cute and not easy ever to extend.
Come to that, would a row structure that looked like
(match, start, end)
be useful?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
ect that that process will expose
bits of the planning and execution machinery that have gotten less
isolated than they should be.
More generally, and I'll start a separate thread on this, we should be
working up to including a reference implementation, however tiny, of
every extension point we
ould documenting these APIs be the right place to start?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
uous ORDER BY, as illustrated
below?
SELECT BIT_XOR(b ORDER BY a, c).../* works */
SELECT BIT_XOR(b) OVER (ORDER BY a, c)... /* works */
SELECT BIT_XOR(b) FROM... /* errors out */
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
On Sat, Mar 06, 2021 at 08:57:46PM +0100, Vik Fearing wrote:
> On 3/6/21 8:55 PM, David Fetter wrote:
> > On Wed, Mar 03, 2021 at 03:30:15PM +0100, Peter Eisentraut wrote:
> >> On 10.02.21 06:42, Kyotaro Horiguchi wrote:
> >>> We already had CREATE AGGREATE
On Sat, Mar 06, 2021 at 09:03:25PM +0100, Vik Fearing wrote:
> On 3/6/21 9:00 PM, David Fetter wrote:
> > On Sat, Mar 06, 2021 at 08:57:46PM +0100, Vik Fearing wrote:
> >> On 3/6/21 8:55 PM, David Fetter wrote:
> >>> On Wed, Mar 03, 2021 at 03:30:15PM +0100, Pet
On Fri, Feb 12, 2021 at 08:02:51PM +0300, Anastasia Lubennikova wrote:
> On 17.01.2021 16:53, Magnus Hagander wrote:
> > On Fri, Jan 15, 2021 at 8:28 AM Peter Eisentraut
> > wrote:
> > > On 2020-12-31 04:28, David Fetter wrote:
> > > > This could probably use a
t; All catalogs with _aclitem columns have been included in the view.
>
> I think a similar one for ownerships would be nice too.
> But I'll let you digest this one first to see if the concept is fruitful.
+1 for both this and the ownerships view.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
s them to drift
> > away from matching the code, which makes the hook documentation actually
> > worse than having no hook documentation at all.
>
> There's doesn't seem to be agreement on how to proceed here, so closing.
>
> David, if you do decide to proceed with a READM
but it's also due to the API design.
>
> You worried about other FDWs than postgres_fdw. That's reasonable. I
> insisted in other threads that PG developers care only about postgres_fdw,
> not other FDWs, when designing the FDW interface, but I myself made the same
>
On Mon, Jan 11, 2021 at 03:50:54PM +0100, Peter Eisentraut wrote:
> On 2020-12-30 17:41, David Fetter wrote:
> > > The input may have more than 2 billion bits set to 1. The biggest possible
> > > result should be 8 billion for bytea (1 GB with all bits set to 1).
> > &
s broadly more
dangerous and ill-advised.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
aggregates, such as var_pop().
>
> Perhaps something along the lines of count_ones() or count_set_bits()
> would be more apropos.
Done that way.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.or
y
function comments which leave it up in the air as to which positional
argument does what in functions like string_to_array, which take
multiple arguments. I'll try to get a patch in for the next CF with a
fix for that, and a separate one that doesn't put it on people to use
\df+ to find t
ars before repositories have
converted over.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
!
The way it's already produced results is impressive.
Looking at honggfuzz, I see it's been used for wire protocols, of
which we have several. Does testing our wire protocols seem like a
big lift?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Co
I have now read the entire internet on what a suitable name for this
> function could be. I think the emerging winner is BIT_COUNT(), which
> already exists in MySQL, and also in Python (int.bit_count()) and Java
> (Integer.bitCount()).
Thanks for doing this tedious work. Please find attache
On Tue, Mar 23, 2021 at 10:51:08AM +0100, Peter Eisentraut wrote:
> On 21.03.21 02:31, David Fetter wrote:
> > > I have now read the entire internet on what a suitable name for this
> > > function could be. I think the emerging winner is BIT_COUNT(), which
> > > alr
.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
RE, or whether we
should care about anything it happens to say that gets in the way of
doing something more helpful.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
conversation and gets a few
> people excited about the idea the way I am. Maybe even some of the
> GSoC students would take the implementation further?
The conversation has started.
Again, welcome, and thanks for jumping in!
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235
.
Sorry to bother you again, but this now doesn't compile atop master.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
of replacing our current FDW-based push approach. If truncate is ever
> replicated, it would be really nice to be able to specify not to replicate
> it on the subscription level.
Do you have some kind of API in mind for describing subscriptions?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
m deforming of many tuples in parallel, which ids
> especially efficient at quantum computers.
>
> Attach please find patch with first prototype implementation. It provides
> about 3.14 times improvement of performance at most of TPC-H queries.
You're sure it's not 3.1415926
le logs. We
already have human-eye-consumable logs by default. What we don't
have, and increasingly do want, is a log format that's really easy on
machines.
As to logfmt in particular, the fact that it's not standardized is
probably a show-stopper.
Let's go with JSON.
Best,
D
On Sat, Apr 14, 2018 at 11:51:17AM -0400, Tom Lane wrote:
> David Fetter writes:
> > I think a suite of json_to_* utilities would be a good bit more
> > helpful in this regard than changing our human-eye-consumable
> > logs. We already have human-eye-consumable logs by defaul
On Sat, Apr 14, 2018 at 01:20:16PM -0700, Andres Freund wrote:
> On 2018-04-14 18:05:18 +0200, David Fetter wrote:
> > On Sat, Apr 14, 2018 at 11:51:17AM -0400, Tom Lane wrote:
> > > David Fetter writes:
> > > > I think a suite of json_to_* utilities would be a go
places I've worked, the end destination is of less
concern immediate than the ability to process those logs for
near-real-time monitoring. This is where formats like JSON really
shine.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
st,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
rogram
should need to be run from any particular spot. It can detect where it
is and act on that information.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
ames more uniform" is going
> to be a very satisfactory excuse for breakage.
What do you rate the chances that someone created a foo_in when
there's already a built-in fooin? If it's low enough, we could add
all the foo_ins as aliases to fooins and then mandate that new ones be
cal
On Tue, Sep 03, 2019 at 03:56:28PM -0400, Stephen Frost wrote:
> Greetings,
>
> * David Fetter (da...@fetter.org) wrote:
> > I'd like to $Subject, on by default, with a switch to turn it off for
> > those really at the outer edges of performance. Some reasons include:
On Tue, Sep 03, 2019 at 07:41:00PM -0400, Stephen Frost wrote:
> Greetings,
>
> On Tue, Sep 3, 2019 at 19:38 David Fetter wrote:
>
> > On Tue, Sep 03, 2019 at 03:56:28PM -0400, Stephen Frost wrote:
> > > Greetings,
> > >
> > > * David Fetter
o would
> be really sad if we removed or broke APIs they need for it once
> pg_stat_statements is part of core?
Nowhere near the number of people who are inconvenienced, at a
minimum, by the high barriers needed in order to install and use it in
its current form.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
sible to change the field used.
This all sounds interesting. Do you have a concrete proposal as to
how such a new interface would look in operation? Better yet, a PoC
patch implementing same?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donat
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
>From 6e8136ece5b01ca9cd16bdb974c4d54e939c92cf Mon Sep 17 00:00:00 2001
From: David Fetter
Date: Tue, 10 Sep 2019 02:06:31 -0700
Subject: [PATC
On Sun, Sep 15, 2019 at 02:06:29PM +0500, Andrey Borodin wrote:
> > 15 сент. 2019 г., в 12:18, David Fetter написал(а):
> >
> > Please find attached a couple of patches intended to $subject.
> >
> > This patch set cut the time to copy ten million rows of randomly s
wiki/Submitting_a_Patch
https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F
http://www.interdb.jp/pg/
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
On Sun, Sep 15, 2019 at 09:18:49AM +0200, David Fetter wrote:
> Folks,
>
> Please find attached a couple of patches intended to $subject.
>
> This patch set cut the time to copy ten million rows of randomly sized
> int8s (10 of them) by about a third, so at least for that c
On Tue, Sep 17, 2019 at 08:55:05AM +0200, David Fetter wrote:
> On Sun, Sep 15, 2019 at 09:18:49AM +0200, David Fetter wrote:
> > Folks,
> >
> > Please find attached a couple of patches intended to $subject.
> >
> > This patch set cut the time to copy ten million
On Tue, Sep 17, 2019 at 09:01:57AM +0200, David Fetter wrote:
> On Tue, Sep 17, 2019 at 08:55:05AM +0200, David Fetter wrote:
> > On Sun, Sep 15, 2019 at 09:18:49AM +0200, David Fetter wrote:
> > > Folks,
> > >
> > > Please find attached a couple of patches int
On Wed, Sep 18, 2019 at 05:42:01AM +0200, David Fetter wrote:
> On Tue, Sep 17, 2019 at 09:01:57AM +0200, David Fetter wrote:
> > On Tue, Sep 17, 2019 at 08:55:05AM +0200, David Fetter wrote:
> > > On Sun, Sep 15, 2019 at 09:18:49AM +0200, David Fetter wrote:
> > > >
On Wed, Sep 18, 2019 at 07:51:42AM +0200, David Fetter wrote:
> On Wed, Sep 18, 2019 at 05:42:01AM +0200, David Fetter wrote:
> > On Tue, Sep 17, 2019 at 09:01:57AM +0200, David Fetter wrote:
> > > On Tue, Sep 17, 2019 at 08:55:05AM +0200, David Fetter wrote:
> > > >
On Wed, Sep 18, 2019 at 04:27:46PM +0900, Kyotaro Horiguchi wrote:
> Hello.
>
> At Wed, 18 Sep 2019 05:42:01 +0200, David Fetter wrote in
> <20190918034201.gx31...@fetter.org>
> > On Tue, Sep 17, 2019 at 09:01:57AM +0200, David Fetter wrote:
> > > On Tue, Sep 17
On Fri, Sep 20, 2019 at 09:14:51PM +0200, David Fetter wrote:
> On Wed, Sep 18, 2019 at 04:27:46PM +0900, Kyotaro Horiguchi wrote:
> > Hello.
> >
> > At Wed, 18 Sep 2019 05:42:01 +0200, David Fetter wrote
> > in <20190918034201.gx31...@fetter.org>
> > >
On Fri, Sep 20, 2019 at 11:09:16PM +0200, David Fetter wrote:
> On Fri, Sep 20, 2019 at 09:14:51PM +0200, David Fetter wrote:
> > On Wed, Sep 18, 2019 at 04:27:46PM +0900, Kyotaro Horiguchi wrote:
> > > Hello.
> > >
> > > At Wed, 18 Sep 2019 05:42:01
On Sat, Sep 21, 2019 at 03:36:21AM +0100, Andrew Gierth wrote:
> >>>>> "David" == David Fetter writes:
>
> David> + /* Compute the result string. */
> David> + if (value >= 1)
> David> + {
> David> +
y emitting a trailing . for all floats), I
> >also found it to be clearer this way - Value nodes are otherwise
> >undistinguishable from raw strings, raw numbers etc, which is not
> >great.
> >
> > It'd also be easier to now just change the node format
On Sat, Sep 21, 2019 at 07:29:25AM +0100, Andrew Gierth wrote:
> >>>>> "David" == David Fetter writes:
>
> David> +static inline uint32
> David> +decimalLength64(const uint64_t v)
>
> Should be uint64, not uint64_t.
Fixed.
> Also return an
On Mon, Sep 23, 2019 at 10:28:09AM +0200, Tels wrote:
> Moin,
>
> On 2019-09-22 23:58, David Fetter wrote:
> > On Sat, Sep 21, 2019 at 07:29:25AM +0100, Andrew Gierth wrote:
> > > >>>>> "David" == David Fetter writes:
>
> > Fixed.
>
On Mon, Sep 23, 2019 at 01:16:36PM +0100, Andrew Gierth wrote:
> >>>>> "David" == David Fetter writes:
>
> David> + return pg_ltostr_zeropad(str, (uint32)0 - (uint32)value, minwidth -
> 1);
>
> No, this is just reintroducing the undefined behavior
On Mon, Sep 23, 2019 at 11:35:07PM +0200, David Fetter wrote:
> On Mon, Sep 23, 2019 at 01:16:36PM +0100, Andrew Gierth wrote:
Per discussion on IRC, change some functions to take only unsigned
integer types so as not to branch for the case of negative numbers
they're never actually cal
On Tue, Sep 24, 2019 at 06:30:18AM +0200, David Fetter wrote:
> On Mon, Sep 23, 2019 at 11:35:07PM +0200, David Fetter wrote:
> > On Mon, Sep 23, 2019 at 01:16:36PM +0100, Andrew Gierth wrote:
>
> Per discussion on IRC, change some functions to take only unsigned
> integer
>
> And with that, I've closed the commitfest. I know there's still
> technically a few hours left ... but if anyone wants to commit one more
> patch, they can mark it committed in the next commitfest without
> remorse.
>
> Thanks everyone,
Thanks for doing all t
tabases to be completely independent of other
> > databases in terms of key storage and usage.
>
> Wait, we're going to store the encryption keys with the database?
Encryption keys are fine there so long as decryption keys are
separate.
Best,
David.
--
David Fetter http://fetter.or
cation target any way they need to, but this patch
> doesn't implement that.
With this patch, is it possible to remove a partition manually from a
subscription, or will it just get automatically re-added at some
point?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
ator sounds like a great
idea. Let the name bike-shedding begin!
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
l = psprintf("https://www.postgresql.org/docs/%s/%s.html";,
(strstr(PG_VERSION, "devel") || strstr(PG_VERSION, "beta") ||
strstr(PG_VERSION, "alpha")) : "devel" : PG_MAJORVERSION,
QL_HELP[i].docbook_id);
Best,
David
On Sun, Mar 03, 2019 at 09:57:25PM +0100, Magnus Hagander wrote:
> On Sun, Mar 3, 2019 at 7:14 PM David Fetter wrote:
>
> > On Wed, Feb 27, 2019 at 09:14:59AM +0100, Peter Eisentraut wrote:
> > > + url = psprintf("
> > ht
cs/psql_version/
> else if (psql_version ends with 'devel')
> return /docs/devel/
> else
> return /docs/{psql_version but with text stripped}/
>
> So that e.g. 12beta would return "12", as would 12rc or 12alpha. But
> 12devel would return "devel".
That's exactly what I had in mind :)
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
On Fri, Mar 08, 2019 at 01:45:03PM +0100, Peter Eisentraut wrote:
> On 2019-03-07 23:02, David Fetter wrote:
> >> if (psql_version_is_numeric)
> >> return /docs/psql_version/
> >> else if (psql_version ends with 'devel')
> >> return /docs/devel
confusing as
> > the blocks_done does not correspond to the tuples_done in the final btree
> > sort & load phase.
>
> Good point. Done in the attached version, wherein I also added comments
> to explain the IndexBuildHeapScan API change. I didn't change the hash
> AM implementation here.
Would it be a very large lift to report progress for the rest of the
index types we support?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
also. Attached is a patch to
> implement that.
This is great!
Is this optimization doable for multi-row INSERTs, either with tuples
spelled out in the body of the query or in constructs like INSERT ...
SELECT ...?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
nts, notes?
Whatever optimizations you have in mind for this, could they also work
for string_to_array() and array_to_string() when they get an empty
string handed to them?
As to naming, some languages use explode/implode.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remem
ld be much more fun if
there were comments on these functions explaining things. I'll draft
up a patch for some of that.
In a similar vein, I haven't been able to come up with hazards of
naming function parameters in some document-ish way. What did I miss?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
ot; and we should deprecate this misfeature.
It's bad enough that we'll be supporting it for five years after
deprecating it, but it's worse to leave it hanging around our necks
forever. https://en.wikipedia.org/wiki/Albatross_(metaphor)
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
On Tue, Mar 19, 2019 at 01:59:34PM -0300, Alvaro Herrera wrote:
> On 2019-Mar-19, Andres Freund wrote:
>
> > Hi,
> >
> > On 2019-03-19 12:51:39 -0400, Tom Lane wrote:
> > > David Fetter writes:
> > > > I think the answer is "no," and we sh
le will be doing (the equivalent of)
this as the vulnerabilities inherent in isolation levels lower than
SERIALIZABLE become better known.
https://www.cockroachlabs.com/blog/acid-rain/
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
uld fail with a HINT to set the
wal_level ahead of time.
Possibly in a separate patch, setting the wal_level to anything lower
than logical when publications exist should also fail.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to
On Sun, Mar 24, 2019 at 02:06:59PM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Thu, Mar 21, 2019 at 07:45:59PM -0300, Lucas Viecelli wrote:
> >> I am sending a patch that when an PUBLICATION is created and the
> >> wal_level is different from logical prin
,
>or they have to go through libpq, which quite sensibly doesn't expose
>all the details to the outside. IMO it'd be really nice if we had a
>way to to write low level protocol tests, especially for testing
>things like the v2 protocol.
That sounds wort
osed to do. Would you be so kind as to include those in
the next revision of the patch? You can just attach the patch(es)
without zipping them.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
.
Feature freeze was April 8, so no.
https://www.mail-archive.com/pgsql-hackers@lists.postgresql.org/msg37059.html
You're in plenty of time for 13, though!
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://w
he method used in the patch is acceptable or not, but any
> suggestions are appreciated. I will add tests and other related things to
> the patch if the method used in this patch is acceptable.
I tried adding documentation based on what I could infer about the
behavior of this patch. Is that documenta
On Sat, Aug 03, 2019 at 05:56:04PM +0200, David Fetter wrote:
> On Tue, Jul 30, 2019 at 02:43:05PM -0700, 毛瑞嘉 wrote:
> > Hi,
> >
> >
> > I wrote a patch for adding CORRESPONDING/CORRESPONDING BY to set operation.
> > It is a task in the todo list. This is how
ld just accept the facts on the ground, which are that
> > some tools modify pg.auto.conf by appending to it
>
> +1. It's just a text file...
So are crontab and /etc/passwd, but there are gizmos that help make it
difficult for people to write complete gobbledygook to those. Does it
make sense to discuss tooling of that type?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
nces
> would it be sensible to not create a full set of partitions? Should
> we just enforce that there is a full set, somehow?
+1 for requiring that hash partitions not have gaps, ideally by making
one call create all the partitions.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
ery unlikely that a fix like
> this will be back-patched. Also, if this becomes an issue only for
> more than over 1000 partitions, then it's not very relevant for PG 10
> and PG 11, because we don't recommend using so many partitions with
> them. Maybe we can consider fixing
1 - 100 of 458 matches
Mail list logo
