Re: Peter Eisentraut 2017-08-14
> There are probably a bunch of Perl or Python modules that can be
> employed for this.
https://github.com/ChristophBerg/postgresql-numeral
Christoph
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
Re: Konstantin Knizhnik 2017-09-13
<2393c4b3-2ec4-dc68-4ea9-670597b56...@postgrespro.ru>
>
>
> On 13.09.2017 10:51, Christoph Berg wrote:
> > Re: Konstantin Knizhnik 2017-09-01
> >
> > > + Functional index is based on on projection function: functio
Re: Konstantin Knizhnik 2017-09-01
> + Functional index is based on on projection function: function which
> extract subset of its argument.
> + In mathematic such functions are called non-injective. For injective
> function if any attribute used in the indexed
> + expression
Re: To Andres Freund 2017-09-11 <20170911095338.mqkiinkpk7gko...@msg.df7cb.de>
> Re: Andres Freund 2017-09-11
> <20170911090306.s7sj4uyr4t72w...@alap3.anarazel.de>
> > Could you pprint() the expression that's being initialized?
> (gdb) p pprint(node)
Andres helped me to produce a correct dump, my
Re: Andres Freund 2017-09-11 <20170911090306.s7sj4uyr4t72w...@alap3.anarazel.de>
> Could you pprint() the expression that's being initialized?
(gdb) f 4
#4 0x5604ecedd124 in ExecInitNode (node=node@entry=0x5604ee884f80,
estate=estate@entry=0x5604ee8c78a0,
eflags=eflags@entry=16) at
./b
Re: To Tom Lane 2017-09-11 <20170911083136.stdnc4w52wk3o...@msg.df7cb.de>
> postgres=# select test_param_where();
> FEHLER: XX000: unrecognized node type: 217
> KONTEXT: SQL-Anweisung »select bfrom numbers where a=x«
> PL/pgSQL-Funktion test_param_where() Zeile 6 bei SQL-Anweisung
> ORT:
Re: Tom Lane 2017-09-10 <13662.1505077...@sss.pgh.pa.us>
> Christoph Berg writes:
> > I'm not sure if this is a bug in mysql_fdw, or in PG10:
>
> > ! ERROR: unrecognized node type: 217
>
> Hm, nodetag 217 is T_List according to gdb. Wouldn't expect tha
Hi,
I'm not sure if this is a bug in mysql_fdw, or in PG10:
== running regression test queries==
test mysql_fdw... FAILED
*** 345,359
NOTICE: Found number Three
NOTICE: Found number Four
NOTICE: Found number Five
! NOTICE: Found numb
Re: Tom Lane 2017-08-13 <14677.1502638...@sss.pgh.pa.us>
> Christoph Berg writes:
> > Seems to be a gcc-7 problem affecting several packages on mips64el:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871514
>
> Hm, unless there is a use of sigsetjmp earlier
Re: Peter Eisentraut 2017-08-24
<8aa00f15-144e-e793-750e-d1d6876d6...@2ndquadrant.com>
> On 8/23/17 09:36, Robert Haas wrote:
> > I think I agree. It seems to me that the version of pg_upgrade
> > shipped with release N only needs to support upgrades to release N,
> > not older releases. There's
Re: Tom Lane 2017-08-13 <14517.1502638...@sss.pgh.pa.us>
> I suspect you could work around this with
>
> boolisCompleteQuery = (context <= PROCESS_UTILITY_QUERY);
> - boolneedCleanup;
> + volatile bool needCleanup;
> boolcommandCollected =
Re: Thomas Munro 2017-08-10
> > Agreed. Here's a version that skips those useless detail messages
> > using a coding pattern I found elsewhere.
>
> Rebased after bf6b9e94.
> message ? errdetail("Diagnostic message: %s", message) : 0));
"Diagnostic message" doesn't really mean anything, and pr
Re: Sandeep Thakkar 2017-08-08
> Hi
>
> An update from beta3 build: We are no longer seeing this issue (handshake
> failure) on Windows 64bit, but on Windows 32bit it still persists.
HEAD as of 5a5c2feca still has the same problem on kfreebsd. Is there
anything I could dump so we understand the
Re: To PostgreSQL Hackers 2017-08-13
<20170813130127.g3tcyzzvuvlpz...@msg.df7cb.de>
> 10beta3 and 9.6.4 are both failing during initdb on mips64el on
> Debian/sid (unstable):
>
> https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.6&arch=mips64el&ver=9.6.4-1&stamp=1502374949&raw=0
> https
10beta3 and 9.6.4 are both failing during initdb on mips64el on
Debian/sid (unstable):
https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.6&arch=mips64el&ver=9.6.4-1&stamp=1502374949&raw=0
https://buildd.debian.org/status/fetch.php?pkg=postgresql-10&arch=mips64el&ver=10%7Ebeta3-1&stamp=15
Re: Tom Lane 2017-07-31 <30582.1501508...@sss.pgh.pa.us>
> Christoph Berg writes:
> >>> The only interesting line in log/postmaster.log is a log_line_prefix-less
> >>> Util.c: loadable library and perl binaries are mismatched (got handshake
> >>> key
Re: Ashutosh Sharma 2017-07-31
> > The only interesting line in log/postmaster.log is a log_line_prefix-less
> > Util.c: loadable library and perl binaries are mismatched (got handshake
> > key 0xd500080, needed 0xd600080)
> > ... which is unchanged from the beta2 output.
>
>
> I am not able t
Re: Tom Lane 2017-07-28 <3254.1501276...@sss.pgh.pa.us>
> Christoph Berg writes:
> > The plperl segfault on Debian's kfreebsd port I reported back in 2013
> > is also still present:
> > https://www.postgresql.org/message-id/20130515064201.GC704%40msgid.df7cb.
Re: Heikki Linnakangas 2017-05-18 <5b9085c2-2c18-e5e3-c340-c07d11a9c...@iki.fi>
> > Please go ahead, I don't think I have online access to a m68k machine.
> > (It got demoted to an unofficial port some time ago and the old Debian
> > porter machines got taken down).
>
> Ok, pushed, let's see if th
Re: Dave Page 2017-07-12
> > Well, we have various buildfarm machines running perls newer than that,
> > eg, crake, with 5.24.1. So I'd say there is something busted about your
> > perl installation. Perhaps leftover bits of an older version somewhere?
> >
>
> Well crake is a Fedora box - and
Re: Alvaro Herrera 2017-07-13 <20170713170402.74uuoivrgd3c6tnw@alvherre.pgsql>
> > > Objections to committing this now, instead of waiting for v11?
> >
> > But I am -1 for the sneak part. It is not the time to have a new
> > feature in 10, the focus is to stabilize.
>
> But if we were treating it
Re: To Andres Freund 2017-05-24 <20170524170921.7pykzbt54dlfk...@msg.df7cb.de>
> > > If we had a typo or something in that code, the build farm should have
> > > caught it by now.
> > >
> > > I would try compiling with lower -O and see what happens.
> >
> > Trying -O0 now.
>
> Sorry for the late
Re: Tom Lane 2017-05-31 <28752.1496238...@sss.pgh.pa.us>
> OK, this looks good to me. Just to make sure everyone's on the
> same page, what I propose to do is simplify all our platform-specific
> Makefiles that use either -fpic or -fPIC to use -fPIC unconditionally.
> This affects the netbsd, linu
Re: Tom Lane 2017-05-30 <1564.1496176...@sss.pgh.pa.us>
> It'd be interesting if people could gather similar numbers on other
> platforms of more real-world relevance, such as ppc64. But based on
> this small sample, I wouldn't object to just going to -fPIC across
> the board.
ppc64el, Debian uns
Re: Tom Lane 2017-05-30 <25131.1496163...@sss.pgh.pa.us>
> Christoph Berg writes:
> > My main point here would be that we are already setting this for all
> > extensions for sparc and sparc64, so s390(x) would just follow suit.
>
> For some values of "we", su
Re: Konstantin Knizhnik 2017-05-30
>
>
> On 29.05.2017 20:21, Christoph Berg wrote:
> >
> > I think the term you were looking for is "projection".
> >
> > https://en.wikipedia.org/wiki/Projection_(set_theory)
>
> I have already renamed param
Re: Andres Freund 2017-05-30 <20170530161541.koj5xbvvovrrt...@alap3.anarazel.de>
> I think we can fix this easily enough in Citus, postgis, and whatever.
> But it's not a particularly good user/developer experience, and
> presumably is going to become more and more common. On x86 there
> shouldn't
Re: Tom Lane 2017-05-29 <28291.1496087...@sss.pgh.pa.us>
> Andres Freund writes:
> > On May 29, 2017 12:15:37 PM PDT, Alvaro Herrera
> > wrote:
> >> I think it'd be smart to support the use case directly, because there's
> >> interest in it being actually supported (unlike the statu quo).
> >> S
Re: Jeff Janes 2017-05-29
> > Usually I turn the pager off completely, and only switch it on when I am
> > about to execute something that will return many rows, but what I'd really
> > like is some way to tell psql to activate the pager as normal for height,
> > but to ignore width. My first th
Re: Konstantin Knizhnik 2017-05-29 <592bbd90.3060...@postgrespro.ru>
> On 05/27/2017 09:50 PM, Peter Eisentraut wrote:
> > On 5/25/17 12:30, Konstantin Knizhnik wrote:
> > > Functions like (info->>'name') are named "surjective" ni mathematics.
> > A surjective function is one where each value in th
Re: To Andres Freund 2016-04-28 <20160428080824.ga22...@msg.df7cb.de>
> > I'm not clear why citus triggers this, when other extensions don't?
>
> Maybe it's simply because citus.so is bigger than all the other
> extension .so files:
>
>-fpic
> Generate position-independent code (
Re: To Andres Freund 2017-05-18 <20170518192924.jkrzevlencp3g...@msg.df7cb.de>
> > If we had a typo or something in that code, the build farm should have
> > caught it by now.
> >
> > I would try compiling with lower -O and see what happens.
>
> Trying -O0 now.
Sorry for the late reply, I was ho
Re: Peter Eisentraut 2017-05-18
<7a4d3b0f-78da-2a5b-7f3b-8b3509c1e...@2ndquadrant.com>
> If we had a typo or something in that code, the build farm should have
> caught it by now.
>
> I would try compiling with lower -O and see what happens.
Trying -O0 now.
Re: Andres Freund 2017-05-18 <2017051
Re: Heikki Linnakangas 2017-05-18
> I'll commit that, barring objections. If you can verify that it fixes the
> problem before that, that'd be great, otherwise I guess we'll find out some
> time after the commit.
Please go ahead, I don't think I have online access to a m68k machine.
(It got demot
Re: Tom Lane 2017-05-17 <30016.1495041...@sss.pgh.pa.us>
> Christoph Berg writes:
> > The sequence regression tests are failing on Debian/sparc64:
> > ...
> > (This is only the last 100 lines of regression.diffs, if it helps I
> > can try rebuilding and grabbin
Not sure if a lot of people still care about m68k, but it's still one
of the unofficial Debian ports (it used to be the first non-x86 port
done decades ago):
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
-Wendif-labels -Wmissing-format-attribute -Wformat-security
-
The sequence regression tests are failing on Debian/sparc64:
sequence ... FAILED
polymorphism ... ok
rowtypes ... ok
returning... ok
largeobject ... ok
with ... ok
xml
Re: Fabien COELHO 2017-05-08
> Thus I naïvely added:
>
> password_encryption = scram-sha-256
Hmm. Naïvely I would have assumed this would be missing quotes :)
> The result is:
>
> Error: Invalid line 88 in /etc/postgresql/10/main/postgresql.conf:
> »password_encryption = scram-sha-256«
Re: Daniel Verite 2017-03-03
<4d84079e-325b-48c5-83e6-bb54bb567...@manitou-mail.org>
> - tab-completion: works but the list in tab-complete.c:backslash_commands[]
> is sorted alphabetically so "\\gx" should come after "\\gset"
Good catch, it was still in that place from when it was named \G.
In
Re: To Tom Lane 2017-02-20 <20170220161556.5ukosuj5o572b...@msg.credativ.de>
> I was compiling the program on jessie and on sid, and running the
> jessie binary on sid made it output the same as the sid binary, so the
> difference isn't in the binary, but in some system library.
Fwiw, the problem
Re: Tom Lane 2017-02-20 <13825.1487607...@sss.pgh.pa.us>
> Still, it'd be worth comparing the assembly code for your test program.
I was compiling the program on jessie and on sid, and running the
jessie binary on sid made it output the same as the sid binary, so the
difference isn't in the binary
Re: Tom Lane 2017-02-20 <30737.1487598...@sss.pgh.pa.us>
> Hmph. We haven't touched that code in awhile, and certainly not in the
> 9.4.x branch. I'd have to agree that this must be a toolchain change.
FYI, in the meantime we could indeed trace it back to an libc issue on
Jessie:
$ cat sqrt.c
The point/polygon regression tests have started to fail on 32-bit
powerpc on Debian Jessie. So far I could reproduce the problem with
PostgreSQL 9.4.10+11 and 9.6.1, on several different machines. Debian
unstable is unaffected.
The failure looks like this:
https://buildd.debian.org/status/fetch.p
he \d version starts at line 398 in master.
I think that ship has sailed, given there's already \gset.
Supporting \g[optionset] next to it *now*, given no one knows how
"optionset" is going to evolve seems like premature optimization.
Mit freundlichen Grüßen,
Christoph Berg
--
Senio
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 is
> > another version of the same patch which implements that.
>
> Pa
The majority of voices here was in favor of using \gx, so here is
another version of the same patch which implements that.
Christoph
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
new file mode 100644
index ae58708..e0302ea
*** a/doc/src/sgml/ref/psql-ref.sgml
--- b/d
es not support a filename argument. (It will
instead stuff the argument into the next query buffer.)
(The \G patch already supports the filename argument.)
Mit freundlichen Grüßen,
Christoph Berg
--
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204
Re: Daniel Verite 2017-01-28
<74e7fd23-f5a9-488d-a8c4-1e0da674b...@manitou-mail.org>
> > Mysql's CLI client is using \G for this purpose, and adding the very
> > same functionality to psql fits nicely into the set of existing
> > backslash commands: \g sends the query buffer, \G will do exactly th
Re: Stephen Frost 2017-01-27 <20170127160544.gi9...@tamriel.snowman.net>
> > > Uh, I figured it was more like \g, which just re-runs the last query..
> > > As in, you'd do:
> > >
> > > table pg_proc; % blargh, I can't read it like this
> > > \G % ahh, much nicer
> >
> > Sure, that's exactly the s
people in the thread seem to
> have agreed back then.
I forgot to add the archive URL here:
https://www.postgresql.org/message-id/758d5e7f0804030023j659d72e6nd66a9d6b93b30886%40mail.gmail.com
Mit freundlichen Grüßen,
Christoph Berg
--
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB M
n its own, and several people in the thread seem to
have agreed back then.
Patch attached, I'll add it to the next commit fest.
Mit freundlichen Grüßen,
Christoph Berg
--
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterall
Re: Heikki Linnakangas 2016-10-17 <07ebd878-ff09-72d5-7df7-f7fde7b83...@iki.fi>
> Committed this patch now.
Hi,
I've just taken up work again on PG 10 on Debian unstable.
With openssl 1.1.0c-2, pgcrypto errors out with:
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statemen
Re: Gilles Darold 2016-10-27
> > I'm partial to "format path" over just line number, because
> > it's more explicit. Either way works.
>
> This is the format used. Ex:
>
> ~$ cat /usr/local/postgresql/data/current_logfile
> stderr pg_log/postgresql-2016-10-27_185100.log
> csvlog pg_log/postgre
Re: Karl O. Pinc 2016-10-27 <20161026222513.74cd3...@slate.meme.com>
> Since it now can contain multiple pathnames perhaps the name of the
> file should be "current_logfiles"? Seems more descriptive.
Not sure about that, most often it would contain one logfile only, and
catering for that seems fa
Re: Bruce Momjian 2016-10-19 <20161018220909.ga11...@momjian.us>
> > There's actually another instance of "rename so people shoot their
> > feet less often" here: pg_resetxlog, which is a user-facing tool.
> > Folks on #postgresql have repeatedly been joking that it should rather
> > be named pg_ea
Re: Gilles Darold 2016-10-14
> Agree, the usability of the current version is really a pain. What I've
> thought is that the function could return the csv log in all case when
> csvlog is set in log_destination and the stderr log file when csvlog is
> not defined. We can also have a parametrer to
Re: Stephen Frost 2016-10-14 <20161014113523.gz13...@tamriel.snowman.net>
> > We have a tool called pg_xlogdump in the standard installation. initdb
> > has an option --xlogdir, pg_basebackup has --xlog and others. Renaming
> > the xlog directory would make this all a bit confusing, unless we're
Re: Jeff Janes 2016-10-14
> I don't know why you would have to change %q though. I assume you would
> just stick %a in from of %q, if that is what you wanted to do. But I've
> never used %q myself.
I got it the wrong way round - the change will be that %a will be
available in non-session conte
Re: To Gilles Darold 2016-10-14 <20161014125406.albrfj3qldiwj...@msg.df7cb.de>
> A better design might be to return two columns instead:
>
> postgres=# select * from pg_current_logfile();
> stderr| csvlog
> ---+-
Re: Stephen Frost 2016-10-14 <20161014113523.gz13...@tamriel.snowman.net>
> > I think it would help if we moved it to something like
> > "internal/pg_xlog" and "internal/pg_clog". Keep the name but move it
> > out of sight.
>
> I disagree that this will materially help with the issue.
And intern
Hi Gilles,
Re: Gilles Darold 2016-10-07 <0731a353-8d2f-0f2f-fcd5-fde77114c...@dalibo.com>
> > What bugs me is the new file "pg_log_file" in PGDATA. It clutters the
> > directory listing. I wouldn't know where else to put it, but you might
> > want to cross-check that with the thread that is trying
Re: Michael Paquier 2016-02-10
> On Mon, Feb 8, 2016 at 11:32 PM, Andres Freund wrote:
> > Frequently when reading postgres logs to do some post mortem analysis
> > I'm left wondering what process emitted an error/log message. After the
> > fact it's often hard to know wether an error message wa
Re: Stephen Frost 2016-10-12 <20161012190732.gj13...@tamriel.snowman.net>
> For my 2c, I'd rather have %m, but I definitely agree with Robert that
> we need to do *something* here and if the only thing holding us back is
> %t vs. %m, then let's just pick one and move on. I'll just hold my nose
> w
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
pg_filedump is a separate git repo, so the commitfest app won't let me mark
Re: Aleksander Alekseev 2016-10-12 <20161012111527.GA17916@e733.localdomain>
> Hello.
>
> First patch fixes:
>
> ```
> pg_filedump.c: In function ‘FormatItem’:
> pg_filedump.c:994:18: error: ‘SizeOfIptrData’ undeclared (first use in
> this function)
>if (numBytes < SizeO
Re: Jeff Janes 2016-10-12
> Do you think the pushback will come from people who just accept the
> defaults?
I'm concerned about readability. "2016-10-12 20:14:30.449 CEST" is a
lot of digits. My eyes can parse "20:14:30" as a timestamp, but
"20:14:30.449" looks more like an IP address. (Admitted
Re: Peter Eisentraut 2016-10-12
<0caa6d7f-deb6-9a43-2b38-60e63af93...@2ndquadrant.com>
> >> > is going to do more to raise peoples' awareness than anything we
> >> > could do in the documentation. But perhaps an example along these
> >> > lines would be useful for showing proper use of %q.
> > Pa
Re: Tom Lane 2016-10-08 <29244.1475959...@sss.pgh.pa.us>
> So I'm still of the opinion that there's not likely to be any meaningful
> performance difference in practice, at least not on reasonably recent
> Linux machines. But this does indicate that if there is any difference,
> it will probably f
Re: Heikki Linnakangas 2016-10-06
> I propose the attached patch. It gives up on trying to deal with multiple
> key lengths (as noted earlier, OpenSSL just always passed keylength=1024, so
> that was useless). Instead of using the callback, it just sets fixed DH
> parameters with SSL_CTX_set_tmp_d
Re: Michael Paquier 2016-09-30
"pg_trans" is used in two places:
> -pg_clog records the commit status for each transaction that has been assigned
> +pg_trans records the commit status for each transaction that has been
> assigned
> - /* copy old commit logs to new data dir */
> - copy
Hi Gilles,
I've just tried v4 of the patch. The OID you picked for
pg_current_logfile doesn't work anymore, but after increasing it
randomly by 1, it compiles. I like the added functionality,
especially that "select pg_read_file(pg_current_logfile());" just
works.
What bugs me is the new file
Re: Fabien COELHO 2016-10-03
> > I "\set" a bunch of lengthy SQL commands in there, e.g.
>
> I agree that this looks like a desirable feature, however I would tend to
> see that as material for another independent patch.
Sure, my question was by no means intending to stop your pgbench patch
from
Re: Fabien COELHO 2016-10-03
>
> Attached patch does what is described in the title, hopefully. Continuations
> in other pgbench backslash-commands should be dealt with elsewhere...
Would (a similar version of) that patch also apply to .psqlrc? I
"\set" a bunch of lengthy SQL commands in there,
Re: Tom Lane 2016-09-29 <18642.1475159...@sss.pgh.pa.us>
> > Possibly the longer version could be added as an example in the
> > documentation.
>
> I suspect that simply having a nonempty default in the first place
> is going to do more to raise peoples' awareness than anything we
> could do in th
Re: Tom Lane 2016-09-29 <16946.1475157...@sss.pgh.pa.us>
> Robert Haas writes:
> > As long as we get %t and %p in there we're going to be way ahead, really.
>
> Could we get consensus on just changing the default to
>
> log_line_prefix = '%t [%p] '
>
> and leaving the rest out of it? I t
Re: Peter Eisentraut 2016-09-29
<21d2719f-36ff-06d2-5856-25ed48b96...@2ndquadrant.com>
> > Christoph/Debian:
> > log_line_prefix = '%t [%p-%l] %q%u@%d '
> > Peter:
> > log_line_prefix = '%t [%p]: [%l] %qapp=%a '
>
> I'm aware of two existing guidelines on log line formats: syslog and
> pg
Re: Robert Haas 2016-09-28
> > Well, practically anything that includes a PID and the timestamp is
> > going to be an improvement over the status quo. Just because we can't
> > all agree on what would be perfect does not mean that we can't do
> > better than what we've got now. +1 for trying.
>
Re: To Heikki Linnakangas 2016-09-15
<20160915213406.2mjlhcg7px3sa...@msg.df7cb.de>
> > Can you elaborate? Are you saying that Debian 9 (strect) will not ship
> > OpenSSL 1.0.2 anymore, and will require using OpenSSL 1.1.0?
>
> I thought that was the plan, but upon asking on #debian-devel, it
> s
Re: Heikki Linnakangas 2016-09-15 <7e4991a9-410f-5e1f-2a3a-e918e4a4b...@iki.fi>
> > I'm afraid it's not that easy - Debian 9 (stretch) will release at the
> > beginning of next year, and apt.postgresql.org will want to build
> > 9.2/9.3/9.4 for that distribution. I guess yum.postgresql.org will
> >
Re: Michael Paquier 2016-09-15
> On Thu, Sep 15, 2016 at 8:57 PM, Heikki Linnakangas wrote:
> > I backpatched this to 9.5, but not further than that. The functions this
> > modified were moved around in 9.5, so the patch wouldn't apply as is. It
> > wouldn't be difficult to back-patch further if
Re: Tom Lane 2016-09-06 <17637.1473192...@sss.pgh.pa.us>
> Christoph's idea isn't bad. We could tweak it to:
>
> COPY TO instructs the PostgreSQL server process to write a file.
>
> COPY FROM instructs the PostgreSQL server process to read a file.
>
> This seems to cover both the wr
Re: Craig Ringer 2016-09-05
> To cover the same-host case we could try something like:
>
>COPY runs on the PostgreSQL server, using the PostgreSQL server's
> directories and permissions, it doesn't run on the client.
>
> ... but I think that's actually less helpful for the users who'll need
Re: Simon Riggs 2016-09-03
> pg_hba_file_settings seems a clumsy name. I'd prefer pg_hba_settings,
> since that name could live longer than the concept of pg_hba.conf,
> which seems likely to become part of ALTER SYSTEM in future, so we
> wouldn't really want the word "file" in there.
IMHO "sett
Re: Craig Ringer 2016-09-02
> I thought about that but figured it didn't really matter too much,
> when thinking about examples like
>
> # COPY batch_demo FROM '/root/secret.csv' WITH (FORMAT CSV);
> ERROR: could not open file "/root/secret.csv" for reading: Permission denied
>
> or whatever,
Re: Fabien COELHO 2016-08-26
> So I would suggest something like the following, which is also a little bit
> more compact:
>
> log_line_prefix = '%m [%p:%l] %q%a '
>
> If you want to keep something with %a, maybe parentheses?
>
> Finally I'm wondering also whether a timestamp since the server
Re: Fujii Masao 2016-08-26
> > I agree on a hard break, unless we get pushback from users, and even
> > then, they can create the symlinks themselves.
>
> I strongly prefer symlink approach not to break many existing tools
> and scripts.
Symlinks might actually be worse than removing the direct
Re: Thomas Munro 2016-08-21
> Right, we could just add it to guc.c after "on", so that you can "SET
> synchronous_commit TO remote_flush", but then "SHOW
> synchronous_commit" returns "on".
>
> The problem I was thinking about was this: if you add "remote_flush"
> before "on" in guc.c, then "SHO
Re: To Tom Lane 2016-08-15 <20160815111057.v2mqqjp4aabvw...@msg.df7cb.de>
> Re: Tom Lane 2016-07-30 <1184.1469890...@sss.pgh.pa.us>
> > In short, I think that the way to make something like this work is to
> > figure out how to have "virtual" catalog rows describing a temp table.
> > Or maybe to pa
Re: Tom Lane 2016-07-30 <1184.1469890...@sss.pgh.pa.us>
> In short, I think that the way to make something like this work is to
> figure out how to have "virtual" catalog rows describing a temp table.
> Or maybe to partition the catalogs so that vacuuming away temp-table
> rows is easier/cheaper th
Re: Craig Ringer 2016-08-12
> I think we should emit a HINT here, something like:
>
> ERROR: could not open file "D:\CBS_woningcijfers_2014.csv" for reading: No
> such file or directory'
> HINT: Paths for COPY are on the PostgreSQL server, not the client. You may
> want psql's \copy or a drive
Re: Peter Eisentraut 2016-08-01
> > PostgreSQL uses the spaces inconsistently, though. pg_size_pretty uses
> > spaces:
> >
> > # select pg_size_pretty((2^20)::bigint);
> > pg_size_pretty
> >
> > 1024 kB
>
> because it's "pretty" :)
:)
> > SHOW does not:
> >
> > # show wor
Re: Bruce Momjian 2016-07-30 <20160730181643.gd22...@momjian.us>
> I also just applied a doc patch that increases case and spacing
> consistency in the use of kB/MB/GB/TB.
Hi,
PostgreSQL uses the spaces inconsistently, though. pg_size_pretty uses spaces:
# select pg_size_pretty((2^20)::bigint);
Makes sense. Is this something that should be implemented in postgresql, or via
pg_createcluster?
Am 19. Juli 2016 16:00:05 MESZ, schrieb Magnus Hagander :
>On Sun, Jul 17, 2016 at 10:07 PM, Christoph Berg
>wrote:
>
>> Re: Peter Eisentraut 2016-07-17 <
>> d6b22200-
Re: Peter Eisentraut 2016-07-17
> On 7/15/16 3:07 PM, Andrew Dunstan wrote:
> > Do those packagers who install dummy certificates and turn SSL on also
> > change their pg_hba.conf.sample files to use hostssl?. That could go a
> > long way towards encouraging people.
>
> Debian, which I guess s
Re: Stefan Huehner 2016-07-02 <20160702160042.ga11...@huehner.biz>
> No data at all needed in table.
> In fact just create database + create 3 those objects is enough to reproduce
> it.
Confirmed here on Debian unstable amd64, beta2.
FEHLER: XX000: cache lookup failed for type 0
ORT: get_typle
Re: Andreas Karlsson 2016-07-02
> On 07/01/2016 11:41 AM, Christoph Berg wrote:
> > thanks for the patches. I applied all there patches on top of HEAD
> > (10c0558f). The server builds and passes "make check", pgcrypto still
> > needs work, though:
>
> Thanks
Re: Tom Lane 2016-07-01 <26357.1467400...@sss.pgh.pa.us>
> I made some mostly-cosmetic changes to this and pushed it.
I confirm that Debian's out-of-tree python3 build works now when
invoked directly in the relevant plpython/hstore_plpython
subdirectories. Thanks!
Christoph
--
Sent via pgsql-h
Re: Andreas Karlsson 2016-07-01 <688a438c-ccc2-0431-7100-26e418fc3...@proxel.se>
> Hi,
>
> Here is an initial set of patches related to OpenSSL 1.1. Everything should
> still build fine on older OpenSSL versions (and did when I tested with
> 1.0.2h).
Hi Andreas,
thanks for the patches. I applied
Re: Tom Lane 2016-06-27 <31398.1467036...@sss.pgh.pa.us>
> Bjorn Munch reported off-list that this sequence:
>
> unpack tarball, cd into it
> ./configure ...
> cd src/test/regress
> make
>
> no longer works in 9.6beta2, where it did work in previous releases.
> I have confirmed both statements.
Re: Andreas Karlsson 2016-06-27 <8a0a5959-0b83-3dc8-d9e7-66ce8c1c5...@proxel.se>
> > The errors you report make it sound like they broke API compatibility
> > wholesale. Was that really their intent? If so, where are the changes
> > documented?
>
> I do not see that they have documented the remo
1 - 100 of 312 matches
Mail list logo