Hello
when I checked psql and pset without any arguments patch, I found so only
popt-topt.line_style is initialized to NULL as default. All other popt
variables are not null.
Can we fixed?
Regards
Pavel
Hello
* patch is cleanly patchable and compilation is without warnings
* all regression tests passed
* no impact on dump, performance or any current features
* no comments to programming style
* we would this feature - it is consistent with \set and it gives a fast
resume about psql printer
Thank you for your opinions and ideas.
From: Tom Lane t...@sss.pgh.pa.us
Greg Stark st...@mit.edu writes:
What would be nicer would be to display the C define, EINVAL, EPERM, etc.
Afaik there's no portable way to do that though. I suppose we could just
have a small array or hash table of all
On Thu, Sep 5, 2013 at 12:27 PM, wangs...@highgo.com.cn wrote:
I had committed the patch to the Server Features
(https://commitfest.postgresql.org/action/commitfest_view/open).
Is this right ? If not, please give me more advice,thanks !
Yes this category is fine don't worry.
--
Michael
--
2013/9/7 Kohei KaiGai kai...@kaigai.gr.jp:
2013/9/7 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
I find this a somewhat depressing response. Didn't we discuss this
exact design at the developer meeting in Ottawa? I thought it sounded
reasonable to you then, or at
2) there is only one open question
http://www.postgresql.org/message-id/b6f6fd62f2624c4c9916ac0175d56d880ce00...@jenmbs01.ad.intershop.net
-
there is no clean relation between output and some pset option.
I don't think so Marc' proposal is ideal (these values are not a variables) -
but
On Sat, Sep 07, 2013 at 02:49:54PM +0200, Kohei KaiGai wrote:
2013/9/7 Kohei KaiGai kai...@kaigai.gr.jp:
2013/9/7 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
I find this a somewhat depressing response. Didn't we discuss this
exact design at the developer
On Sat, Sep 7, 2013 at 07:42:55AM +0200, Andres Freund wrote:
On 2013-09-06 23:07:04 -0400, Bruce Momjian wrote:
On Fri, Sep 6, 2013 at 11:00:24PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Thu, Sep 5, 2013 at 05:06:41PM -0400, Bruce Momjian wrote:
Another
2013/9/7 David Fetter da...@fetter.org:
On Sat, Sep 07, 2013 at 02:49:54PM +0200, Kohei KaiGai wrote:
2013/9/7 Kohei KaiGai kai...@kaigai.gr.jp:
2013/9/7 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
I find this a somewhat depressing response. Didn't we discuss
Le 07/09/2013 10:02, Pavel Stehule a écrit :
Hello
* patch is cleanly patchable and compilation is without warnings
* all regression tests passed
* no impact on dump, performance or any current features
* no comments to programming style
* we would this feature - it is consistent with \set
On Sat, Sep 7, 2013 at 10:59:08AM -0400, Bruce Momjian wrote:
My original problem report was November, 2012:
http://www.postgresql.org/message-id/50b3d11f.20...@2ndquadrant.com
and my patch to fix this was July 4. Tom gave me a code snipped to test
PL/pgSQL's handling of record
On Sat, Sep 7, 2013 at 07:34:49AM +0200, Andres Freund wrote:
The idea of using RecentGlobalXmin to see how much _work_ has happened
since the last vacuum is interesting, but it doesn't handle read-only
transactions; I am not sure how they can be tracked. You make a good
point that 5
On Thu, Jan 31, 2013 at 03:49:36PM -0500, Peter Eisentraut wrote:
On 1/9/13 8:56 PM, Tom Lane wrote:
However, it seems to me that this behavior is actually wrong for our
purposes, as it represents a too-literal reading of the spec. The SQL
standard has no concept of privileges on schemas,
On Mon, Jul 15, 2013 at 06:19:27PM -0400, Alvaro Herrera wrote:
Robert Haas escribió:
On Mon, Jul 15, 2013 at 5:59 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Xi Wang escribió:
Intel's icc and PathScale's pathcc compilers optimize away several
overflow checks, since they
On Sat, Sep 07, 2013 at 05:21:31PM +0200, Kohei KaiGai wrote:
2013/9/7 David Fetter da...@fetter.org:
The broad outlines look great.
Do we have any way, at least conceptually, to consider the graph
of the cluster with edges weighted by network bandwidth and
latency?
As postgres_fdw
2013/9/7 Gilles Darold gilles.dar...@dalibo.com
Le 07/09/2013 10:02, Pavel Stehule a écrit :
Hello
* patch is cleanly patchable and compilation is without warnings
* all regression tests passed
* no impact on dump, performance or any current features
* no comments to programming
Hi,
On 2013-09-07 12:50:59 -0400, Bruce Momjian wrote:
That seems very complicated. I think it would be enough to record the
current xid at the time of the vacuum, and when testing for later
vacuums, if that saved xid is earlier than the RecentGlobalXmin, and
there have been no
Should these patches be applied?
I have a copy of the program and was going to take care of this.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 5.9.2013 09:36, Atri Sharma wrote:
On Thu, Sep 5, 2013 at 10:59 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Satoshi Nagayasu wrote:
But, for now, I think we should have a real index for the
statistics data because we already have several index storages,
and it will allow us to
On 5.9.2013 07:29, Alvaro Herrera wrote:
Satoshi Nagayasu wrote:
But, for now, I think we should have a real index for the
statistics data because we already have several index storages, and
it will allow us to minimize read/write operations.
BTW, what kind of index would be preferred
Sent from my iPad
On 08-Sep-2013, at 4:27, Tomas Vondra t...@fuzzy.cz wrote:
On 5.9.2013 09:36, Atri Sharma wrote:
On Thu, Sep 5, 2013 at 10:59 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Satoshi Nagayasu wrote:
But, for now, I think we should have a real index for the
Sent from my iPad
On 08-Sep-2013, at 4:27, Tomas Vondra t...@fuzzy.cz wrote:
On 5.9.2013 09:36, Atri Sharma wrote:
On Thu, Sep 5, 2013 at 10:59 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Satoshi Nagayasu wrote:
But, for now, I think we should have a real index for the
22 matches
Mail list logo
