On 28 January 2013 20:32, Dean Rasheed 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 separately. So
'%-3s' should be
On 29 January 2013 08:19, Dean Rasheed 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 width of 0 is the same a
On 29.01.2013 04:41, Robert Haas wrote:
On Mon, Jan 28, 2013 at 8:39 AM, Heikki Linnakangas
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 better
than that in gene
Hi Marko,
On Mon, Jan 28, 2013 at 5:01 PM, Marko Tiikkaja 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 |filte
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 l
On 28.01.2013 23:30, Gurjeet Singh wrote:
On Sat, Jan 26, 2013 at 11:24 PM, Satoshi Nagayasu wrote:
2012/12/21 Gurjeet Singh:
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
MAX_RANDOM_VALUE64
since its cousin
On Thu, Jan 24, 2013 at 7:04 AM, Hari Babu wrote:
> On Wed, Jan 23, 2013 11:48 PM, Magnus Hagander wrote:
>>On Wed, Jan 23, 2013 at 10:18 AM, Hari Babu
> wrote:
>>> Test scenario to reproduce:
>>> 1. Start the server
>>> 2. create the user as follows
>>> ./psql pos
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 heap_delta_enc
On 15 January 2013 20:28, Kohei KaiGai 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 explain the exact d
Hi Heikki,
On Mon, Jan 28, 2013 at 2:34 PM, Heikki Linnakangas wrote:
> On 23.01.2013 17:30, Robert Haas wrote:
>
>> On Wed, Jan 23, 2013 at 4:04 AM, Jeevan Chalke
>> >
>> wrote:
>>
>>> I guess my earlier patch, which was directly incrementing
>>>
>>> ControlFile->unloggedLSN counter was the c
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
2013/1/29 Simon Riggs :
> On 15 January 2013 20:28, Kohei KaiGai 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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Geoghegan 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 buried in gripes if the
On 29 January 2013 13:30, Kohei KaiGai 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 almost same as
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 perf
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 :
> On 29 January 2013 13:30, Kohei KaiGai 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
Alexander Law 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 standard
infrastruct
On 29 January 2013 14:39, Kohei KaiGai wrote:
> 2013/1/29 Simon Riggs :
>> On 29 January 2013 13:30, Kohei KaiGai 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 dom
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 add
Satoshi Nagayasu 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 this specifi
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 makeRangeVarFromAnyName.
On Sun, Jan 27, 2013 at 11:38 PM, MauMau wrote:
> From: "Fujii Masao"
>>
>> On Sun, Jan 27, 2013 at 12:17 AM, MauMau wrote:
>>>
>>> Although you said the fix will solve my problem, I don't feel it will.
>>> The
>>> discussion is about the crash when the standby "re"starts after the
>>> primary
>
Bruce Momjian 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 plan for pg_up
On Tue, Jan 29, 2013 at 3:12 AM, Alvaro Herrera
wrote:
> Phil Sorber escribió:
>> On Mon, Jan 28, 2013 at 11:20 AM, Fujii Masao 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 not sure whether
>> > we have enough
2013/1/27 Tom Lane :
> Peter Geoghegan writes:
>> On 26 January 2013 22:36, Tom Lane 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 the PK or FK rel as the "errtable". Is this really pe
On Mon, Jan 28, 2013 at 6:19 PM, Dimitri Fontaine
wrote:
> Christopher Browne 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 of schema
>> for Slony.
>
> Cool
2013/1/28 Peter Geoghegan :
> On 28 January 2013 21:33, Peter Eisentraut 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 patch interpreted ROUTINE_NAME
On 29 January 2013 17:05, Pavel Stehule 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 really any use to yo
2013/1/28 Tom Lane :
> Pavel Stehule writes:
>> 2013/1/28 Dean Rasheed :
>>> 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., 'Hello %s, %1$s').
>>>
>>> Having thought about it a b
2013/1/28 Tom Lane :
> Dean Rasheed writes:
>> On 28 January 2013 20:40, Pavel Stehule wrote:
>>> 2013/1/28 Dean Rasheed :
flags - not currently implemented. Pavel's second patch adds support
for the '-' flag for left justified string output. However, I think
this should support al
2013/1/29 Dean Rasheed :
> On 28 January 2013 20:32, Dean Rasheed 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 pa
2013/1/29 Peter Geoghegan :
> On 29 January 2013 17:05, Pavel Stehule 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
>
> R
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 wrote:
> > Robert Haas 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 explicitly. I kind of like that i
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
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
--
Sen
On Tue, Jan 29, 2013 at 2:30 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Tue, Jan 15, 2013 at 3:22 PM, Tom Lane wrote:
>> > Robert Haas 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 th
Christopher Browne 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 ddl_command_end event, then
Robert Haas 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). Whether Robert's
idea i
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 t
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 Font
On 01/29/2013 10:10 PM, Simon Riggs wrote:
> On 29 January 2013 13:30, Kohei KaiGai 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 permit
"David Rowley" 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 deterministic not le
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-ex
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 writes:
> > > ! ereport(ERROR,
> > > !
> > > (ERRCODE_OBJECT_NOT_IN_PREREQUI
On Tue, Jan 29, 2013 at 09:54:04AM -0500, Tom Lane wrote:
> Alexander Law 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
> sh
On Mon, Jan 28, 2013 at 07:24:04PM +0530, Pavan Deolasee wrote:
> On Wed, Jan 23, 2013 at 10:05 AM, Noah Misch 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 you plea
(2013/01/30 0:34), Tom Lane wrote:
> Satoshi Nagayasu 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
Satoshi Nagayasu 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 don't bother wi
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 change
>>> 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 vi
30.01.2013 05:51, Noah Misch wrote:
On Tue, Jan 29, 2013 at 09:54:04AM -0500, Tom Lane wrote:
Alexander Law 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 o
Hi Marko,
On Wed, Jan 30, 2013 at 2:07 AM, Marko Tiikkaja wrote:
> On Tue, 29 Jan 2013 10:18:51 +0100, Jeevan Chalke <
> jeevan.chalke@enterprisedb.**com > wrote:
>
>> That's fine. I am not at all pointing that to you. Have a look at this:
>>
>
> Here's the third version of this patch, hopefull
57 matches
Mail list logo
