Thanks for sending this along!
Is there a public repo for this, in case people have patches they'd
like to contribute? If not, would you be so kind as to make one?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://w
ntent worth noticing.
OK
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
ng contains an
> "\echo :variable".
It no longer does.
> Also, the new entry should probably be between the \w &
> \watch entries instead of between \echo & \ef.
Moved.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consid
an input. I'm not sure it is worth a dedicated
> submission, could go together with any commit that would use it.
My hope is that this is seen as a bug fix and gets back-patched.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donatin
y I did not see it on the preceding submission.
Done.
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 c2cc57537124edac1a0ec5ae2d991d94529c8bc0 Mon Sep 17 00:00:00 2001
From: David Fe
ies
> in pg_class, and ISTM that they can be temporary/unlogged/permanent as
> attached to corresponding objects. So the guard is not very useful and it
> could make sense to show the information on indexes as well.
Done.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415
my @cmd = ('psql', split /\s+/, $opts);
> + my @cmd = ('psql', '-X', split /\s+/, $opts);
> $node->command_checks_all(\@cmd, $stat, $out, $err, $name, $in);
> return;
> }
Please find attached :)
Best,
David.
--
David Fetter http://fette
nk the cases above, or at least the first two of them, should be
available. They could be called range_agg, weighted_range_agg, and
covering_range_agg.
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, May 06, 2019 at 11:19:27AM -0700, Paul Jungwirth wrote:
> On 5/3/19 6:41 PM, David Fetter wrote:
> > This suggests two different ways to extend ranges over aggregation:
> > one which is a union of (in general) disjoint intervals, two others
> > are a union of intervals
On Tue, May 07, 2019 at 11:05:32AM +0900, Kyotaro HORIGUCHI wrote:
> Hi.
>
> At Sun, 28 Apr 2019 17:07:16 +0200, David Fetter wrote in
> <20190428150716.gp28...@fetter.org>
> > Our test coverage needs all the help it can get.
> >
> > This patch, extracted
Folks,
It can get a little tedious turning on (or off) all the boolean
options to EXPLAIN, so please find attached a shortcut.
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
On Tue, May 07, 2019 at 09:30:47AM +0200, David Fetter wrote:
> Folks,
>
> It can get a little tedious turning on (or off) all the boolean
> options to EXPLAIN, so please find attached a shortcut.
>
> Best,
> David.
It helps to have a working patch for this.
Best,
David.
-
>timing = defGetBoolean(opt);
>
> second es->timing should be es->summary, right?
You are correct! Sorry about the copy-paste-o.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: ht
On Tue, May 07, 2019 at 11:03:23AM +0200, Rafia Sabih wrote:
> On Tue, 7 May 2019 at 09:30, David Fetter wrote:
> >
> > Folks,
> >
> > It can get a little tedious turning on (or off) all the boolean
> > options to EXPLAIN, so please find attached a shortcut.
>
On Tue, May 07, 2019 at 08:41:47AM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-05-07 09:30:47 +0200, David Fetter wrote:
> > It can get a little tedious turning on (or off) all the boolean
> > options to EXPLAIN, so please find attached a shortcut.
>
> I'm n
On Tue, May 07, 2019 at 09:39:57AM -0400, Andrew Dunstan wrote:
>
> On 5/6/19 10:42 PM, David Fetter wrote:
> > On Tue, May 07, 2019 at 11:05:32AM +0900, Kyotaro HORIGUCHI wrote:
> >> Hi.
> >>
> >> At Sun, 28 Apr 2019 17:07:16 +0200, David Fetter wrote
>
On Tue, May 07, 2019 at 06:47:59PM +0200, David Fetter wrote:
> On Tue, May 07, 2019 at 09:39:57AM -0400, Andrew Dunstan wrote:
> >
> > On 5/6/19 10:42 PM, David Fetter wrote:
> > > On Tue, May 07, 2019 at 11:05:32AM +0900, Kyotaro HORIGUCHI wrote:
> > >> Hi.
On Tue, May 07, 2019 at 09:44:30AM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-05-07 18:34:11 +0200, David Fetter wrote:
> > On Tue, May 07, 2019 at 08:41:47AM -0700, Andres Freund wrote:
> > > On 2019-05-07 09:30:47 +0200, David Fetter wrote:
> > > > It can
same users's better without
qualification, and helps some positive fraction of our current users.
On a slightly related topic, we haven't, to date, made any promises
about what EXPLAIN will put out, but as we make more machine-readable
versions, we should at least think about its schema and versioning
of same.
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
ng, except
> for some footnote. Maybe we could call ANALYZE a "legacy spelling"
> of EXECUTE.
I tried changing it to EXEC (EXPLAIN EXECUTE is already a thing), but
got a giant flock of reduce-reduce conflicts along with a few
shift-reduce conflicts.
How do I fix this?
Best,
David.
--
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.
>
> To be blunt, I find 500K worth of changes in the regression test
> outputs to be absolutely unacceptable, especially when
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.
>
> To be blunt, I find 500K worth of changes in the regression test
> outputs to be absolutely unacceptable, especially when
etting
> ourselves up for years, possibly decades, worth of confusion. And
> without any real benefit.
>
> Defaulting BUFFERS to ON is probably a reasonable change, thuogh.
Would this be worth back-patching? I ask because adding it will cause
fairly large (if mechanical) churn in the regr
achadair/imath/pull/39
I noticed that it's gone from upstream. I also noticed that upstream
did a release in January since the previous pull. Is it worth trying
to merge those in as they arrive?
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
to:
- PostgreSQL consultancies
- Cloud providers
- Vendors of proprietary software based on or including 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
ch a
> > column. This can help distinguish which command is running and thus
> > which phases to expect. It seems reasonable to keep these views
> > consistent, too. (They are both new in PG12.) Patch attached.
>
> Seems like we should do that for v12 then?
+1
Best,
Da
here as well that David Rowley has joined the ranks of
> PostgreSQL committers.
>
> Congratulations to David, may the buildfarm be gentle to him, and his first
> revert far away!
Kudos, David!
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
CTEs, just as it doesn't affect statements with volatile
functions and recursive CTEs.
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, Jun 03, 2019 at 07:33:35PM -0400, Tom Lane wrote:
> David Fetter writes:
> > It might be worth documenting the fact that NOT MATERIALIZED doesn't
> > affect DML CTEs, just as it doesn't affect statements with volatile
> > functions and recursive CTEs.
>
a lot of time or other resources?
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, Oct 05, 2018 at 01:40:05AM +0100, Andrew Gierth wrote:
> >>>>> "Andreas" == Andreas Karlsson writes:
>
> > On 10/03/2018 05:57 PM, David Fetter wrote:
> >> Is there any meaningful distinction between "inlining," by which I
>
it'd be better
> to call attention to this in a new thread, to make sure people had a
> chance to object.
How much time would someone have to convert the timetravel piece of
contrib/spi to use non-deprecated time types in order to make this
window?
Best,
David.
--
David Fetter http:/
On Tue, Oct 09, 2018 at 12:31:19PM -0700, Andres Freund wrote:
> Hi,
>
> On 2018-10-09 21:26:31 +0200, David Fetter wrote:
> > On Tue, Oct 09, 2018 at 12:22:37PM -0700, Andres Freund wrote:
> > > In-Reply-To: <20180928223240.kgwc4czzzekrp...@alap3.anarazel.de>
> &
On Tue, Oct 09, 2018 at 01:43:48PM -0700, Andres Freund wrote:
>
>
> On October 9, 2018 1:40:34 PM PDT, David Fetter
> wrote:
> >On Tue, Oct 09, 2018 at 12:31:19PM -0700, Andres Freund wrote:
> >> Hi,
> >>
> >> On 2018-10-09 21:26:31 +0200, David Fe
master/plugin/cscope_maps.vim
Semantic Autocompletion: I've heard good things about YCM, but I haven't tried
it out yet.
http://valloric.github.io/YouCompleteMe/
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
der whether something JIT-like could elide this. A very
interesting subset of such WHEN clauses could be pretty
straight-forward to implement in a pretty efficient 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/donate
t we should prioritize performance optimizations for cases when
people haven't explicitly decided to trade performance for lower
information leak rates, which is to say for people who haven't put
those access controls on in the first place.
That's just my take, though. Another GUC to c
On Mon, Oct 22, 2018 at 04:43:52PM +0530, Dilip Kumar wrote:
> On Mon, Oct 22, 2018 at 11:22 AM David Fetter wrote:
> >
> > On Mon, Oct 22, 2018 at 11:10:09AM +0530, Dilip Kumar wrote:
> > > As part of the security fix
> > > (e2d4ef8de869c57e3bf270a30c12d48c
Folks,
Per gripes I've been hearing with increasing frequency, please find
attached a patch that implements $Subject. It's microsecond resolution
because at least at the moment, nanosecond resolution doesn't appear
to be helpful in this context.
Best,
David.
--
David Fetter ht
On Wed, Oct 24, 2018 at 08:00:24AM +1300, Thomas Munro wrote:
> On Wed, Oct 24, 2018 at 7:51 AM David Fetter wrote:
> > Per gripes I've been hearing with increasing frequency, please find
> > attached a patch that implements $Subject. It's microsecond resolution
> >
On Tue, Oct 23, 2018 at 04:14:50PM -0300, Alvaro Herrera wrote:
> On 2018-Oct-23, David Fetter wrote:
>
> > On Wed, Oct 24, 2018 at 08:00:24AM +1300, Thomas Munro wrote:
> > > On Wed, Oct 24, 2018 at 7:51 AM David Fetter wrote:
> > > > Per gripes I've
On Wed, Oct 24, 2018 at 08:46:47AM +0900, Michael Paquier wrote:
> On Wed, Oct 24, 2018 at 12:11:18AM +0200, David Fetter wrote:
> > That's an interesting point. pgbadger is the only one I recall using
> > that's still maintained. Which others would it be useful to
precated as of v11 for CREATE TRIGGER
> and CREATE EVENT TRIGGER. Wouldn't it be better to just complete
> with FUNCTION for a v11 or newer server? I think that we want to
> encourage users to use EXECUTE FUNCTION if possible.
+1 for not completing with syntax we've just deprecated.
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, Oct 24, 2018 at 11:10:02AM +0100, Tom Lane wrote:
> David Fetter writes:
> > On Wed, Oct 24, 2018 at 08:00:24AM +1300, Thomas Munro wrote:
> >> On Wed, Oct 24, 2018 at 7:51 AM David Fetter wrote:
> >>> Per gripes I've been hearing with increasing freq
On Wed, Oct 24, 2018 at 03:17:09PM +0100, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2018-Oct-24, David Fetter wrote:
> >> For another, having separate letter rather than number modifiers as
> >> printf("%03d") does, is just lousy API design.
>
> &
On Thu, Oct 25, 2018 at 01:00:08PM +1300, David Rowley wrote:
> On 25 October 2018 at 11:25, David Fetter wrote:
> > Digging a teensy bit deeper, I noticed that there's already a
> > "padding" (space padding, if I understand correctly) system for parts
> >
erver. So long as the
threads don't directly interact with the backend, you could do this
safely.
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, Oct 31, 2018 at 11:21:33PM +, Nasby, Jim wrote:
> On Oct 11, 2018, at 10:35 AM, David Fetter wrote:
> >
> >> It didn't get far, but you may want to take a look at a rejected patch for
> >> copy_srf() (set returning function)
> >> htt
llowing optimizations:
> - columns c and e are never referenced, and need never be turned into a
> datum (though we might do so just to confirm that they conform to the data
> type)
That sounds like something that could go inside the WITH extension
I'm proposing above.
[STRICT_
s like poor design to add grammar to support a
single client, so we'd need to think about this in terms of what we
want to support on the client side independent of specific clients. It
also seems like a violation of separation of concerns to couple FEBE
to grammar, so there'd need to be
going to want to write
> > code to convert jsonb's internal form into whatever their application
> > uses; particularly not dealing with numeric fields.
>
> I'm all for making jsonb_out() faster, but even a faster jsonb_out()
> isn't going to be faster than shoveli
t does so
> reading queries becomes just a little bit more difficult.
>
> Attached is a patch to create a function for it, based off 5953c99697.
+1
In a slightly related matter, at some point, we also need to come up
with a timestamptz2 or some such which preserves the input time zone.
Best,
D
eing no
> maximum than to think about the maximum being anything.
..and now, I'm finally beginning to see the reasoning that led Oracle
to conflate NULL and empty string.
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
15, assuming support for it in at least two common
compiler toolchains ;)
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, Nov 12, 2018 at 02:57:37PM -0800, Andres Freund wrote:
> Hi,
>
> On 2018-11-12 23:51:35 +0100, David Fetter wrote:
> > On Tue, Nov 13, 2018 at 11:01:33AM +1300, David Rowley wrote:
> > > On 13 November 2018 at 10:39, Thomas Munro
> > > wrote:
> >
Folks,
At least two external logical replication systems have simple ways to
change the node which is accepting rights for a replication set.
Please find attached a doc patch naming the lack of this feature as a
current limitation.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415
, too late.)
If we're on board with exposing pilot error, we could decide not to
implement the nonstandard WITH syntax. One type of pilot error this
would expose is a situation where:
- A UDF has side effects, but is declared IMMUTABLE
- A WITH clause calls it in order to get those side ef
pendencies there because the functions are black box for parser.
Some UDFs are not a black box for the parser, namely ones written in
SQL. Would it make sense at least not to foreclose the non-(black box)
option?
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
nge ends pg_upgrade support.
Are we really that attached to how we store things?
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
o print the context that the match looked
> at:
>
> 1414: "alt" -> "er "
> 1435: "alter " -> ""
> 1435: "alter t" -> "ab"
>
> etc.
>
> regards, tom lane
Is this something alo
d logs where setting the variable after the
> fact doesn't help.
>
> Please consider the attached patch, extension packagers will thank
> you.
>
> Christoph
+1 for pushing this. Regression diffs can get pretty noisy even with
it in place.
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
r maybe if I missed
> something.
>
> Patrick Francelle
I believe that features F671 (subqueries in CHECK constraints) and
possibly F673 (reads SQL-data routine invocations in CHECK
constraints) from the standard should be referred to here.
We haven't implemented either one of
ally the right thing.
On a busy server, because we don't yet have ways to carve off streams
of logs, these ones could get lost in the noise.
This brings up an interesting idea, though. It seems like we're
backing into a logging facility for psql with this feature. How about
just sen
On Mon, Nov 26, 2018 at 12:23:16PM +0900, Kyotaro HORIGUCHI wrote:
> Thank you for the comments.
>
> At Sun, 25 Nov 2018 01:17:27 +0100, David Fetter wrote in
> <20181125001727.gm...@fetter.org>
> > On Fri, Nov 23, 2018 at 04:32:31PM -0500, Tom Lane wrote:
> >
On Tue, Nov 27, 2018 at 06:06:06PM +0900, Kyotaro HORIGUCHI wrote:
> Hello.
>
> At Mon, 26 Nov 2018 07:08:53 +0100, David Fetter wrote in
> <20181126060853.gp...@fetter.org>
> > On Sun, Nov 25, 2018 at 11:21:51PM -0500, Tom Lane wrote:
> > > Kyotaro HORIGUCHI
On Tue, Nov 27, 2018 at 03:54:55PM -0500, Tom Lane wrote:
> David Fetter writes:
> > Do we still want this as a compile-time option, or does it make more
> > sense as a run-time option? I'm thinking that with \L, it might make
> > sense as a run-time option.
>
> T
way to specify.
I also noticed that in psql, \dRp+ doesn't show the WHERE clause,
which it probably should.
Does it need regression tests?
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, Mar 01, 2018 at 12:41:04PM -0300, Euler Taveira wrote:
> 2018-02-28 21:47 GMT-03:00 David Fetter :
> > I noticed that the WHERE clause applies to all tables in the
> > publication. Is that actually the right thing? I'm thinking of a
> > case where we have f
k format change in
> pg_upgrade for GPDB, I am not arguing against that. Not at all.
Your experience reflects one of the fundamental problems with those
systems. It wasn't a one-off.
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, Jan 15, 2018 at 09:14:02PM +, Joe Wildish wrote:
> Hi David,
>
> > On 15 Jan 2018, at 16:35, David Fetter wrote:
> >
> > It sounds reasonable enough that I'd like to make a couple of Modest
> > Proposals™, to wit:
> >
> > - We fo
This seems pretty specialized. If we're adding something new, how about
psql --format=csv -o foo.csv -c 'TABLE foo'
Or we could stick with:
psql -P format=csv -o foo.csv -c 'TABLE foo'
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 it's not clear how we'd make a sane default
that made choices among those correct for enough users.
For example, do we know that we want tuples_only behavior by default?
A lot of people's CSV tools assume a header row.
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, Mar 07, 2018 at 09:37:26PM +0100, Pavel Stehule wrote:
> 2018-03-07 21:31 GMT+01:00 Daniel Verite :
>
> > David Fetter wrote:
> >
> > > We have some inconsistency here in that fewer table formats are
> > > supported, but I think a
On Thu, Mar 08, 2018 at 09:11:58PM +, Joe Wildish wrote:
> Hi David,
>
> >
> > This patch no longer applies. Any chance of a rebase?
>
> Of course. I’ll look at it this weekend,
Much appreciate it!
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 23
es and a few other minor amendments.
Thanks!
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
oposed, complete
with concrete use cases that could really make PostgreSQL stand out.
That we don't have an obvious choice of "most correct" operation over
which to close ranges makes it even bigger a potential foot-gun
when we choose one arbitrarily and declare it to be
Folks,
I noticed that $subject completes with already valid constraints,
please find attached a patch that fixes it. I noticed that there are
other places constraints can be validated, but didn't check whether
similar bugs exist there yet.
Best,
David.
--
David Fetter http://fetter.org/
E TABLE
> eax=# alter table foo add constraint bar check (x < 3) not valid;
> ALTER TABLE
> eax=# alter table foo add constraint baz check (x <> 5) not valid;
> ALTER TABLE
> eax=# alter table foo validate constraint ba
> bar baz
> eax=# alter table foo validate constraint
est,
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 4202229a9319fa2f307b2761696775a2c5905fcd Mon Sep 17 00:00:00 2001
From: David Fetter
Date: Wed, 5 May 2021 15:48:53 -0700
Subje
a of how (not) to design the APIs
to them.
I'm going to guess that anything with an incompatible license will
upset people who are accustomed to ensuring that we have what legally
amounts to an MIT license clean distribution, but I'm thinking that
option is at least worth discussing, even if the immediate consensus
is, "libreadline is bad enough. We went to a lot of trouble to purge
that other stuff back in the bad old days. Let's not make that mistake
again."
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
Hi,
I thought about using the dual, but wasn't sure how many languages
support 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
>From 1fd595576c5972d8604adf77d1959008daeb
On Tue, Jun 15, 2021 at 09:37:11AM +0200, Laurenz Albe wrote:
> On Tue, 2021-06-15 at 04:59 +0000, David Fetter wrote:
> > I thought about using the dual, but wasn't sure how many languages
> > support it.
>
> I think none of the languages for which we cater uses the dua
I believe might have been a
requirement for C11, should be wish to get sub-microsecond
granularity.
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
On Sun, May 08, 2022 at 04:12:27PM -0500, Justin Pryzby wrote:
> On Sun, May 08, 2022 at 08:44:51PM +0000, David Fetter wrote:
> > CREATE TABLE postgres_log
> > (
> > - log_time timestamp(3) with time zone,
> > + log_time timestamp(6) with time zone,
>
> Ple
similar that would require careful consideration.
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 00654ad8707fef0c9bcb7a8b6a8073d1f143368a Mon Sep 17 00:00:00 2001
From: David Fet
On Mon, May 09, 2022 at 11:21:26AM +0100, Dagfinn Ilmari Mannsåker wrote:
> David Fetter writes:
>
> > diff --git src/backend/utils/error/elog.c src/backend/utils/error/elog.c
> > index 55ee5423af..4698e32ab7 100644
> > --- src/backend/utils/error/elog.c
> > +++
On Mon, Jun 13, 2022 at 09:11:56AM +0200, Erik Rijkers wrote:
> Op 13-06-2022 om 07:51 schreef David Fetter:
> > Folks,
> >
> > Please find attached a patch to do $Subject. As dates in a fair number
> > of fields of endeavor are expressed this way, it seems reasonab
On Mon, Jun 13, 2022 at 04:22:42PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Sun, May 8, 2022 at 4:45 PM David Fetter wrote:
> >> Please find attached a patch to change the sub-second granularity of
> >> log timestamps from milliseconds to microseconds.
>
nfo_charp = prev3_wd;
> > + COMPLETE_WITH_QUERY(Query_for_nonvalid_constraint_of_table);
> > + }
> > Specifying valid constraints is an authorized grammar, so it does not
> > seem that bad to keep things as they are, either. I would leave that
> > alo
t languages for specific
> users or databases.
That's a great idea, but I must be missing something important as it
relates to parser hooks. Could you connect those a little more
explicitly?
Best,
David.
* It's not actually a heap in the sense that the term is normally used
in compu
pop
one or more stacks holding state as each character came in? I suspect
the overhead would be unnoticeable even on the slowest* client.
Best,
David.
* One possible exception would be a gigantic paste, a case where psql
can be prevented from attempting tab completion, although the
prevention measures involve a pretty obscure terminal setting:
https://cirw.in/blog/bracketed-paste
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
iscuss reversing our claim that
we support such systems, seeing as it doesn't appear that people will
be deploying new versions of PostgreSQL on 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
rebased and updated these to be more principled about what
functions could be tab completed.
Still missing: tests.
What precisely is this supposed to do?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://w
e so kind as to include
updated documentation of the feature and at least one regression test
of same?
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 better way to do 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
>From 1cf7202facd9fee161865d90304e5ede1e3c65cf Mon Sep 17 00:00:00 2001
From: David Fetter
Date: Mon, 26
ms 174.013 ms
latency stddev:1.94 ms 6.84 ms
which doesn't look like a difference to me.
Intuitively, I'd expect us to get things in the neighborhood of 1 a
lot more often than things in the neighborhood of 1 << (30 or 60). Do
we have some idea of the distri
nger than
SQL has existed. If we're going to capture input time zones, we
should come up with a way to capture the time zone as it existed when
the write occurred, i.e. both its name and the UTC offset it
represented at that time of the write.
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 pretty sure we actually
need to see documenting that as a thing that does actually go to core
database functionality. Yes, there are resources involved with doing a
thing like this, but I don't think that they require constant or even
frequent attention from committers or even from seasoned DB hackers.
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
>
> I agree those functions would be nice too.
>
> I also think it would be nice to provide these convenience functions:
> to_bytes(bigint) -> bytea
> from_bytes(bytea) -> bigint
Along with these, would it make sense to have other forms of these
that won't choke at 63 bits, e.g. NUMERIC or TEXT?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
On Wed, Aug 14, 2024 at 05:39:32PM +0200, Joel Jacobson wrote:
> On Wed, Aug 14, 2024, at 16:43, David Fetter wrote:
> >> I also think it would be nice to provide these convenience functions:
> >> to_bytes(bigint) -> bytea
> >> from_bytes(bytea) -> bigint
>
201 - 300 of 460 matches
Mail list logo
