traints() and have it validate all remaining checks.
28. For table WITH OIDs, the OID should probably follow the new tuple
for partition-key-UPDATEs.
CREATE TABLE p (a BOOL NOT NULL, b INT NOT NULL) PARTITION BY LIST (a)
WITH OIDS;
CREATE TABLE P_true PARTITION OF p FOR VALUES IN('t'
ubclass (etc.)
>
> 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 http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
C
A patch to fix this is attached.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
event_trigger_statistics_doc.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
gt;> (BITS_PER_BITMAPWORD - (BITNUM(upper) - 1));
> =
No objections here for making bms_add_range() perform better, but this
is not going to work when lwordnum == uwordnum. You'd need to special
case that. I didn't think it was worth the trouble, but maybe it is...
I assume
On 7 November 2017 at 01:52, David Rowley wrote:
> Thanks. I'll look over it all again starting my Tuesday morning. (UTC+13)
Hi Amit,
I had another look over this today. Apologies if any of the review seems petty.
Here goes:
1. If test seems to be testing for a child that's
o commit the attached patch.
Thanks, Simon! This was on my to do list today -- glad I checked my
email first.
--
-David
da...@pgmasters.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 7 November 2017 at 01:52, David Rowley wrote:
> Thanks. I'll look over it all again starting my Tuesday morning. (UTC+13)
I have a little more review to share:
1. Missing "in" in comment. Should be "mentioned in"
* get_append_rel_partitions
* Return the list of
the fix to make the new pruning
> code handle Boolean partitioning.
Thanks. I'll look over it all again starting my Tuesday morning. (UTC+13)
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pg
resql.org/gitweb/?p=postgresql.git;a=commit;h=d4c3a156cb46dcd1f9f97a8011bd94c544079bb5
[2]
https://www.postgresql.org/message-id/flat/CAKJS1f9q0j3BgMUsDbtf9%3DecfVLnqvkYB44MXj0gpVuamcN8Xw%40mail.gmail.com#CAKJS1f9q0j3BgMUsDbtf9=ecfvlnqvkyb44mxj0gpvuamcn...@mail.gmail.com
--
David Rowley
On 6 November 2017 at 17:30, Amit Langote wrote:
> On 2017/11/03 13:32, David Rowley wrote:
>> On 31 October 2017 at 21:43, Amit Langote
>> wrote:
>> 1. This comment seem wrong.
>>
>> /*
>> * Since the clauses in rel->baserestrictinfo should all
owed too. This works slightly differently.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 3 November 2017 at 17:32, David Rowley wrote:
> 2. This code is way more complex than it needs to be.
>
> if (num_parts > 0)
> {
> int j;
>
> all_indexes = (int *) palloc(num_parts * sizeof(int));
> j = 0;
> if (min_part_idx >= 0 && max_part
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)
> > + $(
On 3 November 2017 at 03:26, Craig Ringer wrote:
> On 2 November 2017 at 22:22, David Rowley
> wrote:
>> Maybe, but the new implementation is not going to do well with places
>> where we perform lcons(). Probably many of those places could be
>> changed to lappend(),
PARTITION_MAX_KEYS * sizeof(NullTestType *));
should be PARTITION_MAX_KEYS * sizeof(NullTestType). It might have
worked on your machine if you're compiling as 32 bit.
I'll continue on with the review in the next few days.
--
David Rowley http://www.2ndQuadrant.com/
ab13bf. Can you send patches rebased on current master?
Thanks
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
Folks,
Please find attached a patch for $Subject.
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
Don't make an unneeded temp file
In passing, make a slight correction to the
On 3 November 2017 at 03:27, Stephen Frost wrote:
> * David Rowley (david.row...@2ndquadrant.com) wrote:
>> We could get around a few of these problems if Lists were implemented
>> internally as arrays, however, arrays are pretty bad if we want to
>> delete an item out the m
On 3 November 2017 at 03:38, Tom Lane wrote:
> David Rowley writes:
>> On 3 November 2017 at 03:17, Tom Lane wrote:
>>> We've jacked up the List API and driven a new implementation underneath
>>> once before. Maybe it's time to do that again.
>
>>
of those places could be
changed to lappend(), but I bet there's plenty that need prepend.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
xecutor)
Comments on the design are welcome, but I was too late to the
commitfest, so there are other priorities. However, if you have a
strong opinion, feel free to voice it.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
00
at's required is a flock of old clients? 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 ear
> On Nov 1, 2017, at 1:02 PM, Nico Williams wrote:
>
> On Thu, Mar 19, 2015 at 05:41:02PM -0500, David Christensen wrote:
>> The two-arg form of the current_setting() function will allow a
>> fallback value to be returned instead of throwing an error when an
>> unk
On Thu, Mar 19, 2015 at 3:41 PM, David Christensen
wrote:
> The two-arg form of the current_setting() function will allow a
> fallback value to be returned instead of throwing an error when an
> unknown GUC is provided. This would come in most useful when using
> cust
The two-arg form of the current_setting() function will allow a
fallback value to be returned instead of throwing an error when an
unknown GUC is provided. This would come in most useful when using
custom GUCs; e.g.:
-- errors out if the 'foo.bar' setting is unset
SELECT current_setting('foo.
andling.
A patch to do this is attached.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
0001-Support-removing-LEFT-JOINs-with-DISTINCT-GROUP-BY.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsq
group to check whether it is qualified - since every group is
checked the incoming output_tuples from the prior grouping is used. The
side-effect of the effort is that the number of output_tuples has now been
reduced to only those matching the qual - and so it now must take on a new
value to represe
strictly bad given the seeming frequency of the
existing problematic syntax in the wild already.
David J.
lumn_name ) = ROW ( expression | DEFAULT )
If we revert 10 to the pre-10 behavior the existing syntax will work.
David J.
On 10/30/17 6:36 AM, Michael Paquier wrote:
> On Mon, Oct 30, 2017 at 10:15 AM, Chris Travers
>>
>> How does rep mgr or other programs using pg_rewind know what to exclude?
>
> Good question. Answers could come from folks such as David Steele
> (pgBackRest) or Marco (bar
since we
are indeed talking about LOGIN roles there but we are already pointing to
sql-alterrole instead of sql-alteruser and so changing the create variation
to point to sql-createrole seems warranted.
Attached, and below.
David J.
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client
On Mon, Oct 30, 2017 at 11:15:00AM +0300, Anthony Bykov wrote:
> On Sun, 29 Oct 2017 19:11:02 +0100
> David Fetter wrote:
>
> > Thanks for your hard work!
> >
> > Should there also be one for PL/Python3U?
> >
> > Best,
> > David.
> Hi.
>
On 30 October 2017 at 22:44, Andres Freund wrote:
> On 2017-10-30 22:39:01 +1300, David Rowley wrote:
>> Today I was thinking, to get around that issue, we might be able to
>> generate another thin wrapper around elog_start() and mark that as
>> __attribute__((cold)) and fud
On 30 October 2017 at 22:34, Andres Freund wrote:
> Hi,
>
> On 2015-12-20 02:49:13 +1300, David Rowley wrote:
>> Alternatively, if there was some way to mark the path as cold from within
>> the path, rather than from the if() condition before the path, then we
>> could
example, function "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 http://fetter.org/
Phone:
| | | plain | |
b | integer | | | | plain | |
Partition key: RANGE (a)
Partitions: ab_p1 FOR VALUES FROM (1) TO (1),
ab_p2 FOR VALUES FROM (10000) TO (2)
--
David Rowley http:/
more understandable shape. Any opinions?
>
> Strong "yes" from me.
+1
--
-David
da...@pgmasters.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 26 October 2017 at 23:42, Antonin Houska wrote:
> David Rowley wrote:
>
>> Method 1:
>>
>> In set_append_rel_size() detect when just a single subpath would be
>> added to the Append path.
>
> I spent some time reviewing the partition-wise join patch during
On 26 October 2017 at 23:30, Robert Haas wrote:
> On Wed, Oct 25, 2017 at 11:59 PM, David Rowley
> wrote:
>> As of today, because we include this needless [Merge]Append node, we
>> cannot parallelise scans below the Append.
>
> Without disputing your general notion th
which
would be much cleaner.
[1]
https://www.postgresql.org/message-id/CAKJS1f9UXdk6ZYyqbJnjFO9a9hyHKGW7B%3DZRh-rxy9qxfPA5Gw%40mail.gmail.com
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing l
hatever other states 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?
Bes
t comes 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.
--
On Wed, Oct 18, 2017 at 2:30 PM, Nico Williams
wrote:
> On Wed, Oct 18, 2017 at 02:13:29PM -0700, David G. Johnston wrote:
> > > More useful than this, for me, would be a way to get the top-most user.
> >
> > That would be "session_user"?
>
> It's not
On Wed, Oct 18, 2017 at 2:08 PM, Nico Williams
wrote:
> On Wed, Oct 18, 2017 at 01:43:30PM -0700, David G. Johnston wrote:
>
> More useful than this, for me, would be a way to get the top-most user.
>
>
That would be "session_user"?
> Introducing the concept of a
rity definer function it would return whatever current_role would have
returned if the function was a security invoker (i.e., the role that the
system will put back into effect once the security definer function
returns).
Introducing the concept of a stack at the SQL level here seems, at first
glance, to be over-complicating things.
David J.
A small patch to fix these is attached.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
allpath_typos_fix.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
-X/--wal-method default to
stream.
An option value none has been added to reproduce
the old
behavior. The pg_basebackup option
-x
has been removed (instead, use -X fetch).
Also attached.
David J.
diff --git a/doc/src/sgml/release-10.sgml b/doc/src/sgml/release-10.sgml
On 15 October 2017 at 06:49, Robert Haas wrote:
> On Fri, Oct 13, 2017 at 4:49 PM, David Rowley
> wrote:
>> tps = 8282.481310 (including connections establishing)
>> tps = 8282.750821 (excluding connections establishing)
>
> vs.
>
>> tps = 8520.822410 (including
ust speed up the planner. Perhaps I missed some? It
looks like there's plenty we could do in there, just nobody seems
interested enough to go and do it, everyone who cares about
performance is too busy trying to make execution run faster.
--
David Rowley http://www.2ndQuadran
On 14 October 2017 at 09:04, Robert Haas wrote:
> On Mon, Oct 9, 2017 at 11:03 PM, David Rowley
> wrote:
>> -- Unpatched
>> Planning time: 0.184 ms
>> Execution time: 105.878 ms
>>
>> -- Patched
>> Planning time: 2.175 ms
>> Execution time: 1
On 13 October 2017 at 19:36, Jeevan Chalke
wrote:
> I have tried exactly same tests to get to this factor on my local developer
> machine. And with parallelism enabled I got this number as 7.9. However, if
> I disable the parallelism (and I believe David too disabled that), I get
> th
On 13 October 2017 at 12:41, Tom Lane wrote:
> David Rowley writes:
>> If the user defines their normal aggregate as not safe for merging,
>> then surely it'll not be suitable to be used as a window function
>> either, since the final function will also be called t
f the user defines their normal aggregate as not safe for merging,
then surely it'll not be suitable to be used as a window function
either, since the final function will also be called there multiple
times per state.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL
On 13 October 2017 at 04:56, Alvaro Herrera wrote:
> I pushed your original fix.
Thanks for committing
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-
SELECTs too.
I had imagined this would be some backend local cache that saved MRU
plans up to some size of memory defined by a GUC, where 0 would
disable the feature. I never got any further than those thoughts.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Deve
your code assumed the OpExpr was a Var.
The reason Tomas coded it the way it was coded is due to the fact that
there's already code that works exactly the same way in
clauselist_selectivity(). Personally, I don't particularly like that
code, but I'd rather not invent a n
-
2.400209476818
(1 row)
Maybe it's worth trying with different row counts to see if the
additional cost is consistent, but it's probably not worth being too
critical here.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training
Removed by Filter: 00
Planning time: 2.175 ms
Execution time: 106.326 ms
(8 rows)
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
allow_relabelled_vars_in_dependency_stats.patch
Description: Binary data
--
Sent via pgsq
comment in create_append_path() which claims the zero cost is a bit
optimistic.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
On 9 October 2017 at 17:41, David Rowley wrote:
> Thoughts?
Actually, I was a little inconsistent with my List NULL/NIL checks in
that last one.
I've attached an updated patch.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
t that as relations
without unique indexes are pretty uncommon (at least in my world).
Thoughts?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
remove_left_join_distinct.patch
Description: Binary data
--
Sent via
and finding performance is not quite
what they need. It's a bit sad that often the people with the loudest
voices are always so fast to stomp on the ideas for improvements. It
would be much nicer if you'd at least wait for benchmarks before
shooting.
--
David Rowley h
On Thu, Oct 5, 2017 at 3:05 PM, Joshua D. Drake
wrote:
> On 10/05/2017 02:54 PM, David G. Johnston wrote:
>
>> On Thu, Oct 5, 2017 at 2:37 PM, Joshua D. Drake > <mailto:j...@commandprompt.com>>wrote:
>>
>> I get being able to change my search_path on the
g them to always change things on-the-fly or bug
a DBA to change the default for them.
David J.
iorated to some degree, but JITing obviously isn't always going to
> be a win.
It's pretty exciting to see thing being worked on.
I've not looked at the code, but I'm thinking, could you not just JIT
if the total cost of the plan is estimated to be > X ? Where
ing they're permitted, which...well, I could make a case, they
should be mutually exclusive with the cached option.
I guess documenting the behavior in the manual would suffice, tempting
as it would be to include a NOTICE when the table goes from having 0
or more generated columns all of whic
On Oct 1, 2017, at 20:22, Robert Haas wrote:
>> Are permissions correct in the citext extension?
>
> Not to be picky, but couldn't you investigate that a bit before posting here?
Normally I would, but my attention is far from Postgres these days, sadly, and
I tend to think of citext (IT’S NOT
Hackers,
Are permissions correct in the citext extension?
Best,
David
> Begin forwarded message:
>
> From: Sadek Touati
> Subject: Have a problem with citext
> Date: September 29, 2017 at 17:02:50 EDT
> To: "da...@kineticode.com"
>
> Dear sir,
>
, we'd have to check if the table's options were legal for the
> new FDW, but in principle we could support this, I suppose.
> Not sure if it's useful enough to be worth the trouble.
It would definitely be useful if it were available. Nodes are a good
bit more fungibl
e of that function
is not so pretty and that would likely tidy it up a bit. The matching
partition indexes could be returned as a Bitmapset, yet, I don't
really see any code which handles adding the NULL and DEFAULT
partition in get_rel_partitions() either, maybe I've just not looked
hard
-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. Expression
it;h=9140cf826
Yeah, I see 0001 conflicts with that. I'm going to set this to waiting
on author while you're busy rebasing this.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-h
On Sep 25, 2017, at 10:55, Andrew Dunstan
wrote:
> Let's ask a couple of users who I think are or have been actually
> hurting on this point. Christophe and David, any opinions?
If I understand the issue correctly, I think I’d be fine with requiring ALTER
TYPE ADD LABEL to be disa
On 9/23/17 10:22 AM, Peter Eisentraut wrote:
> On 9/13/17 10:26, David Steele wrote:
>> Here's a new patch based on your review. Where I had a question I made
>> a choice as described below:
>
> I have committed the changes to the file APIs and a fix for the umask
&g
ns go through strcoll_l(), which might not even
> exist on a given platform. So they're entirely separate code paths.
>
> regards, tom lane
>
--
David Kohn | Data Engineer | MOAT
63 Madison Ave, 15th Floor, NYC
On 9/20/17 6:26 AM, Dagfinn Ilmari Mannsåker wrote:
> Craig Ringer writes:
>
>> On 20 September 2017 at 06:36, David Steele wrote:
>>
>>>
>>> I just use:
>>>
>>> $SIG{__DIE__} = sub {Carp::confess @_};
>
> That is the basic idea
f limited
backward incompatibility.
Arrays not considered; single-column composites might end up looking like
scalars when presented to a (c) target.
Hope this helps someone besides me understand the problem space.
David J.
nd I don't care since the important information is at the top.
I have used this in production code and it doesn't seem to have any
nasty side effects, though this is only a last resort for when a defined
exception is not raised. For test code it should be more than sufficient.
I have not t
On Tue, Sep 19, 2017 at 2:12 PM, Tom Lane wrote:
> "David G. Johnston" writes:
> > Actually, this does work, just not the way one would immediately expect.
>
> On closer inspection, what's actually happening in your example is that
> you're getting the SELE
;, c1;
END;
$$;
Notice: ("(1,2)",)
And so, yes, my thinking has a backward compatibility problem. But one
that isn't fixable when constrained by backward compatibility - whether
this patch goes in or not.
David J.
to considering exactly one output column for each target var
this seems unnecessary. Then the one special case is today's single
composite column target and multiple output columns. If there is only one
select column it has to be composite.
David J.
On 9/18/17 7:26 PM, Michael Paquier wrote:
> On Tue, Sep 19, 2017 at 8:14 AM, David Steele wrote:
>> On 8/31/17 11:56 PM, Michael Paquier wrote:
>>> Here is an updated patch with refreshed documentation, as a result of
>>> 449338c which was discussed in thread
>
upBackupHistory() will immediately remove the
history file when archive_mode != always so it seems useless to write
it. On the other hand the code is a bit simpler this way. Thoughts?
Regards,
--
-David
da...@pgmasters.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
subsets of clauses in a filter.
I've taken the liberty of adding this to the upcoming commitfest.
Best,
David.
--
David Fetter 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!
7;Mismatch: i=% rn=% rn_val=%', 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, &#
this being a bug.
The attached fixes.
(CC'd -hackers since we're starting to discuss code changes. Further
discussion which includes -hackers should drop the general list)
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training &a
alues,
> so I would be fine with (5), then (4) as the test suite is not
> portable.
I'd prefer 5, but can go with 4.
I get that users need to store their own passwords, but we have support
for SHA1 via the crypto module which seems by far the better choice.
--
-David
da...@pgmasters.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
x27;s not fully cooked yet though.
I'm interested in seeing improvements in this area, so I've put my
name down to review this.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql
the beta period. Why should we do nothing?
>
> Because we do not have consensus on changing it. I've decided that
> you're right, but several other people are saying "no". I can't just
> go change it in the face of objections.
>
>
Add my +1 for changing this to the official tally.
David J.
#x27;s my feeling on it.
>
I think we are being consistent as a project by enforcing strictness of
input in this situation so I'll toss my +0.5/+1 here as well.
David J.
rtitioning
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 partitioning
e
docs say that, so OK, but is there anything else a user should be
worried about?
The rest looks good. I'll mark this "Ready for Committer" since I'm the
only reviewer. I don't think anything you might add based on my
comments above requires a re-review.
As for testing
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 http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter
re when scrolling in a new page).
So I'll agree that in an absolute sense reading the whole of the content in
its condensed form is more difficult than if there were blank lines in
between each block, but usability for the intended purpose is better in the
current form.
David J.
Hi Peter,
Here's a new patch based on your review. Where I had a question I made
a choice as described below:
On 9/1/17 1:58 PM, David Steele wrote:
> On 9/1/17 1:15 PM, Peter Eisentraut wrote:
>> On 8/29/17 12:15, David Steele wrote:
>>
>> I wonder whether we even
owing it out there but can we making putting SET inside a CTE work?
David J.
would see some resistance,
so won't have time to look at this soon.
If the possibility of this increasing planning time in corner cases is
going to be a problem, then it might be best to return this with
feedback for now and I'll resubmit if I get time later in the cycle.
--
Da
a. That would also mean 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?
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 http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter
is to the 2017-11 CF.
Thanks,
--
-David
da...@pgmasters.net
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 95aeb35507..c3e6c30eba 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1130,6 +1130,12 @@ SELECT pg_stop_backup();
+
1 - 100 of 6488 matches
Mail list logo
