On Thu, Apr 12, 2012 at 05:49, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 11, 2012 at 5:36 PM, Peter Eisentraut pete...@gmx.net wrote:
I'd still review it, but I'd be able to spend say 3 minutes on review
and 30 seconds on committing it, versus 3
On 08.04.2012 11:59, Guillaume Lelarge wrote:
Hi,
I recently wrote a plpgsql plugin. I wanted to enable the use of pgxs,
to make it easier to compile the plugin, but I eventually found that I
can't do that because the plpgsql.h file is not available in the include
directory.
I'm wondering if
The SELECT manpage has:
and with_query is:
with_query_name [ ( column_name [, ...] ) ] AS ( select | insert |
update | delete )
Should that list that you can use values as well? Or is it something
we generally consider wherever select works you can use values?
(I ran into it because it's
* Magnus Hagander (mag...@hagander.net) wrote:
with_query_name [ ( column_name [, ...] ) ] AS ( select | insert |
update | delete )
Should that list that you can use values as well? Or is it something
we generally consider wherever select works you can use values?
(I ran into it
On Tue, Apr 10, 2012 at 08:43:12PM -0400, Greg Smith wrote:
The main reason I worry about this is because of a very real
chicken/egg problem here that I keep banging into. Since the commit
standards for so many other open-source projects are low, there are
a non trivial number of business
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 08.04.2012 11:59, Guillaume Lelarge wrote:
There could be a good reason which would explain why we can't (or don't
want to) do this, but I don't see it right now.
Me neither, except a general desire to keep internals hidden. I
Stephen Frost sfr...@snowman.net writes:
* Magnus Hagander (mag...@hagander.net) wrote:
with_query_name [ ( column_name [, ...] ) ] AS ( select | insert |
update | delete )
Should that list that you can use values as well? Or is it something
we generally consider wherever select works you can
Excerpts from Tom Lane's message of jue abr 12 00:49:38 -0300 2012:
At the other end of the scale, I think it's true that the CF app could
be more helpful than it is for tracking the state of complex patches.
I don't really have any concrete suggestions, other than that I've
seen far too
On 12 April 2012 13:45, Bruce Momjian br...@momjian.us wrote:
I want to caution against adjusting things to improve funding
possibilities. There is nothing wrong with increasing funding
possibilities, per say, but such changes often distort behavior in
unforeseen ways that adversely affect
On 04/11/2012 10:24 AM, Tom Lane wrote:
Greg Smithg...@2ndquadrant.com writes:
I'd like to dump around 50 pages of new material into the docs as a
start, but I don't want to take so much time away from the code oriented
committers to chew on that much.
Well, with all due respect, that does
If we were actually using git branches for it, the CF app could
automatically close entries when they were committed. But that
requires them to be committed *unmodified*, and I'm not sure that's
reasonable. I also think requiring a git branch for the *simple*
changes is adding more tooling
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I want to caution against adjusting things to improve funding
possibilities. There is nothing wrong with increasing funding
possibilities, per say, but such changes often distort behavior in
unforeseen ways that adversely affect our
On 23 March 2012 19:07, David Fetter da...@fetter.org wrote:
On Fri, Mar 23, 2012 at 11:38:56AM -0700, David Fetter wrote:
How about this one?
Oops, forgot to put the latest docs in.
I think the docs need some additional supporting content. The LIKE
clause and its source_table parameter
On Thu, Apr 12, 2012 at 03:34:31PM +0100, Peter Geoghegan wrote:
Something that I would suggest is that those that are receiving
funding be transparent about it. It isn't essential of course, but to
do any less might lead to the perception of there being a conflict of
interests in some
On ons, 2012-04-11 at 22:10 +0100, Thom Brown wrote:
On 11 April 2012 21:58, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2012-04-11 at 21:42 +0100, Thom Brown wrote:
Could you clarify what you're defining to be a client application and
a server application? This could be confusing as
I think the big take-away, education-wise, is that for our project,
committer == grunt work. Remember, I used to be the big committer of
non-committer patches --- need I say more. ;-) LOL
Well, promoting several people to committer specifically and publically because
of their review work
On Thu, Apr 12, 2012 at 11:34:48AM -0400, Bruce Momjian wrote:
On Thu, Apr 12, 2012 at 03:34:31PM +0100, Peter Geoghegan wrote:
Something that I would suggest is that those that are receiving
funding be transparent about it. It isn't essential of course, but to
do any less might lead to the
On 12.04.2012 16:59, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
On 08.04.2012 11:59, Guillaume Lelarge wrote:
There could be a good reason which would explain why we can't (or don't
want to) do this, but I don't see it right now.
Me neither, except a
On 04/12/2012 11:34 AM, Bruce Momjian wrote:
The specific suggestion that vendors are not taking contributors
seriously unless they have commit-bits is perhaps something that
requires education of vendors, or perhaps my blogging about this will
help.
I'm glad I managed to vent my frustration
I wrote:
So I'm back to thinking we need to look explicitly at the rowcount
comparison as well as all the existing conditions in add_path.
One annoying thing about that is that it will reduce the usefulness of
add_path_precheck, because that's called before we compute the rowcount
estimates
On Wed, Apr 11, 2012 at 12:00:39PM -0300, Alvaro Herrera wrote:
remote in their main PG tree, and so changesets could be pulled into the
same clone and cherry-picked into the master branch.
If you're talking about a way of using git to support reviewing, the
Gerrit tool has an interesting
Alvaro Herrera wrote:
Now what would be sort of neat is if we had a way to keep all the
versions of patch X plus author and reviewer information, links to
reviews and discussion, etc. in some sort of centralized place.
FWIW: y'all might have discussed to death during the git migration, so
On Thu, Apr 12, 2012 at 6:11 PM, Jay Levitt jay.lev...@gmail.com wrote:
Rather than extend the CF app into a trivial-patch workflow app, it might be
worth looking at integrating it with github.
There's a reluctance to require a proprietary component that could
disappear on us without notice.
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
This is a little patch to fix a typo in contrib/file_fdw.
I think that comment is fine as-is.
OK, thanks.
Best regards,
Etsuro Fujita
regards, tom lane
--
Sent via
On Sun, 2012-03-18 at 11:25 -0400, Tom Lane wrote:
Yeah, that was me, and it came out of actual user complaints ten or more
years back. (It's actually not 2X growth but more like 4X growth
according to the comments in logtape.c, though I no longer remember the
exact reasons why.) We knew
25 matches
Mail list logo
