On 28 January 2013 20:32, Dean Rasheed dean.a.rash...@gmail.com wrote:
In general a format specifier looks like:
%[parameter][flags][width][.precision][length]type
This highlights another problem with the current implementation ---
the '-' flag and the width field need to be parsed
On 29 January 2013 08:19, Dean Rasheed dean.a.rash...@gmail.com wrote:
* The width field is optional, even if the '-' flag is specified. So
'%-s' is perfectly legal and should be interpreted as '%s'. The
current implementation treats it as a width of 0, which is wrong.
Oh, but of course a
On 29.01.2013 04:41, Robert Haas wrote:
On Mon, Jan 28, 2013 at 8:39 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
We already have that MyXactAccessedTempRel global flag. Just checking that
should cover many common cases.
+1 for that. I'm actually unconvinced that we need to do any
Hi Marko,
On Mon, Jan 28, 2013 at 5:01 PM, Marko Tiikkaja pgm...@joh.to wrote:
On 1/28/13 12:14 PM, Jeevan Chalke wrote:
I could not apply the patch with git apply, but able to apply it by patch
-p1 command.
IME that's normal for patches that went through filterdiff. I do: git
diff
On 1/29/13 10:18 AM, Jeevan Chalke wrote:
That's fine. I am not at all pointing that to you. Have a look at this:
Ugh.. I'm sorry, I don't understand how this happened. I manually
looked through all the changes, but somehow this slipped through. Will
have a look this evening.
Regards,
On Tuesday, January 29, 2013 2:53 AM Heikki Linnakangas wrote:
On 28.01.2013 15:39, Amit Kapila wrote:
Rebased the patch as per HEAD.
I don't like the way heap_delta_encode has intimate knowledge of how
the lz compression works. It feels like a violent punch through the
abstraction layers.
On 28.01.2013 23:30, Gurjeet Singh wrote:
On Sat, Jan 26, 2013 at 11:24 PM, Satoshi Nagayasusn...@uptime.jp wrote:
2012/12/21 Gurjeet Singhsingh.gurj...@gmail.com:
The patch is very much what you had posted, except for a couple of
differences due to bit-rot. (i) I didn't have to #define
On Thu, Jan 24, 2013 at 7:04 AM, Hari Babu haribabu.ko...@huawei.com wrote:
On Wed, Jan 23, 2013 11:48 PM, Magnus Hagander wrote:
On Wed, Jan 23, 2013 at 10:18 AM, Hari Babu haribabu.ko...@huawei.com
wrote:
Test scenario to reproduce:
1. Start the server
2. create the user as
On 29.01.2013 11:58, Amit Kapila wrote:
Can there be another way with which current patch code can be made better,
so that we don't need to change the encoding approach, as I am having
feeling that this might not be performance wise equally good.
The point is that I don't want to
On 15 January 2013 20:28, Kohei KaiGai kai...@kaigai.gr.jp wrote:
This patch adds sepgsql support for permission checks equivalent
to the existing SCHEMA USE privilege.
This feature is constructed on new OAT_SCHEMA_SEARCH event
type being invoked around pg_namespace_aclcheck().
Can you
Hi Heikki,
On Mon, Jan 28, 2013 at 2:34 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 23.01.2013 17:30, Robert Haas wrote:
On Wed, Jan 23, 2013 at 4:04 AM, Jeevan Chalke
jeevan.chalke@enterprisedb.**com jeevan.cha...@enterprisedb.com
wrote:
I guess my earlier patch, which
On Tue, Jan 29, 2013 at 04:19:15PM +1100, Josh Berkus wrote:
OK, I had some time to think about this. Basically, we have three
outcomes for pg_ctl start:
server not running and pg_ctl start success
server start failed
server already running
Can't we just assign
2013/1/29 Simon Riggs si...@2ndquadrant.com:
On 15 January 2013 20:28, Kohei KaiGai kai...@kaigai.gr.jp wrote:
This patch adds sepgsql support for permission checks equivalent
to the existing SCHEMA USE privilege.
This feature is constructed on new OAT_SCHEMA_SEARCH event
type being invoked
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Peter Geoghegan peter.geoghega...@gmail.com writes:
I can see the case for fixing this, but I don't feel that it's
particularly important that constraints be uniquely identifiable from
the proposed new errdata fields.
I think that we'll soon be
On 29 January 2013 13:30, Kohei KaiGai kai...@kaigai.gr.jp wrote:
It makes unavailable to control execution of
functions from viewpoint of selinux, and here is no way selinux
to prevent to execute functions defined by other domains, or
others being not permitted.
Also, what we want to do is
On Tuesday, January 29, 2013 3:53 PM Heikki Linnakangas wrote:
On 29.01.2013 11:58, Amit Kapila wrote:
Can there be another way with which current patch code can be made
better,
so that we don't need to change the encoding approach, as I am having
feeling that this might not be performance
On 1/28/13 11:08 PM, Tom Lane wrote:
The issue is that
this definition presupposes that we want to complain about a table or
a domain, never both, because we're overloading both the SCHEMA_NAME
and CONSTRAINT_NAME fields for both purposes. This is annoying in
validateDomainConstraint(),
2013/1/29 Simon Riggs si...@2ndquadrant.com:
On 29 January 2013 13:30, Kohei KaiGai kai...@kaigai.gr.jp wrote:
It makes unavailable to control execution of
functions from viewpoint of selinux, and here is no way selinux
to prevent to execute functions defined by other domains, or
others
Alexander Law exclus...@gmail.com writes:
Please look at the following l10n bug:
http://www.postgresql.org/message-id/502a26f1.6010...@gmail.com
and the proposed patch.
That patch looks entirely unsafe to me. Neither of those functions
should be expected to be able to run when none of our
On 29 January 2013 14:39, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2013/1/29 Simon Riggs si...@2ndquadrant.com:
On 29 January 2013 13:30, Kohei KaiGai kai...@kaigai.gr.jp wrote:
It makes unavailable to control execution of
functions from viewpoint of selinux, and here is no way selinux
to
Hi,
I have tried this patch.
https://commitfest.postgresql.org/action/patch_view?id=1051
2013/01/29 14:48, Peter Eisentraut wrote:
On Mon, 2013-01-07 at 07:14 -0500, Peter Eisentraut wrote:
Here is a patch for psql's \l command to accept patterns, like \d
commands do. While at it, I also
Satoshi Nagayasu sn...@uptime.jp writes:
On Mon, 2013-01-07 at 07:14 -0500, Peter Eisentraut wrote:
Here is a patch for psql's \l command to accept patterns, like \d
BTW, is there any good place to put new regression test for the psql
command? I couldn't find it out.
As far as a test for
Please find attached the complete patch for alter rename rule. I have
followed all the suggestions. Followings things are added in this updated
patch:
1) Disallow alter rename of ON SELECT rules.
2) Remove warning.
3) Varibles are lined up.
4) Used qualified_name instead of
On Sun, Jan 27, 2013 at 11:38 PM, MauMau maumau...@gmail.com wrote:
From: Fujii Masao masao.fu...@gmail.com
On Sun, Jan 27, 2013 at 12:17 AM, MauMau maumau...@gmail.com wrote:
Although you said the fix will solve my problem, I don't feel it will.
The
discussion is about the crash when the
Bruce Momjian br...@momjian.us writes:
pg_upgrade uses that to find out of the server was already running or if
we started it. This is to start the server to remove the
postmaster.pid file. Also, no one has explained how not knowing if -o
options were used was a safe.
What happened to the
On Tue, Jan 29, 2013 at 3:12 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Phil Sorber escribió:
On Mon, Jan 28, 2013 at 11:20 AM, Fujii Masao masao.fu...@gmail.com wrote:
Maybe. But I'm not inclined to add new libpq interface at this stage.
Because we are in the last CommitFest and I'm
2013/1/27 Tom Lane t...@sss.pgh.pa.us:
Peter Geoghegan peter.geoghega...@gmail.com writes:
On 26 January 2013 22:36, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, one thing that struck me in a quick look-through is that the
ERRCODE_FOREIGN_KEY_VIOLATION patches seem to inconsistently send
either
On Mon, Jan 28, 2013 at 6:19 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Christopher Browne cbbro...@gmail.com writes:
I'm poking at event triggers a bit; would like to set up some examples
(and see if they
work, or break down badly; both are interesting results) to do some
validation
2013/1/28 Peter Geoghegan peter.geoghega...@gmail.com:
On 28 January 2013 21:33, Peter Eisentraut pete...@gmx.net wrote:
Another point, in case someone wants to revisit this in the future, is
that these fields were applied in a way that is contrary to the SQL
standard, I think.
The presented
On 29 January 2013 17:05, Pavel Stehule pavel.steh...@gmail.com wrote:
Perhaps I'm mistaken, but I can't imagine that it would be terribly
useful to anyone (including Pavel) to have a GET DIAGNOSTICS style
ROUTINE_NAME.
I hoped so I can use it inside exception handler
Right, but is that
2013/1/28 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2013/1/28 Dean Rasheed dean.a.rash...@gmail.com:
Starting with the first patch - it issues a new WARNING if the format
string contains a mixture of format specifiers with and without
parameter indexes (e.g.,
2013/1/28 Tom Lane t...@sss.pgh.pa.us:
Dean Rasheed dean.a.rash...@gmail.com writes:
On 28 January 2013 20:40, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/1/28 Dean Rasheed dean.a.rash...@gmail.com:
flags - not currently implemented. Pavel's second patch adds support
for the '-' flag
2013/1/29 Dean Rasheed dean.a.rash...@gmail.com:
On 28 January 2013 20:32, Dean Rasheed dean.a.rash...@gmail.com wrote:
In general a format specifier looks like:
%[parameter][flags][width][.precision][length]type
This highlights another problem with the current implementation ---
the '-'
2013/1/29 Peter Geoghegan peter.geoghega...@gmail.com:
On 29 January 2013 17:05, Pavel Stehule pavel.steh...@gmail.com wrote:
Perhaps I'm mistaken, but I can't imagine that it would be terribly
useful to anyone (including Pavel) to have a GET DIAGNOSTICS style
ROUTINE_NAME.
I hoped so I can
I wrote:
Rather what we've got is that constraints are uniquely named among
those associated with a table, or with a domain. So the correct
unique key for a table constraint is table schema + table name +
constraint name, whereas for a domain constraint it's domain schema +
domain name +
Heikki Linnakangas wrote:
Tolerate timeline switches while pg_basebackup -X fetch is running.
I just noticed that this commit introduced a few error messages that
have a file argument which is not properly quoted:
+ ereport(ERROR,
+ (errcode_for_file_access(),
+
Robert Haas escribió:
On Tue, Jan 15, 2013 at 3:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Or perhaps there is some other way to make sure that the user really
meant it, like refusing to create in pg_catalog unless the schema
name is given
On 1/28/13 9:29 PM, Bruce Momjian wrote:
pg_upgrade uses that to find out of the server was already running or if
we started it. This is to start the server to remove the
postmaster.pid file.
It's currently a bit missed up anyway. pg_ctl start is successful if
the server is already started,
On Tue, Jan 29, 2013 at 04:34:50PM -0500, Peter Eisentraut wrote:
On 1/28/13 9:29 PM, Bruce Momjian wrote:
pg_upgrade uses that to find out of the server was already running or if
we started it. This is to start the server to remove the
postmaster.pid file.
It's currently a bit missed
I wrote:
Here's an updated patch (code only, sans documentation) that fixes that
and adds some other refactoring that I thought made for improvements.
I think this is ready to commit except for the documentation.
Pushed with documentation.
regards, tom lane
--
Sent
On Tue, Jan 29, 2013 at 2:30 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Robert Haas escribió:
On Tue, Jan 15, 2013 at 3:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Or perhaps there is some other way to make sure that the user really
meant it,
Christopher Browne cbbro...@gmail.com writes:
Hmm. I think some information about the object is pretty needful.
For the immediate case I'm poking at, namely looking for dropped tables,I
could determine that which object is gone by inference; if I run the trigger
as part of the
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 29, 2013 at 2:30 PM, Alvaro Herrera
Robert, are you working on this?
I wasn't, but I can, if we agree on it.
I think we need to do *something* (and accordingly have added this to
the 9.3 open items page so we don't forget about it).
All,
It's perhaps not the ideal time for a discussion but if I thought it would
turn into a long discussion then I'd probably not post this due to the
current timing in the release cycle.
This is something I thought of while doing a restore on a 40ish GB database
which has a few hundred smallish
Hi,
Please find attached v2 of the Extension Templates patch, with pg_dump
support and assorted fixes. It's still missing ALTER RENAME and OWNER
facilities, and owner in the dump. There's a design point I want to
address with some input before getting there, though. Hence this email.
Dimitri
On 01/29/2013 10:10 PM, Simon Riggs wrote:
On 29 January 2013 13:30, Kohei KaiGai kai...@kaigai.gr.jp wrote:
It makes unavailable to control execution of
functions from viewpoint of selinux, and here is no way selinux
to prevent to execute functions defined by other domains, or
others being
David Rowley dgrowle...@gmail.com writes:
If pg_dump was to still follow the dependencies of objects, would there be
any reason why it shouldn't backup larger tables first?
Pretty much every single discussion/complaint about pg_dump's ordering
choices has been about making its behavior more
I wrote:
Over in the thread about enhanced error fields, I claimed that
constraints are uniquely named among those associated with a table,
or with a domain. But it turns out that that ain't necessarily so,
because the code path for index constraints doesn't pay any attention
to pre-existing
On Fri, Jan 25, 2013 at 11:28:58PM -0500, Bruce Momjian wrote:
On Fri, Jan 25, 2013 at 11:08:56PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
! ereport(ERROR,
!
On Tue, Jan 29, 2013 at 09:54:04AM -0500, Tom Lane wrote:
Alexander Law exclus...@gmail.com writes:
Please look at the following l10n bug:
http://www.postgresql.org/message-id/502a26f1.6010...@gmail.com
and the proposed patch.
That patch looks entirely unsafe to me. Neither of those
On Mon, Jan 28, 2013 at 07:24:04PM +0530, Pavan Deolasee wrote:
On Wed, Jan 23, 2013 at 10:05 AM, Noah Misch n...@leadboat.com wrote:
You're the second commentator to be skittish about the patch's correctness,
so
I won't argue against a conservatism-motivated bounce of the patch.
Can
(2013/01/30 0:34), Tom Lane wrote:
Satoshi Nagayasu sn...@uptime.jp writes:
On Mon, 2013-01-07 at 07:14 -0500, Peter Eisentraut wrote:
Here is a patch for psql's \l command to accept patterns, like \d
BTW, is there any good place to put new regression test for the psql
command? I couldn't
Satoshi Nagayasu sn...@uptime.jp writes:
First of all, I was looking for some regression tests for
CREATE/ALTER/DROP DATABASE commands, but I couldn't find them
in the test/regress/sql/ directory. So, I asked the question.
I guess these database tests are in pg_regress.c. Right?
Yeah, we
On Wed, 2013-01-16 at 14:35 +0530, Jeevan Chalke wrote:
However, I think you need to add this in docs. Letting people know
about this environment variable to make use of that.
Done and committed. Thanks.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
I don't think I like --force because it isn't clear if we are forcing
the start to have done something, or forcing the server to be running.
Do we need this idempotent feature for stop too?
Yes, of course.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via
30.01.2013 05:51, Noah Misch wrote:
On Tue, Jan 29, 2013 at 09:54:04AM -0500, Tom Lane wrote:
Alexander Law exclus...@gmail.com writes:
Please look at the following l10n bug:
http://www.postgresql.org/message-id/502a26f1.6010...@gmail.com
and the proposed patch.
That patch looks entirely
Hi Marko,
On Wed, Jan 30, 2013 at 2:07 AM, Marko Tiikkaja pgm...@joh.to wrote:
On Tue, 29 Jan 2013 10:18:51 +0100, Jeevan Chalke
jeevan.chalke@enterprisedb.**com jeevan.cha...@enterprisedb.com wrote:
That's fine. I am not at all pointing that to you. Have a look at this:
Here's the
57 matches
Mail list logo
