>
> postgres=# select str
> string_to_array( strip(strpos(
Neat!
Please add this to the upcoming (2018-01) commitfest at
https://commitfest.postgresql.org/
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778
Remem
On Fri, Nov 03, 2017 at 11:34:18AM -0400, Peter Eisentraut wrote:
> On 11/2/17 22:07, David Fetter wrote:
> > postgres.xml: $(srcdir)/postgres.sgml $(ALLSGML)
> > - $(OSX) $(SPFLAGS) $(SGMLINCLUDE) -x lower $< >$@.tmp
> > - $(call mangle-xml,book)
> > + $(
Folks,
Please find attached a patch for $Subject.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
Don't make an unneeded temp file
In passing, make a
I
presume there's a good reason to reroute rather than serve these
requests.
> * For the new clients to the new server, the message flow will be based
> on the routing list filed in the configuration.
> This proposal is in very early stage, comments and feedback is very much
&g
On Mon, Oct 30, 2017 at 11:15:00AM +0300, Anthony Bykov wrote:
> On Sun, 29 Oct 2017 19:11:02 +0100
> David Fetter <da...@fetter.org> wrote:
>
> > Thanks for your hard work!
> >
> > Should there also be one for PL/Python3U?
> >
> > Best,
> > Da
test" transforms incoming jsonb into python,
> transforms it back into jsonb and returns it.
>
> create extension jsonb_plpython2u cascade;
Thanks for your hard work!
Should there also be one for PL/Python3U?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org
they can get to.
As to "crazy complicated calculations," this is what active databases
are all about. SQL is Turing complete, so you really can do it.
Would you want something that compiles from the user inputs to SQL?
Might that have a more general utility?
Best,
David.
--
David Fett
es of committing at
some higher frequency than the logical transaction.
What other things did you try, and how did they fail? In particular,
what happened when you used
UPDATE table2
SET [things based on table1]
FROM table1 [qualified] JOIN table2 ON ([conditions])
Best,
David.
--
David
rated columns all of which are immutable to having at
least one that's not.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider
re fungible than they were even 5 years back.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Pos
ing a half-baked job of this is probably within
> reach. I'm uncertain about what it would take to bake it fully.
To stretch this analogy too far, what other things could be built out
of the bread this bakes? I'm guessing that at least non-hash
multicolumn indexes would benefit. Expressional in
subsets of clauses in a filter.
I've taken the liberty of adding this to the upcoming commitfest.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail
al=%', i, rn, rn_val;
> end if;
> end loop;
> raise notice 'Tested roman numerals 1..3999';
> end;
> $$;
>
> It's a lot easier to maintain than separate selects.
Why not just one SELECT, as in:
SELECT i, to_char(i, 'rn'), to_number(to_char(i, 'rn'), 'rn');
FROM ge
magically when the partitioning
scheme[1] is specified? In other words, do we have a good reason to have
only some of the hash partitions so defined by default?
Best,
David.
[1] For now, that's just the modulus, but the PoC included specifying
hashing functions, so I assume other ways to specify the
oject I would say it is worth it.
So long as the expression on the normal columns was immutable, it's
fit for an expressional index, as is any immutable function composed
with it.
What am I missing?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3
an that the
> timestamps would be in sync and we could probably eliminate the
> occurrences of the wrong format appearing in the wrong logs.
+1 for making the emitters all work off the same source.
Any idea how much work we're talking about to do these things?
Best,
David.
--
David Fetter <
st move the library-specific
> tests to their own file and mark it as skipped at the start of the file
> when a different library is detected.
This seems like a much smarter and more reliable way to test.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone:
ept patch accompanying
the plan than without. Don't bother with any level of care past
proof-of-concept until you get positive feedback.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: d
On Fri, Aug 18, 2017 at 05:10:29PM +0900, Etsuro Fujita wrote:
> On 2017/08/17 23:48, David Fetter wrote:
> >On Thu, Aug 17, 2017 at 05:27:05PM +0900, Etsuro Fujita wrote:
> >>On 2017/07/11 6:56, Robert Haas wrote:
> >>>On Thu, Jun 29, 2017 at 6:20 AM,
transfer.
These primitives look good. I know it seems unlikely at first blush,
but do we know of bulk load APIs for non-PostgreSQL data stores that
this would be unable to serve?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfe
them. We should think
>about ways to avoid that if we're going to do a major rewrite of the
>stats stuff, which this certainly sounds like.
>
>
> If there weren't HS to worry about, these two points kinda sound like
> the data should be persisted into an actual table, rat
t; >>> early in the pipeline as possible?
>
> >> Adding overhead to every developer's every test cycle doesn't
> >> sound like a win.
>
> > If it takes 100ms, nobody's gonna notice.
>
> I doubt running a perl script that analyzes the entire backend
o 3999?
There are ways to represent much larger numbers, possibly bigger than
INT_MAX. https://en.wikipedia.org/wiki/Roman_numerals#Large_numbers
https://en.wikipedia.org/wiki/Numerals_in_Unicode#Roman_numerals
As nearly as I can tell, this patch is late by 124 days.
Best,
David.
--
David Fetter &
On Wed, Jul 19, 2017 at 06:17:35PM -0500, Merlin Moncure wrote:
> On Tue, Jul 18, 2017 at 12:49 PM, David Fetter <da...@fetter.org> wrote:
> > On Tue, Jul 18, 2017 at 01:36:32PM +0200, david.tu...@linuxbox.cz wrote:
> >> Hi,
> >>
> >> some users and me use
be on board with just dropping the type altogether despite
> Mark's concern. But I am not sure that the way you are proposing would
> please anybody except pedants.
+1 for just dropping the types, preferably modifying the contrib
extensions that depend on it, less preferably, dropping th
FROM arg2 -> key
$$;
CREATE OPERATOR - (
PROCEDURE = jsonb_minus,
LEFTARG = jsonb,
RIGHTARG = jsonb
);
I suspect that there's a faster way to do the jsonb_minus function
internally.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM
B - '{"b": 1, "b": {"c": 3}}'::JSONB
to yield?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Co
On Tue, Jul 18, 2017 at 08:38:25AM +0200, Michael Paquier wrote:
> On Tue, Jul 18, 2017 at 3:45 AM, David Fetter <da...@fetter.org> wrote:
> > The one I run into frequently is in a proprietary fork, RDS Postgres.
> > It'll happily dump out COMMENT ON EXTENSION plpgsq IS .
er backwards to support proprietary forks strikes me
as a terrible idea, I'd like to enable pg_dump to produce and consume
ToCs just as pg_restore does with its -l/-L options. This would
provide the finest possible grain.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://
On Fri, Jul 14, 2017 at 09:49:25PM -0500, Robert Haas wrote:
> On Mon, Jul 10, 2017 at 5:46 PM, David Fetter <da...@fetter.org> wrote:
> > With utmost respect, it's less messy than adding '!' to the already
> > way too random and mysterious syntax of psql's \ commands.
hese
things for local (not localhost) users. Is there some way to handle
them, too, or would that be over-engineering this, given what a local
user can already accomplish?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666
ue that?
+1 for pursuing it. When operations just compose, users get a more
fun experience.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Re
ions. Is that latter just its immediate partitions?
Recursion all the way down? Somewhere in between?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail
On Mon, Jul 10, 2017 at 04:15:28PM +0900, Amit Langote wrote:
> On 2017/07/10 15:32, Craig Ringer wrote:
> > On 8 July 2017 at 00:03, David Fetter <da...@fetter.org> wrote:
> >
> >> On Fri, Jul 07, 2017 at 10:29:26AM +0900, Amit Langote wrote:
> >>> Hi
On Sun, Jul 09, 2017 at 11:46:03AM +1200, Thomas Munro wrote:
> On Sat, Jul 8, 2017 at 8:42 PM, David Fetter <da...@fetter.org> wrote:
> > Using the script attached, I'm getting this very odd result set below.
> >
> > Audit records from COPY to the "foo bar&qu
:52.368228-07 |
public | baz| | {"t": "c"}
2017-07-08 01:36:52.368228-07 | shackle | 2017-07-08 01:36:52.368228-07 |
public | baz | | {"t": "d"}
2017-07-08 01:36:52.368228-07 | shackle | 2017-07-08 01:36:52.368228-07 |
publi
D volume rather than any individual
disk in it.
Are people actually running Pgpool on an untrusted network to the
PostgreSQL nodes?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot
> > public | date_fact_201707 | table | postgres
> > public | date_fact_rest | table | postgres
> > (7 rows)
Would showing relispartition=tru tables only in \d+ fix this?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1
On Mon, Jun 26, 2017 at 12:35:47PM -0700, David G. Johnston wrote:
> On Mon, Jun 26, 2017 at 12:19 PM, David Fetter <da...@fetter.org> wrote:
>
> > On Mon, Jun 26, 2017 at 04:00:55PM +0200, Joel Jacobson wrote:
> > > Hi hackers,
> > >
> > > A colleague
ld this mode handle it? Should it try to detect calls to
volatile functions, or should it just silently fail to do what
it's promised to do?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidf
which means that getting this to overflow (resulting in
> probably-exploitable memory overruns) would be about as hard as
> taking candy from a baby.
So it kicks off really loud and persistent alarms, and isn't as easy
as you thought, even taking this into account?
Best,
David.
--
David Fe
then it
> doesn't feel like a "join" as we know it, but clearly it is. I had
> never considered before that such things might belong inside the
> database as a kind of join operator.
If you turn your head sideways, it's very similar to the range merge
join Jeff Davis proposed.
le attempt to do so.
> In the scenario of a sensitive application hosted on a shared
> SAN, I don't think that is good enough.
>
> Also, in the use case you describe, if you use pg_basebackup to make a
> direct encrypted copy of a data directory, I think that would mean you'd
> ha
do support it are the average and standard deviation
> functions.
>
> Is there a reason for this or it just wasn't gotten to?
I'd bet on lack of tuits. Anything with text has to deal with
collation issues, etc., that may make this trickier than it first
appears.
Best,
David.
--
Davi
On Tue, May 16, 2017 at 08:10:39AM -0700, Jeff Davis wrote:
> On Mon, May 15, 2017 at 1:04 PM, David Fetter <da...@fetter.org> wrote:
> > As the discussion has devolved here, it appears that there are, at
> > least conceptually, two fundamentally different classes of partiti
ts.
Mashing those two cases together appears to cause more problems than
it solves.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember
g anyway.
Does it make sense at this point to separate our partitions into two
categories, those which have can significance to applications, and
those which can't?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfett
it this way. Hard work has been done to make
tuple-routing cheap, and this is one of the payoffs.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(do
o
express what is in essence a boolean condition puzzling. Any
insights?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consid
On Thu, May 11, 2017 at 05:24:16PM +0200, Remi Colinet wrote:
> 2017-05-10 21:52 GMT+02:00 David Fetter <da...@fetter.org>:
>
> > On Wed, May 10, 2017 at 06:40:31PM +0200, Remi Colinet wrote:
> > > Hello,
> > >
> > > This is version 2 of the new comma
eature
several times.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/
as there
a good reason that this isn't a function callable from SQL, i.e. not
restricted to the psql client?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gm
On Tue, May 09, 2017 at 12:48:01PM -0400, Tom Lane wrote:
> David Fetter <da...@fetter.org> writes:
> > On Fri, May 05, 2017 at 02:20:26PM -0400, Robert Haas wrote:
> >> On Thu, May 4, 2017 at 10:59 AM, Chapman Flack <c...@anastigmatix.net>
> >> wrote:
>
y points to wanting an
ability to place arbitrary fields in the logs, not just a
log_line_prefix. This would be made a good bit simpler by structuring
logs, by default, in some serialization a little easier to reason
about (and among other things, parse correctly) than CSV.
Best,
David.
--
David
;
> Student: Shubham Barai
> Mentors: Andrey Borodin, Kevin Grittner
>
> - Foreign Keys for Array Elements
>
> Student: Mark Rofail
> Mentors: Alexander Korotkov, Stephen Frost, Alvaro Herrera
Good luck to all, and welcome to Alexey, Menxing, Shubham, and Mark!
Best,
On Wed, May 03, 2017 at 10:33:32AM -0700, David Fetter wrote:
> On Wed, May 03, 2017 at 10:57:06AM -0300, Alvaro Herrera wrote:
> > Peter Eisentraut wrote:
> > > Most documentation and error messages still uses the term "transaction
> > > log" to refer to
Silver Searcher" for phrase
searches as follows:
ag $(echo "the phrase to be searched" | sed -e 's/ /\\s/g')
Thanks to Dagfinn Ilmari Mannsåker for the tip :)
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo
On Wed, May 03, 2017 at 01:27:38PM -0300, Claudio Freire wrote:
> On Wed, May 3, 2017 at 11:31 AM, David Fetter <da...@fetter.org> wrote:
> > Are you aware of such an ORM which both supports WITH and doesn't
> > also closely track PostgreSQL development? I'm not.
ssessment of what is useful ... but
> generally there seems to be support for making partitioned tables, at
> least, look more like a single table that happens to have partitions
> and less like a bunch of separate tables attached to each other with
> duct tape.)
+1 on the not-duc
c seems like a good idea, without which ORMs that
> support CTEs would be at a loss.
Are you aware of such an ORM which both supports WITH and doesn't also
closely track PostgreSQL development? I'm not.
Even assuming that such a thing exists, it's not at all obvious to me
that we should
H clause from another.
The hammer would then be guaranteed to be too big for precisely the
cases where it's most needed.
> 4. Add some new more generic query hinting facility. This is a lot
> of work and something which would be very hard to get consensus for.
Just the design of the thing
nes of
WITH FENCED/* Somewhat fuzzy. What fence? */
or
WITH AT_MOST_ONCE /* Clearer, but not super precise */
or
WITH UNIQUE_ATOMIC /* More descriptive, but not super clear without the
docs in hand */
or something along that line.
Best,
David.
--
David Fetter <david(a
at?"
>
> If I had to make up some numbers, I'd say the "What?" group is
> about 10x the group of people who intentionally rely on CTEs being
> optimization fences.
I suspect you're off by at least a couple of orders of magnitude here,
which make this even m
On Fri, Apr 28, 2017 at 06:29:48PM +0900, Amit Langote wrote:
> On 2017/04/28 7:36, David Fetter wrote:
> > On Thu, Apr 27, 2017 at 10:30:54AM +0900, Amit Langote wrote:
> >> On 2017/04/27 1:52, Robert Haas wrote:
> >>> On Tue, Apr 25, 2017 at 10:34 PM, Am
If not, I'm not suggesting that this be added at this late date, but
we might want to document that.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)co
On Tue, Apr 25, 2017 at 11:35:21PM +0300, Konstantin Knizhnik wrote:
> On 04/25/2017 07:54 PM, David Fetter wrote:
> > On Tue, Apr 25, 2017 at 06:11:09PM +0300, Konstantin Knizhnik wrote:
> > > On 24.04.2017 21:43, Andres Freund wrote:
> > > > Hi,
> > >
gt; 2927
> prepared
> 6865
> simple + autoprepare
> 6844
If this is string mashing on the unparsed query, as it appears to be,
it's going to be a perennial source of security issues.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415
right now, almost everybody
> > hates.
>
> That's certainly an issue, but it's a lot harder to resolve because
> we've, for years, told people to intentionally use CTEs as optimization
> barriers :(
If we can get better performance by removing the barriers, we can
certainly exp
and I suspect that people will start using this infrastructure
for some very cool projects.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remem
multivariate" to "extended?"
I ask because I found a "multivariate" in there.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)c
alid input syntax for timestamp without time zone:
current_timestamp
HINT: perhaps you meant to use timestamp with time zone.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP:
regression from the extant inheritance-based partitioning.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating
git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=b6fb6471f6afaf649e52f38269fd8c5c60647669
If that's even vaguely usable, I'd say we should use it for this.
I notice that that commit has no SGML component. Should it have one?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 2
tractive on efficiency grounds, less so on reliability ones.
- Something added to the wire protocol
More specialized, limits the information to the session where the
command was issued
- Other things not named here
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.or
On Tue, Feb 28, 2017 at 01:22:22PM -0500, Stephen Frost wrote:
> Greetings!
>
> The PostgreSQL committers would like to welcome Andrew Gierth as a
> new committer for the PostgreSQL project.
Congratulations!
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fet
nts either. I *really* don't want us
> going down some road where we try to make sure that hitting 'tab'
> never fails...
Wouldn't that just be a correct, grammar-aware implementation of tab
completion? Why wouldn't you want that?
Best,
David.
--
David Fetter <david(at)fetter(d
jority, but that would be very sad.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donat
bpq...
You bring up a salient point. What say we make pg_services a little
more universal? I'm guessing that the Java port wouldn't be too
complicated. It's already well defined.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfet
om/tatsuo-ishii/pgproto
> (to build the program, you need C compiler and libpq)
Does it seem reasonable to start making this into a regression test
and/or fuzz test for the protocol itself?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AI
as "?column?", 1+1) AS x;
This is what you get when you do the second, which I'm assuming is
what you meant to do:
ERROR: column reference "?column?" is ambiguous
LINE 1: SELECT "?column?" FROM (select 1+1 as "?column?", 1+1) AS x;
Best,
David.
--
David F
the hex format.
>
> Is there a reason we chose hex over base64?
Whether there was or not, there's not a compelling reason now to break
people's software. When people want compression, methods a LOT more
effective than base64 are common. Gzip, for example.
Best,
David.
--
David Fetter <d
s to do something if float timestamps are enabled?
> >
>
> It's definitely not hard, we already have
> IntegerTimestampToTimestampTz() which does the opposite conversion anyway.
>
> That being said, I did wonder myself if we should just deprecate float
> timestamps as we
future, could you please leave patches uncompressed so they're
easier to see in the archives?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
m tuits not to expand
TABLESAMPLE to the rest of our SQL-visible relation structures? I'm
guessing this could have something to do with the volatility they
might have, whether in views that call volatile functions or in
foreign tables that might not make the right guarantees...
Best,
David.
--
David Fetter
right sub-partition
> for the message. If we decide to write code to find the root
> partition, then it's just a matter of another function
> ExecFindPartition().
>
> Also, I was thinking : give the hint *only* if we know there is a
> right sub-partition. Otherwise, it might distra
On Wed, Feb 15, 2017 at 01:06:32PM +0530, Amit Khandekar wrote:
> On 14 February 2017 at 22:24, David Fetter <da...@fetter.org> wrote:
> > On Mon, Feb 13, 2017 at 05:31:56PM +0530, Amit Khandekar wrote:
> >> Currently, an update of a partition key of a partition is
ATE TABLE foo (LIKE foo_tv);
INSERT INTO foo SELECT * FROM foo_tv;
> Are there plans in 10.0 to allow parallelism in queries that write,
> or at least in "CREATE TABLE AS" queries? (Support in materialized
> views would be great, too!)
Patches are always welcome, and there's one
ot found, an error is reported.
This is great!
Would it be really invasive to HINT something when the subtree is a
proper subtree?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMP
it
> helps prevent unnecessary intermediate overflows when k > n/2. Of
> course, that's not a worry for the current use of this function, but
> it's good to have a robust algorithm.
Indeed. :)
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phon
On Thu, Feb 09, 2017 at 11:12:00AM +0100, Christoph Berg wrote:
> Re: David Fetter 2017-02-08 <20170208151214.ga8...@fetter.org>
> > Would you be open to saving the next person some work by doing
> > something similar to how \d is done, namely looking for an 'x'
> > modi
keywords the standards committee will
dream up, or what silliness they'll introduce in the grammar :/
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)co
also that I think num_combinations(n) is just an expensive way of
> calculating 2^n - n - 1.
Combinations are n!/(k! * (n-k)!), so computing those is more
along the lines of:
unsigned long long
choose(unsigned long long n, unsigned long long k) {
if (k > n) {
return 0;
}
On Wed, Feb 08, 2017 at 03:52:40PM +0100, Christoph Berg wrote:
> Re: David Fetter 2017-02-07 <20170207051659.gc3...@fetter.org>
> > On Mon, Feb 06, 2017 at 08:54:13PM +0100, Christoph Berg wrote:
> > > The majority of voices here was in favor of using \gx, so here
On Tue, Feb 07, 2017 at 09:10:17AM -0800, David Fetter wrote:
> On Tue, Feb 07, 2017 at 04:13:40PM +0100, Joel Jacobson wrote:
> > Hi hackers,
> >
> > Currently there is no simple way to check if two sets are equal.
>
> Assuming that a and b each has a
NOT NULL test is faster than IS NULL, but you can flip that and change
the array to {0} with identical effect.
WITH t AS (
SELECT a AS a, b AS b, (a IS NOT NULL)::int + (b IS NOT NULL)::int AS ind
FROM a FULL JOIN b ON ...
)
SELECT array_agg(DISTINCT ind) = '{2}'
FROM t;
Best,
David.
--
Dav
*/psql.*
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
These things and many others are in the
https://wiki.postgresql.org/wiki/Developer_FAQ
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember
atch and any documentation you write that
comes with it.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgr
think about facilities to enable or disable different checks.
This is just the discussion I'd hoped for. I'll draft up a patch in
the next day or two, reflecting what's gone so far.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: df
On Thu, Feb 02, 2017 at 10:34:43AM -0500, Bruce Momjian wrote:
> On Thu, Feb 2, 2017 at 07:18:45AM -0800, David Fetter wrote:
> > On Thu, Feb 02, 2017 at 03:16:29PM +, Bruce Momjian wrote:
> > > I just don't see this patch going in. I think it needs are
> > > larg
1 - 100 of 2065 matches
Mail list logo
