On Mon, Jan 24, 2011 at 13:05, Stephen Frost wrote:
> FOR var in ARRAY array_expression ...
>
> I like that a lot more than inventing a new top-level keyword,
AFAIR, the syntax is not good at an array literal.
FOR var IN ARRAY ARRAY[1,2,5] LOOP ...
And it was the only drawback compared with FOR
Itagaki Takahiro writes:
> Since pg_dump won't dump user objects in pg_catalog, adminpack can
> avoid the above errors by installing functions in pg_catalog.
> CREATE EXTENSION might have the same issue -- Can EXTENSION work
> without errors when we install extensions in template databases?
Well
On Wed, 2011-01-26 at 13:14 +0900, Fujii Masao wrote:
> When log_checkpoints is enabled, checkpoint logs the number of
> WAL files created/deleted/recycled, but restartpoint doesn't.
> This is OK before 9.0 because restartpoint had never created/
> deleted/recycled WAL files. But, in 9.0 or later,
On Mon, 2011-01-24 at 09:29 +0200, Heikki Linnakangas wrote:
> On 24.01.2011 03:48, Kevin Grittner wrote:
> > If I get a solid answer on the SSI/HS issue before I post V14, I
> > might be able to cover that, too, in that patch. I haven't wanted to
> > totally write off the possibility of integrati
On Mon, 2011-01-24 at 18:43 -0800, Richard Broersma wrote:
> We have the funding. We're looking for mentors. Next we'll just
> about ready to open the application process. But I'd expect several
> weeks to pass before have ready to look at applicants.
You're paying the reviewers; are you payin
On Tue, 2011-01-25 at 11:15 -0800, Josh Berkus wrote:
> > However, having a mentee begin work early in the 9.2 commit-fest cycle
> > might be advantageous. I imagine that there is less pressure to review
> > all of the patches in the early commit-fests. Perhaps this will give
> > prospective ment
I recently started getting these:
plpython.c: In function ‘PLy_output’:
plpython.c:3468: warning: format not a string literal and no format arguments
plpython.c: In function ‘PLy_elog’:
plpython.c:3620: warning: format not a string literal and no format arguments
plpython.c:3627: warning: format n
On Wed, Jan 26, 2011 at 6:15 AM, Simon Riggs wrote:
> Many people are contributing patches for free. Will those people get
> paid to fix their own bugs? I guess they might well be better at finding
> and fixing them than others, so it is an interesting question.
I remember hearing about a case wh
On Mon, 2011-01-24 at 21:30 -0600, Kevin Grittner wrote:
> Dan and I have spent many, many hours desk-check and testing,
> including pounding for many hours in DBT-2 at high concurrency
> factors on a 16 processor box. In doing so, we found and fixed a few
> issues. Neither of us is aware of any b
On Tue, Jan 25, 2011 at 10:22 PM, Noah Misch wrote:
> I'm fine with this patch.
OK, committed.
> The next patch removed new_changeoids, so we would instead be keeping it with
> this as the only place referencing it.
[...]
> The at2v2 patch would then morph to do something like:
>
> if (worklevel
On Wed, 2011-01-26 at 11:36 +, Simon Riggs wrote:
> Pounding for hours on 16 CPU box sounds good. What diagnostics or
> instrumentation are included with the patch? How will we know whether
> pounding for hours is actually touching all relevant parts of code? I've
> done such things myself onl
On Wed, Jan 26, 2011 at 6:14 AM, Tom Lane wrote:
> Gurjeet Singh writes:
> > Attached is the updated patch with doc changes and test cases.
>
> Applied with assorted corrections. Aside from the refactoring I wanted,
> there were various oversights.
>
Looking at the commit, the committed patch
Simon Riggs writes:
> Not sure how to handle that. My understanding is that we are replacing
> the old Serializable mode with the new Serializable mode. The old way
> works, but the new way doesn't. I don't think we should throw an error;
> we just need to document that it works the old way on HS
On Wed, 2011-01-26 at 14:27 +0100, Dimitri Fontaine wrote:
> Simon Riggs writes:
> > Not sure how to handle that. My understanding is that we are replacing
> > the old Serializable mode with the new Serializable mode. The old way
> > works, but the new way doesn't. I don't think we should throw an
On Mon, Jan 24, 2011 at 11:13 PM, Noah Misch wrote:
>> > This helps on conversions like varchar(4)->varchar(8) and text->xml.
>>
>> I've read through this patch somewhat. As I believe Tom also
>> commented previously, exemptor is a pretty bad choice of name.
>
> I spent awhile with a thesaurus be
Robert Haas wrote:
> I recently started getting these:
>
> plpython.c: In function ?PLy_output?:
> plpython.c:3468: warning: format not a string literal and no format arguments
> plpython.c: In function ?PLy_elog?:
> plpython.c:3620: warning: format not a string literal and no format arguments
> p
Simon Riggs wrote:
> So in the Compatibility release notes for 9.1 we should say:
>
> "Applications that request SERIALIZABLE mode will now experience
> different and fully correct behaviour. The new mode does not
> currently work in Hot Standby mode, and an error will be returned
> if this is
On Wed, Jan 26, 2011 at 3:12 AM, Simon Riggs wrote:
> > We have the funding. We're looking for mentors. Next we'll just
> > about ready to open the application process. But I'd expect several
> > weeks to pass before have ready to look at applicants.
>
> You're paying the reviewers; are you
Heikki Linnakangas wrote:
> On 25.01.2011 22:53, Kevin Grittner wrote:
>> Is there somewhere you would like to
>> see that argument documented?
>
> README-SSI .
Done (borrowing some of your language).
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=470abc51c5626c
2011/1/25 KaiGai Kohei :
> (2011/01/26 12:23), KaiGai Kohei wrote:
Yikes. On further examination, exec_object_restorecon() is pretty
bogus. Surely you need some calls to quote_literal_cstr() in there
someplace.
>>>
>> Are you concerning about the object name being supplied to
>> se
Dimitri Fontaine writes:
> The missing entry in pg_depend is the reason why the extension is not
> part of the dump. We could fix that using a LEFT JOIN here and COALESCE
> to force the namespace as pg_catalog. Is that not a kludge?
Yes, it is. Why is the pg_depend entry missing?
Robert Haas writes:
> Remove arbitrary ALTER TABLE .. ADD COLUMN restriction.
> The previous coding prevented ALTER TABLE .. ADD COLUMN from being used
> with a non-NULL default in situations where the table's rowtype was being
> used elsewhere. But this is a completely arbitrary restriction sinc
On Mon, Jan 24, 2011 at 12:17:16PM -0800, Richard Broersma wrote:
> PgUS is preparing to fund a grant for PgUS members to learn and
> participate in the patch review process. We looking for experienced
> reviewers that can assist a candidate through to process of testing a
> patch - to submitting
Tom Lane writes:
> Dimitri Fontaine writes:
>> The missing entry in pg_depend is the reason why the extension is not
>> part of the dump. We could fix that using a LEFT JOIN here and COALESCE
>> to force the namespace as pg_catalog. Is that not a kludge?
>
> Yes, it is. Why is the pg_depend e
On Wed, Jan 26, 2011 at 10:36 AM, Tom Lane wrote:
> Robert Haas writes:
>> Remove arbitrary ALTER TABLE .. ADD COLUMN restriction.
>> The previous coding prevented ALTER TABLE .. ADD COLUMN from being used
>> with a non-NULL default in situations where the table's rowtype was being
>> used elsewh
On Wed, Jan 26, 2011 at 7:38 AM, David Fetter wrote:
> I'm thinking that we should consider *very* carefully before we
> introduce payments into what had been an all-volunteer effort. You
> may get people to do things they might not otherwise have done, but
> you'll also make people wonder whet
Simon Riggs wrote:
> On Wed, 2011-01-26 at 11:36 +, Simon Riggs wrote:
>
>> Pounding for hours on 16 CPU box sounds good. What diagnostics or
>> instrumentation are included with the patch? How will we know
>> whether pounding for hours is actually touching all relevant
>> parts of code? I've
Robert Haas writes:
> On Wed, Jan 26, 2011 at 10:36 AM, Tom Lane wrote:
>> This is not an "arbitrary restriction" because according to the SQL
>> standard those operations mean different things. In the first case you
>> get a column filled with the default value, in the second case you get a
>>
On 1/24/2011 7:02 PM, Tom Lane wrote:
Given where we've ended up on what we want printed, I'm forced to
conclude that there is basically nothing usable in the submitted patch.
I personally feel that if we could even add this for explicit Filter
conditions, people would be a lot happier. While
Everybody,
I'm interested in the query optimizer of PostgreSQL DB. Where could I
find useful documentation or could you send me a pointer in the source code?
What kind of parallelism does PostgreSQL use for operators, like
selection or join?
Thank you
- felix
--
Sent via pgsql-hackers mailing
Excerpts from Simon Riggs's message of mié ene 26 10:40:28 -0300 2011:
> So in the Compatibility release notes for 9.1 we should say:
>
> "Applications that request SERIALIZABLE mode will now experience
> different and fully correct behaviour. The new mode does not currently
> work in Hot Standby
Marko Tiikkaja writes:
> On 1/24/2011 7:02 PM, Tom Lane wrote:
>> Given where we've ended up on what we want printed, I'm forced to
>> conclude that there is basically nothing usable in the submitted patch.
> I personally feel that if we could even add this for explicit Filter
> conditions, peop
For those of you using git, I wanted to point out that it is fairly easy
to remove git branches. For example, I can easily remove a branch on
my github repository using:
$ git branch -d :branch_name
I don't believe that is revertable. What is scarey is that this could
be done on our 'or
On Wed, Jan 26, 2011 at 11:26:04AM -0500, Bruce Momjian wrote:
> For those of you using git, I wanted to point out that it is fairly easy
> to remove git branches. For example, I can easily remove a branch on
> my github repository using:
>
> $ git branch -d :branch_name
>
> I don't believ
On Wed, Jan 26, 2011 at 11:05 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jan 26, 2011 at 10:36 AM, Tom Lane wrote:
>>> This is not an "arbitrary restriction" because according to the SQL
>>> standard those operations mean different things. In the first case you
>>> get a column filled
On 01/26/2011 11:26 AM, Bruce Momjian wrote:
For those of you using git, I wanted to point out that it is fairly easy
to remove git branches. For example, I can easily remove a branch on
my github repository using:
$ git branch -d :branch_name
I don't believe that is revertable. Wha
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Wed, Jan 26, 2011 at 11:26:04AM -0500, Bruce Momjian wrote:
> > For those of you using git, I wanted to point out that it is fairly easy
> > to remove git branches. For example, I can easily remove a branch on
> > my github reposit
On Wed, Jan 26, 2011 at 11:26 AM, Bruce Momjian wrote:
> For those of you using git, I wanted to point out that it is fairly easy
> to remove git branches. For example, I can easily remove a branch on
> my github repository using:
>
> $ git branch -d :branch_name
>
> I don't believe that i
Andrew Dunstan wrote:
>
>
> On 01/26/2011 11:26 AM, Bruce Momjian wrote:
> > For those of you using git, I wanted to point out that it is fairly easy
> > to remove git branches. For example, I can easily remove a branch on
> > my github repository using:
> >
> > $ git branch -d :branch_name
Robert Haas writes:
> It's certainly not obvious from the archives from around 2004-06-06
> that this was discussed. Perhaps you could be a bit more specific.
> As for the spec, if it requires composite types to have defaults (or
> constraints), then we're in violation of that all over the place
Robert Haas wrote:
> On Wed, Jan 26, 2011 at 11:26 AM, Bruce Momjian wrote:
> > For those of you using git, I wanted to point out that it is fairly easy
> > to remove git branches. ?For example, I can easily remove a branch on
> > my github repository using:
> >
> > ? ? ? ?$ git branch -d :branch_
On Wed, Jan 26, 2011 at 11:49 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Wed, Jan 26, 2011 at 11:26 AM, Bruce Momjian wrote:
>> > For those of you using git, I wanted to point out that it is fairly easy
>> > to remove git branches. ?For example, I can easily remove a branch on
>> > my gi
Robert Haas wrote:
> On Wed, Jan 26, 2011 at 11:49 AM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Wed, Jan 26, 2011 at 11:26 AM, Bruce Momjian wrote:
> >> > For those of you using git, I wanted to point out that it is fairly easy
> >> > to remove git branches. ?For example, I can easily
Simon Riggs wrote:
> I looked at the patch to begin a review and immediately saw
> "dtest". There's no docs to explain what it is, but a few comments
> fill me in a little more. Can we document that please? And/or
> explain why its an essential part of this commit? Could we keep it
> out of core
Dimitri Fontaine writes:
> Tom Lane writes:
>> Dimitri Fontaine writes:
>>> The missing entry in pg_depend is the reason why the extension is not
>>> part of the dump. We could fix that using a LEFT JOIN here and COALESCE
>>> to force the namespace as pg_catalog. Is that not a kludge?
>> Yes,
Alvaro Herrera wrote:
> Also, perhaps
>
> errmsg("cannot use serializable mode in a hot standby"),
> errhint("You can use REPEATABLE READ instead.")
OK:
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=0950b11c91aecbbe490ec06205235d60fcd90a2e
-Kevin
--
Sent
On Jan 26, 2011, at 7:48 AM, Richard Broersma wrote:
> On Wed, Jan 26, 2011 at 7:38 AM, David Fetter wrote:
>
>> I'm thinking that we should consider *very* carefully before we
>> introduce payments into what had been an all-volunteer effort. You
>> may get people to do things they might not o
On Wed, Jan 26, 2011 at 9:31 AM, David E. Wheeler wrote:
> Part of GCOC's success has been in allowing a class of people to
> participate who otherwise would have had to get summer jobs flipping
> burgers.
>
This is essentially the idea for this grant, to fund a person in learning a
new skill.
On Wed, Jan 26, 2011 at 11:47 AM, Tom Lane wrote:
> Robert Haas writes:
>> It's certainly not obvious from the archives from around 2004-06-06
>> that this was discussed. Perhaps you could be a bit more specific.
>> As for the spec, if it requires composite types to have defaults (or
>> constrai
On Jan 26, 2011, at 9:40 AM, Richard Broersma wrote:
> On Wed, Jan 26, 2011 at 9:31 AM, David E. Wheeler
> wrote:
>> Part of GCOC's success has been in allowing a class of people to
>> participate who otherwise would have had to get summer jobs flipping
>> burgers.
>>>
>>
>
> This is esse
On Wed, Jan 26, 2011 at 12:07 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Wed, Jan 26, 2011 at 11:49 AM, Bruce Momjian wrote:
>> > Robert Haas wrote:
>> >> On Wed, Jan 26, 2011 at 11:26 AM, Bruce Momjian wrote:
>> >> > For those of you using git, I wanted to point out that it is fairly e
Robert Haas writes:
> ... A side issue is that I really
> want to avoid adding a new parser keyword for this. It doesn't bother
> me too much to add keywords for really important and user-visible
> features, but when we're adding stuff that's only going to be used by
> 0.1% of our users it's real
Greetings,
I was thinking about an old 2007 topic, where schema
qualification was proposed on the EXPLAIN output
(http://archives.postgresql.org/pgsql-
hackers/2007-06/msg00473.php).
Besides my need for this "feature" for my own PgFoundry
project (that need to parse the explain output), at th
Greetings,
I was thinking about an old 2007 topic, where schema
qualification was proposed on the EXPLAIN output
(http://archives.postgresql.org/pgsql-
hackers/2007-06/msg00473.php).
Besides my need for this "feature" for my own PgFoundry
project (that need to parse the explain output), at th
On 26.01.2011 17:00, Kevin Grittner wrote:
Simon Riggs wrote:
So in the Compatibility release notes for 9.1 we should say:
"Applications that request SERIALIZABLE mode will now experience
different and fully correct behaviour. The new mode does not
currently work in Hot Standby mode, and an e
Heikki Linnakangas wrote:
> By all means, feel free to add a note to the docs about this. A
> note in the Hot Standby Caveats section would be good, in addition
> to somewhere in the chapter about isolation levels.
OK, will do.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
Robert Haas writes:
> Saying "we're not doing all that well" with it is an understatement.
> We're not doing it at all, except apparently for this one place.
Yeah, it's mostly broken. That doesn't mean we should introduce more
breakage in order to gain no meaningful functionality.
> Your
> clai
On Wed, Jan 26, 2011 at 3:12 AM, Simon Riggs wrote:
> You're paying the reviewers; are you paying the mentors?
>
The answer to this question is that we can fund mentor (teacher). However,
the amount to fund a mentor would be significantly less that the amount to
fund a reviewer (student). The
On Sat, Jan 15, 2011 at 15:48, Alex Hunsaker wrote:
> On Wed, Jan 12, 2011 at 13:04, Alexey Klyukin wrote:
>>
>> On Jan 12, 2011, at 8:52 PM, David E. Wheeler wrote:
>>
>>> On Jan 12, 2011, at 5:14 AM, Alexey Klyukin wrote:
>>>
You mean packing both a string representation and a reference to
Tom Lane writes:
> OK, so I guess I'm missing why the extension code is looking for stuff
> dependent on the pg_catalog schema. That schema certainly doesn't
> belong to any extension.
Exactly. We're on the same page here, full agreement. So the extension
patch is not considering pg_catalog in
Kevin,
thanks for your heads-up.
On 01/26/2011 06:07 PM, Kevin Grittner wrote:
> Simon Riggs wrote:
>
>> I looked at the patch to begin a review and immediately saw
>> "dtest". There's no docs to explain what it is, but a few comments
>> fill me in a little more. Can we document that please? A
Excerpts from Robert Haas's message of mié ene 26 14:43:08 -0300 2011:
> For those following along at home who may wish to express an opinion,
> perhaps a brief review of the behavior change we're arguing about will
> be helpful. Prior to this patch, if foo was used as a type in some
> other tabl
Alvaro Herrera wrote:
> If you really want to do what you seem to want (i.e. add a column
> with a default and not have it alter existing rows), you can
> already do it like this:
>
> ALTER TABLE foo ADD COLUMN bar INTEGER, ALTER COLUMN bar SET
> DEFAULT 5;
>
> If there's an intention to impro
On Wed, 2011-01-26 at 11:07 -0600, Kevin Grittner wrote:
> > When this runs in production, how will we know whether SSI is
> > stuck
>
> Stuck? I'm not sure what you mean by that. Other than LW locking
> (which I believe is always appropriately brief, with rules for order
> of acquisition whic
Heikki Linnakangas wrote:
> By all means, feel free to add a note to the docs about this. A
> note in the Hot Standby Caveats section would be good, in addition
> to somewhere in the chapter about isolation levels.
Here's what I came up with:
http://git.postgresql.org/gitweb?p=users/kgrittn/
On Wed, Jan 26, 2011 at 1:32 PM, Richard Broersma
wrote:
> On Wed, Jan 26, 2011 at 3:12 AM, Simon Riggs wrote:
>> You're paying the reviewers; are you paying the mentors?
>
> The answer to this question is that we can fund mentor (teacher). However,
> the amount to fund a mentor would be signifi
"Kevin Grittner" wrote:
> Suggested changes?
I see that Heikki suggested that the change to the hot standby docs
belonged in the Caveats section. Will change that note to a bullet
point under Caveats.
Sorry I didn't catch that sooner.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql
On Wed, Jan 26, 2011 at 12:47 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... A side issue is that I really
>> want to avoid adding a new parser keyword for this. It doesn't bother
>> me too much to add keywords for really important and user-visible
>> features, but when we're adding stuff that
Excerpts from Kevin Grittner's message of mié ene 26 14:07:18 -0300 2011:
> Simon Riggs wrote:
> > Pounding for hours on 16 CPU box sounds good. What diagnostics or
> > instrumentation are included with the patch? How will we know
> > whether pounding for hours is actually touching all relevant p
Dimitri Fontaine writes:
> So in his tests, Itagaki was tempted to issue the following statement:
> CREATE EXTENSION adminpack WITH SCHEMA pg_catalog;
> That's supposed to register a dependency from the extension to its
> declared hosting schema (adminpack is not relocatable so that entirely
>
Cristiano Duarte writes:
> I was thinking about an old 2007 topic, where schema
> qualification was proposed on the EXPLAIN output
> (http://archives.postgresql.org/pgsql-
> hackers/2007-06/msg00473.php).
> Besides my need for this "feature" for my own PgFoundry
> project (that need to parse
Alvaro Herrera wrote:
> BTW did you try "make coverage" and friends? See
> http://www.postgresql.org/docs/9.0/static/regress-coverage.html
> and
> http://developer.postgresql.org/~petere/coverage/
I had missed that; thanks for pointing it out!
I'm doing a coverage build now, to see what cov
Hi,
On Jan 26, 2011, at 8:45 PM, Alex Hunsaker wrote:
> On Sat, Jan 15, 2011 at 15:48, Alex Hunsaker wrote:
>> On Wed, Jan 12, 2011 at 13:04, Alexey Klyukin
>> wrote:
>>>
>>> On Jan 12, 2011, at 8:52 PM, David E. Wheeler wrote:
>>>
On Jan 12, 2011, at 5:14 AM, Alexey Klyukin wrote:
Dimitri Fontaine writes:
> We could use get_extension_namespace() just after recoding the
> dependency and error out if we don't find the arguments we gave to
> recordDependencyOn() so that we're not duplicating code. That will
> cover any pinned schema. I'm preparing a patch to do that.
Kids a
"David E. Wheeler" writes:
> I think M. Fetter is completely wrong. If people are rethinking
> whether they should volunteer based on whether other people are being
> funded for their time to review patches, we don't want such people
> around anyway. Let them leave.
I can see his concern though:
Tom Lane writes:
> Mph. Although such an extension should certainly carry a dependency on
> the schema it's using, I'm not sure that it makes sense to consider that
> the extension (as opposed to its contained objects) belongs to the
> schema. If we think that extensions live inside schemas then
On Wed, Jan 26, 2011 at 11:15 AM, Robert Haas wrote:
> Usually, in an educational process, it's the teachers who get paid,
> and the students who have to pay to get educated. I realize this is
> somewhat different because we want to encourage people to get involved
> in the project, but it stil
On Wed, Jan 26, 2011 at 12:44, Alexey Klyukin wrote:
> Hi,
>
> On Jan 26, 2011, at 8:45 PM, Alex Hunsaker wrote:
>
>> On Sat, Jan 15, 2011 at 15:48, Alex Hunsaker wrote:
>>> On Wed, Jan 12, 2011 at 13:04, Alexey Klyukin
>>> wrote:
On Jan 12, 2011, at 8:52 PM, David E. Wheeler wrote:
>
Robert Haas writes:
> On Wed, Jan 26, 2011 at 12:47 PM, Tom Lane wrote:
>> If you didn't mind inverting the sense of the result
>> then we could use "EXECUTE IF function_name".
> What about borrowing from the trigger syntax?
> WITH FUNCTION function_name (argument_type, [...]) WHEN
> function_t
"Kevin Grittner" wrote:
> Alvaro Herrera wrote:
>
>> BTW did you try "make coverage" and friends? See
>> http://www.postgresql.org/docs/9.0/static/regress-coverage.html
>> and
>> http://developer.postgresql.org/~petere/coverage/
>
> I had missed that; thanks for pointing it out!
>
> I'm d
On Wed, Jan 26, 2011 at 1:32 PM, Tom Lane wrote:
>> I think you're conflating the table with its row type, and I'd like to
>> see some prior writing indicating otherwise.
>
> I will agree that a language lawyer could argue that a table rowtype
> doesn't have to act like a separately-declared compo
On Wed, Jan 26, 2011 at 10:01:28AM -0600, Kevin Grittner wrote:
> In looking at it just now, I noticed that after trying it in a
> couple different places what was left in the repository was not the
> optimal version for code coverage. I've put this back to the
> version which did a better job, fo
On Wed, Jan 26, 2011 at 01:42:23PM -0600, Kevin Grittner wrote:
> Dan, do you still have access to that machine you were using for the
> DBT-2 runs? Could we get a coverage run with and without
> TEST_OLDSERXID defined?
Sure, I'll give it a shot (once I figure out how to enable coverage...)
Dan
On Wed, 2011-01-26 at 14:15 -0500, Robert Haas wrote:
> On Wed, Jan 26, 2011 at 1:32 PM, Richard Broersma
> wrote:
> > On Wed, Jan 26, 2011 at 3:12 AM, Simon Riggs wrote:
> >> You're paying the reviewers; are you paying the mentors?
> >
> > The answer to this question is that we can fund mentor (
Dan Ports wrote:
> Isn't this placement the same as the version we had before that
> didn't work?
You're right. How about this?:
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=86b839291e2588e59875fb87d05432f8049575f6
Same benefit in terms of exercising more
On Jan 26, 2011, at 10:08 PM, Alex Hunsaker wrote:
> On Wed, Jan 26, 2011 at 12:44, Alexey Klyukin wrote:
>> Hi,
>>
>> On Jan 26, 2011, at 8:45 PM, Alex Hunsaker wrote:
>>
>>> On Sat, Jan 15, 2011 at 15:48, Alex Hunsaker wrote:
On Wed, Jan 12, 2011 at 13:04, Alexey Klyukin
wrote:
Dimitri Fontaine writes:
> Tom Lane writes:
>> Mph. Although such an extension should certainly carry a dependency on
>> the schema it's using, I'm not sure that it makes sense to consider that
>> the extension (as opposed to its contained objects) belongs to the
>> schema.
> Well yes, extensio
I wrote:
> You're right. How about this?:
That's even worse. I'm putting back to where you had it and taking
a break before I do anything else that dumb.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
On Wed, Jan 26, 2011 at 02:36:25PM -0600, Kevin Grittner wrote:
> Same benefit in terms of exercising more lines of code, but
> *without* exposing the uninitialized structure to other threads.
Won't this cause a deadlock because locks are being acquired out of
order?
Dan
--
Dan R. K. Ports
On Wed, Jan 26, 2011 at 3:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jan 26, 2011 at 12:47 PM, Tom Lane wrote:
>>> If you didn't mind inverting the sense of the result
>>> then we could use "EXECUTE IF function_name".
>
>> What about borrowing from the trigger syntax?
>
>> WITH FUNC
Robert Haas writes:
> On Wed, Jan 26, 2011 at 1:32 PM, Tom Lane wrote:
>> I will agree that a language lawyer could argue that a table rowtype
>> doesn't have to act like a separately-declared composite type, but
>> that surely doesn't meet the POLA.
> Well, actually, what I thought was that the
Just a small comment: If someone offered me $15 to mentor a reviewer, I
would tell him to kindly go away. If the same person were to offer me a
$15 t-shirt saying I mentored the review (or whatever), I would consider
it.
Yes, I know I could buy the t-shirt with the money. People are strange
tha
On Wed, Jan 26, 2011 at 3:48 PM, Tom Lane wrote:
>> Well, actually, what I thought was that the rowtype *should* act
>> exactly like a separately-declared composite rowtype. Which is to
>> say, it shouldn't have a default, because a separately-declared
>> composite rowtype *can't have a default*.
Robert Haas writes:
> On Wed, Jan 26, 2011 at 3:08 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> It's not obvious to me that it has a use case outside of casts, but
>>> it's certainly possible I'm missing something.
>> A possible example is simplifying X + 0 to X, or X * 0 to 0.
> Oh, I see.
Tom Lane writes:
> Oh: then you're doing it wrong. If you want to remember that WITH
> SCHEMA was specified, you need to explicitly store that as another
> column in pg_extension. You should not be depending on the dependency
> mechanism to remember that for you, any more than we'd use pg_depend
Building for coverage and running the reports littered my tree with
files which should probably be in .gitignore for just such a
contingency. Patch attached.
-Kevin
*** a/.gitignore
--- b/.gitignore
***
*** 12,17
--- 12,26
*.mo
objfiles.txt
.deps/
+ *.h.gcov
+ *.c.gc
We use small "k" in postgresql.conf, so pg_test_fsync should use the
same. Using "kB" would be more accurate in any case.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 26, 2011 at 3:29 PM, Joshua D. Drake wrote:
> Not somewhat, completely. Most of the "teachers" we have are already
> getting paid to work on PostgreSQL. There are some exceptions of course
> but if you look at the list of people that are qualified to actually
> review code, they are ge
On ons, 2011-01-26 at 06:33 -0500, Robert Haas wrote:
> I recently started getting these:
>
> plpython.c: In function ‘PLy_output’:
> plpython.c:3468: warning: format not a string literal and no format arguments
> plpython.c: In function ‘PLy_elog’:
> plpython.c:3620: warning: format not a string
Robert Haas writes:
> Considering the number of OTHER places we'd have to break backward
> compatibility, one more wouldn't bother me any, but apparently that's
> just me.
Well, again, it'd be all right with me if we were going to get any
meaningful increment in functionality out of it, but we ar
1 - 100 of 167 matches
Mail list logo
