Hi,
I'd like to propose $subject, as embodied in the attached patch. This
makes it possible to discover and fulfill a need for logical
replication that can arise at a time when bouncing the server has
become impractical, i.e. when there is already high demand on it.
Best,
David.
--
David F
bigger change though, but perhaps it is now possible once
> we have the "global barriers" in 13?
As much as I would love to have this capability, I was hoping to keep
the scope of this contained. As pointed out down-thread, there's lots
more to doing this dynamically that just tu
with_token() function definition so it would be always
> available, which is used to remove the @tokens@ in case user does
> not specify a default auth method for the new hostssl, hostgss
> options. I think you should also remove the "#ifndef
> HAVE_UNIX_SOCKETS" around it
gt; (committed, etc.) at the beginning of the CF has been moved to an
> > uncompleted state. Or perhaps my math is just bad.
> >
> > The RMT has determined that the CF will be extended for one week so I'll
> > hold off on moving and marking patches until Apri
On Mon, Apr 27, 2020 at 12:52:48PM -0400, Jonah H. Harris wrote:
> Hey, everyone.
> If there's any interest, I'll clean-up their patch and submit. Thoughts?
Where's the current patch?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vo
On Mon, Apr 27, 2020 at 10:44:04PM -0400, Jonah H. Harris wrote:
> On Mon, Apr 27, 2020 at 10:32 PM David Fetter wrote:
> > On Mon, Apr 27, 2020 at 12:52:48PM -0400, Jonah H. Harris wrote:
> > > Hey, everyone.
> >
> > > If there's any interest, I'l
he
> feature deprecation in (at least) the CREATE OPERATOR man page, and
> we'd have to decide how many release cycles the deprecation notices
> need to stand for.
>
> If that's the intention, though, it'd be good to get those deprecation
> notices published in
; It looks like those bits should reliably be zero right now.
+1 for adding +/- infinity to NUMERIC.
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
pg_restore -L <(pg_dump -l /path/to/dumpfile | grep -f /path/to/listfile)
-d new_db /path/to/dumpfile
That's a lot of shell magic and obscure corners of commands to expect
people to use.
Would it make sense to expand this patch to handle other objects?
Best,
David.
--
David Fetter h
re
> > creep disaster.
>
> How about changing the default behavior, making BUFFERS enabled by
> default? Those who don't need it, always can say BUFFERS OFF — the
> say as for TIMING.
+1 for changing the default of BUFFERS to ON.
Best,
David.
--
David Fetter http://fet
ould be a foot cannon) by
default. For those few to whom it really matters, there'd be OFF
switches.
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
rns over availability of oids, but simply from the fact
> that we have no business whatsoever inserting ourselves into the
> extension development process in this way.
+1 for keeping our nose out of this business.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Rem
wball/libstemmer tsearch \
> > tsearch/dicts utils port port/atomics port/win32 port/win32_msvc \
>
> Seems like a good idea. I think we ought to backpatch that to 11? Will
> do tomorrow if nobody protests.
+1 for back-patching
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
abling crosstabs.
https://www.iso.org/standard/69776.html
If we're going to put work into crosstabs, it seems to me that the
"we" needs to be the project as a whole, and the work should be, to
the extent reasonable, toward standard compliance.
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, Jan 25, 2019 at 04:31:00PM -0600, Merlin Moncure wrote:
> On Fri, Jan 25, 2019 at 3:16 PM David Fetter wrote:
> >
> > On Fri, Jan 25, 2019 at 02:21:55PM -0600, Merlin Moncure wrote:
> > > Hackers,
> > >
> > > We have a strong need to make a varia
ommon states next to each other rather than scattered around the
> array?
Do we have a pretty good idea of what commonly grouped states are, or
at least a way to get some not-awful estimates of what they are?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to
On Fri, Jan 25, 2019 at 06:55:56PM -0500, Bruce Momjian wrote:
> On Sat, Jan 26, 2019 at 12:49:50AM +0100, David Fetter wrote:
> > On Fri, Jan 25, 2019 at 05:38:59PM -0500, Bruce Momjian wrote:
> > > With our scanner keywords list now more cache-aware, and with us
> > >
27;s not get hung up on the syntax details.
>
> I propose that we implement and document this as
>
> WITH ctename AS [ MATERIALIZE { ON | OFF } ] ( query )
I think this would be better with parentheses like this:
WITH ctename [ ( MATERIALIZE { ON | OFF } ) ] AS ( query ) [, ...
OO="arbitrary text".
>
> In that case I propose that we avoid the whole issue by removing
> -Wdeclaration-after-statement entirely.
>
> So far, expressed opinions have run about 4:2 in favour of allowing
> mixed declarations and code.
+1 for 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
> at least one non-whitespace character, but from what I can see these
> don't really improve the readability.
Are you talking about \w+, or [^[:space:]]+, [^[:blank:]]+, or...?
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
> @ARGV;
> - }
> - else
> - {
> - usage();
> - }
> -}
> +GetOptions(
> + 'output:s'=> \$output_path,
> + 'include:s' => \$include_path) || usage();
>
> # Make sure output_path ends in a slash.
> if ($output_path ne '' && substr($output_path, -1) ne '/')
> @@ -52,7 +34,7 @@ if ($output_path ne '' && substr($output_path, -1) ne '/')
> }
>
> # Sanity check arguments.
And here:
> -die "No input files.\n" if !@input_files;
> +die "No input files.\n" if !@ARGV;
> die "No include path; you must specify -I.\n" if !$include_path;
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 be
to build a proof of concept?
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
docs.
> (What exactly is the point of having zipfian at all?)
Taking a statistical perspective, Zipfian distributions violate some
assumptions we make by assuming uniform distributions. This matters
because Zipf-distributed data sets are quite common in real life.
Best,
David.
--
David Fetter
On Sun, Feb 17, 2019 at 11:02:37PM +0100, Tomas Vondra wrote:
> On 2/17/19 6:33 PM, David Fetter wrote:
> > On Sun, Feb 17, 2019 at 11:09:27AM -0500, Tom Lane wrote:
> >> Fabien COELHO writes:
> >>>> I'm trying to use random_zipfian() for benchmarking of sk
On Thu, Feb 21, 2019 at 04:04:41PM -0500, Tom Lane wrote:
> I still say we should reject this and invent array_greatest/array_least
> functions instead.
Might other array_* functions of this type be in scope for this patch?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 23
kout from immediately
after branching will be *very* different from one just before the
release. The way I've come up with to clear this up is *way* too
expensive: lazily create doc builds for each SHA1 requested. Pointing
people at the latest devel docs is less confusing than pointing them
On Fri, Nov 30, 2018 at 04:55:30PM -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-11-30 19:53:18 +0100, David Fetter wrote:
> >> This makes it much simpler for computers to use the logs while not
> >> making it excessively difficult for humans to use the
hout other changes?
Would rotating daily and keeping a week's worth be reasonable as
defaults? If not, what do you have 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 Mon, Dec 03, 2018 at 07:18:31PM +0100, Gilles Darold wrote:
> Le 30/11/2018 à 19:53, David Fetter a écrit :
> > This makes it much simpler for computers to use the logs while not
> > making it excessively difficult for humans to use them.
>
> I'm also not very comfort
ve cases where we should be measuring performance dips?
Also, is there something about about indexes involved in this query
or WITH RECURSIVE itself that's pessimizing performance, generally?
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
ead, it repeats
that query in an infinite loop.
There's a bit of a philosophical issue here, or a mathematical one,
whichever way you want to put it. Does it actually make sense to have
the behavior of one "semicolon" spill onto another?
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 Thu, Dec 06, 2018 at 05:01:26AM -0300, Alvaro Herrera wrote:
> On 2018-Dec-06, David Fetter wrote:
>
> > There's a bit of a philosophical issue here, or a mathematical one,
> > whichever way you want to put it. Does it actually make sense to have
> > the behavior
ewrite its syntax to support the
> > > new option.
> >
> > We were just busy shooting down a different suggestion of
> > behavior-changing GUCs. A GUC that turns all ALTERs into no-ops
> > sure seems like a foot-gun to me.
>
> Yeah, I like EXPLAIN better.
> -g option shows in help message. (perhaps arguable.)
>
> I'm not sure that this should be a run-time option.
Given the often onerous givens of installing new software on
production machines, I'm thinking it actually should be.
> But we surely don't want to use up a
On Fri, Dec 14, 2018 at 12:23:17AM -0500, Tom Lane wrote:
> David Fetter writes:
> > On Thu, Dec 13, 2018 at 07:43:52PM +0100, Peter Eisentraut wrote:
> >> I'm not sure that this should be a run-time option.
>
> > Given the often onerous givens of installin
On Mon, Dec 17, 2018 at 05:31:22PM -0500, Tom Lane wrote:
> David Fetter writes:
> > Please find attached a run of a tool that looks for duplicated
> > tokens. I've removed some things that seem like false positives,
> > basically all from the stemmer part of the sourc
er/index.php?/archives/63-Kick-em-out,-and-keep-em-out!.html
so there appears to be interest in such a feature.
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
ns, allows them
the
ability to read any file on the server which the database can read and
that those reads bypass all in-database privilege checks.
Is there a useful distinction to be drawn between the files readable
by the system user who owns the database and those the database itself
ca
for "non-overwriting storage
> management", but that's a mouthful and acronyms based on
> "non-overwriting" don't seem great ("noheap" seems a bit silly. Maybe
> "nowheap" is better? How about "nosheap"?)
>
> Maybe we ca
On Sat, Dec 22, 2018 at 07:03:32AM +1100, Thomas Munro wrote:
> On Sat, Dec 22, 2018 at 5:56 AM David Fetter wrote:
> >
> > Folks,
> >
> > I'm trying to compile master (c952eae52a33069e2e92d34f217b43d0eca3d7de)
> > on Termux, using the supplied settings, as
On Fri, Dec 21, 2018 at 04:24:20PM -0500, Andrew Dunstan wrote:
> On 12/21/18 4:04 PM, Thomas Munro wrote:
> > On Sat, Dec 22, 2018 at 7:32 AM David Fetter wrote:
> >> On Sat, Dec 22, 2018 at 07:03:32AM +1100, Thomas Munro wrote:
> >>> That talks about using -D__A
th TRUNCATE and INSERT triggers).
Would it make more sense to fill in the missing implementations of NEW
and OLD for per-row triggers instead of adding another hack?
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 Mon, Dec 24, 2018 at 04:13:44PM -0800, Mitar wrote:
> Hi!
>
> Thanks for reply!
>
> On Mon, Dec 24, 2018 at 2:20 PM David Fetter wrote:
> > You've got the right mailing list, a description of what you want, and
> > a PoC patch. You also got the
yacc was originally designed. Is LALR
actually suitable for languages like SQL, or is it just there for
historical reasons?
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
[much output elided]
Fortunately, this has been part of Perl core a lot further back than
we promise to support for builds, so I think we're clear to use it
everywhere we process options.
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 Wed, Jan 09, 2019 at 08:43:08PM -0500, Tom Lane wrote:
> I see somebody marked the CF as in-progress, but if anyone volunteered
> to be nagger-in-chief for this month, I didn't see that.
I'm happy to do it.
Would love to chat with recent prior CFMs, if they're willing.
B
ed on time.
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
If it is
> possible to get the CF closed more or less on time using this method
> that would be nice.
Consensus having been reached, I'll aim for 1/31 or 2/1 at the latest.
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
> materialization. If they specify neither, then we make some decision
> which we may change in a future release. If they do specify
> something, we do that.
When they're specifying it, are they specifying it globally, or
per WITH clause, or...?
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 Wed, Jan 15, 2020 at 03:45:12PM -0800, Jesse Zhang wrote:
> On Tue, Jan 14, 2020 at 2:09 PM David Fetter wrote:
> > > The changes in hash AM and SIMPLEHASH do look like a net positive
> > > improvement. My biggest cringe might be in pg_bitutils:
> > >
>
question one asks when one wants to get a positive response.
> I however do agree that we should strive to not introduce
> cryptographic code into the pg source tree - nobody here seems to
> have even close to enough experience to maintaining / writing that.
+1 for not turning ourselves into implementers of cryptographic
primitives.
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 major version in a year before, so we
have a track record of that actually happening.
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 patch attached?
> It's not just pedantry but rather based on a real-life example of someone
> reading and being not sure
> whether e.g. joins can be used in there.
Thanks for doing this!
Speaking of examples, there should be more of them illustrating some
of the cases you name
e still be available to front-end
code?
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, Feb 14, 2020 at 08:16:47AM -0800, Mark Dilger wrote:
> > On Feb 14, 2020, at 8:15 AM, David Fetter wrote:
> >
> > On Fri, Feb 14, 2020 at 10:33:04AM -0500, Robert Haas wrote:
> >> On Thu, Feb 13, 2020 at 11:26 AM Mark Dilger
> >> wrote:
> &g
ething similar that reduces the input alphabet efficiently), then
reserve bytes that denote delimiters of various types. ASCII has
separators for file, group, record, and unit that we could use as
inspiration.
I don't have anything to offer for free-form input other than to agree
that it looks like a hole with no bottom, and maybe we should just
keep that process serial, at least until someone finds a bottom.
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
ing is needed.
>
> I am talking about access to shared memory instead of the process
> local memory. I understand that an extra copy won't be required.
Isn't accessing shared memory from different pieces of execution what
threads were designed to do?
Best,
David.
--
David Fetter
://github.com/robertdavidgraham/wc2
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 Thu, Feb 20, 2020 at 02:36:02PM +0100, Tomas Vondra wrote:
> On Thu, Feb 20, 2020 at 04:11:39PM +0530, Amit Kapila wrote:
> > On Thu, Feb 20, 2020 at 5:12 AM David Fetter wrote:
> > >
> > > On Fri, Feb 14, 2020 at 01:41:54PM +0530, Amit Kapila wrote:
> > &g
s,
> it'll merge with all of the following blocks. You may think that
> nobody is doing this sort of thing, but I think people are, and that
> they will come after us with pitchforks if we break it.
I'm doing it, and I don't know about pitchforks, but I do know about
suddenly
On Mon, Feb 24, 2020 at 06:40:16PM +0100, Vik Fearing wrote:
> On 24/02/2020 18:37, David Fetter wrote:
>
> > If we'd done this from a clean sheet of paper, it would have been the
> > right decision. We're not there, and haven't been for decades.
>
> OT
ve also written tests and very basic documentation.
Please find attached an update that I believe fixes the bug I found in
a principled way.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/
On Fri, Jan 31, 2020 at 04:59:18PM +0100, David Fetter wrote:
> On Wed, Jan 15, 2020 at 03:45:12PM -0800, Jesse Zhang wrote:
> > On Tue, Jan 14, 2020 at 2:09 PM David Fetter wrote:
> > > > The changes in hash AM and SIMPLEHASH do look like a net positive
> > > &g
On Wed, Feb 26, 2020 at 06:38:57PM +0800, John Naylor wrote:
> On Wed, Feb 26, 2020 at 3:51 PM David Fetter wrote:
> >
> > I believe the following should error out, but doesn't.
> >
> > # SELECT date_trunc_interval('1 year 1 ms', TIMESTAMP '2001-
On Wed, Feb 26, 2020 at 09:12:24AM +0100, David Fetter wrote:
> On Fri, Jan 31, 2020 at 04:59:18PM +0100, David Fetter wrote:
> > On Wed, Jan 15, 2020 at 03:45:12PM -0800, Jesse Zhang wrote:
> > > On Tue, Jan 14, 2020 at 2:09 PM David Fetter wrote:
> > > > > The
On Thu, Feb 27, 2020 at 02:41:49PM +0800, John Naylor wrote:
> On Thu, Feb 27, 2020 at 1:56 PM David Fetter wrote:
> > [v6 set]
>
> Hi David,
>
> In 0002, the pg_bitutils functions have a test (input > 0), and the
> new callers ceil_log2_* and next_power_of_2
format. There is only one generic format for data - csv.
Not exactly. There's a lot of uses for things along the lines of
\gf json
\gf yaml
I'd rather add a new \gf that takes arguments, as it seems more
extensible. For example, there are uses for
\gf csv header
if no header is the
have a cardinality, and each range within would have a weight,
all of which would be an increasingly heavy burden on the common case
where there's just a single range.
Enhancing a separate multirange type to have weights seems like a
cleaner path forward.
Given that, I'm -1 on mushing multi-ranges into a special case of
ranges, or /vice versa/.
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 07, 2020 at 06:45:44PM -0500, Tom Lane wrote:
> David Fetter writes:
> > There's another use case not yet covered here that could make this
> > even more complex, we should probably plan for it: multi-ranges
> > with weights.
>
> I'm inclined to r
On Mon, Mar 02, 2020 at 12:45:21PM -0800, Jesse Zhang wrote:
> Hi David,
>
> On Wed, Feb 26, 2020 at 9:56 PM David Fetter wrote:
> >
> > On Wed, Feb 26, 2020 at 09:12:24AM +0100, David Fetter wrote:
> > > On Fri, Jan 31, 2020 at 04:59:18PM +0100, David Fetter wrote
types in binary: For
> > hard to discern reasons we a) embed type oids in them b) verify them. b)
> > won't ever work for non-builtin types, because oids are assigned
> > dynamically.
> >
>
> I figured arrays and UDT's would be problematic.
Would it mak
> > EXECUTE. Even EXECUTION might be better.
>
> The GQL draft uses PROFILE as a separate top-level command, so it would be
>
> PROFILE SELECT ...
>
> That seems nice and clear.
Are you proposing something along the lines of this?
PROFILE [statement]; /* Shows th
On Wed, Jun 19, 2019 at 02:08:21PM +0200, Daniel Gustafsson wrote:
> > On 19 Jun 2019, at 08:15, Peter Eisentraut
> > wrote:
> >
> > On 2019-06-18 23:15, David Fetter wrote:
> >> Are you proposing something along the lines of this?
> >>
&
e than 4x, and if
> that is not enough then we can ask whether raising max_connections is
> a reasonable workaround,
Is there perhaps a way to make raising max_connections not require a
restart? There are plenty of situations out there where restarts
aren't something that can be done on a wh
On Fri, Jun 21, 2019 at 05:20:54PM -0400, Alvaro Herrera wrote:
> On 2018-Jan-29, David Fetter wrote:
>
> > We could certainly have \d call DESCRIBE for later versions of the
> > server. \ commands which call different SQL depending on server
> > version have long
On Fri, Jun 21, 2019 at 05:49:43PM -0400, Alvaro Herrera wrote:
> On 2019-Jun-21, David Fetter wrote:
>
> > On Fri, Jun 21, 2019 at 05:20:54PM -0400, Alvaro Herrera wrote:
> > > On 2018-Jan-29, David Fetter wrote:
> > >
> > > > We could certainly have
out a consistent way of describing expectations and displaying results
This is a giant problem.
> * no tool was chosen
If there's a way to get this in the tree, assuming people agree it
should be there, that'd be fantastic.
Our current system has been creaking for years.
Best,
David.
On Tue, Jul 02, 2019 at 03:06:52PM +0100, Peter Eisentraut wrote:
> On 2019-05-18 19:39, David Fetter wrote:
> > On Wed, May 15, 2019 at 09:32:31AM -0400, Tom Lane wrote:
> >> David Fetter writes:
> >>> I hope the patch is a little easier to digest as now attached.
d the
way "unique" is used here, which is 3 distinct {a, b, c}, but only one
{a, b}.
Or I could be missing something obvious, and in that case, please
ignore.
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
columns is still unique.
Thanks for clarifying!
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
Folks,
Corey Huinker put together the documentation for this proposed
feature. Does this seem like a reasonable way to do it?
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
>F
ion of covering_range
and multi_range types covers all cases. To recap, covering_range_agg
assigns a weight, possibly 0, to each non-overlapping sub-range. A
cast from covering_range to multi_range would meld adjacent ranges
with non-zero weights into single ranges in O(N) (N sub-ranges) time
and som
On Fri, Jul 05, 2019 at 12:38:02PM -0400, Tom Lane wrote:
> I wrote:
> > David Fetter writes:
> >> [ v7-0001-Add-warn-to-psql.patch ]
>
> > I took a look at this. I have no quibble with the proposed feature,
> > and the implementation is certainly simple enoug
gt; - x <@ mr
> - r <@ mr
> - mr <@ mr
> - mr << mr (strictly left of)
> - mr >> mr (strictly right of)
> - mr &< mr (does not extend to the right of)
> - mr &> mr (does not extend to the left of)
> - inverse opera
On Tue, Jul 09, 2019 at 09:40:59AM -0700, Paul A Jungwirth wrote:
> On Tue, Jul 9, 2019 at 8:51 AM David Fetter wrote:
> > > - A multirange type is an extra thing you get when you define a range
> > > (just like how you get a tstzrange[]). Therefore
> > > - I d
gt;
> > Anyway, I fixed that. But now you really do need to rebase :-)
>
> Thanks for fixing and for the reminder! Here is the new rebased version. It
> contradicts a bit with 44982e7d09, because I'm actually using indexprSlice,
> but
> I guess we can figure this o
On Thu, Jul 11, 2019 at 04:30:46PM +0200, Dmitry Dolgov wrote:
> > On Thu, Jul 11, 2019 at 9:47 AM David Fetter wrote:
> >
> > Looks great!
> >
> > The tutorial piece has bit-rotted slightly. Please find attached a
> > patch atop yours that fixes it.
>
&
> over the Unix-domain socket to the same database user name as their
> operating system user names (on operating systems that support this,
> which are most modern Unix-like systems, but not Windows)
It turns out that really recent versions of Windows do have it.
https://bsmadhu.word
ould help meet people's expectations coming
from other RDBMSs.
On the other hand, making functions could just be done in SQL, which
might hurry the process along.
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
a KR
What precisely are you trying to do here, and how are you doing it?
Is the source published somewhere?
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
.
We went with a very liberal license from the outset for what we
believed were good reasons, and that's served us well over the
decades. If you're proposing a change of this magnitude, it's going
to have to be a lot more convincing than, "it would be convenient for
my company
On Sat, Jul 07, 2018 at 10:20:35AM -0700, Andres Freund wrote:
> Hi,
> On 2018-07-07 19:12:58 +0200, David Fetter wrote:
> > On Thu, Jul 05, 2018 at 01:15:15AM +, Tsunakawa, Takayuki wrote:
> > > I believe that accepting patented code from companies would be
> > &g
On Sat, Jul 07, 2018 at 11:05:48AM -0700, Andres Freund wrote:
> On 2018-07-07 19:37:45 +0200, David Fetter wrote:
> > On Sat, Jul 07, 2018 at 10:20:35AM -0700, Andres Freund wrote:
> > > Hi,
> > > On 2018-07-07 19:12:58 +0200, David Fetter wrote:
> > > > O
On Sat, Jul 07, 2018 at 12:01:10PM -0700, Andres Freund wrote:
> Hi,
>
> On 2018-07-07 20:51:56 +0200, David Fetter wrote:
> > As to "dual license," that's another legal thicket in which we've been
> > wise not to involve ourselves. "Dual licensin
On Mon, Jul 09, 2018 at 08:29:08AM +, Tsunakawa, Takayuki wrote:
> From: David Fetter [mailto:da...@fetter.org]
> > We went out of our way to excise code that the PostgreSQL license
> > doesn't cover some years back. I think that was done for good
> > reasons, which
ecause to is about how
to use PostgreSQL, not how to change PostgreSQL.
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
atures without listing them
> > individually in the release notes. I don't think randomly selecting one
> > relatively uncommonly used hook is a good way to attack that.
>
> Agreed. Ideally we would have a wiki page that lists _all_ the hooks,
> and what release they we
ce (off) and MS-SQL-compatible behavior (on).
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 a9ff5dbd9139c83bd6241765f74c3b637059e87b Mon Sep 17 00:00:00 2001
From: David Fet
"error" value is not documented.
>
> More generally, The value is said to be an enum, but the list of values is
> not listed anywhere in the documentation.
>
> ISTM that the doc would be clearer if for each of the four values of the
> parameter the behavior is spelled ou
or case-test results would be more useful than a parser
> check.
Am I understanding correctly that this would be looking for bogus
conditions in the plan tree?
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
301 - 400 of 460 matches
Mail list logo
