Re: [HACKERS] auto_explain WAS: RFC: Timing Events

Sorry for the late reply, but I think I can add some ideas here... On 11/21/12 5:33 PM, Gavin Flower wrote: On 22/11/12 12:15, Greg Smith wrote: On 11/8/12 2:16 PM, Josh Berkus wrote: Also, logging only the long-running queries is less useful than people on this list seem to think. When I'm

Re: [HACKERS] Show type in psql SELECT

On 02/25/2013 08:54 AM, Mike Toews wrote: > On 25 February 2013 12:48, Craig Ringer > wrote: > > However, the thing I want most couldn't be provided by this patch > > because it seems to be a deeper server limitation: the ability to get > > typmod data from calculatio

Re: [HACKERS] [DOCS] Contrib module "xml2" status

On 24 February 2013 13:46, Peter Eisentraut wrote: > > done > The patch included the word 'so' in the email address by accident.

Re: [HACKERS] Show type in psql SELECT

On 25 February 2013 12:48, Craig Ringer wrote: > However, the thing I want most couldn't be provided by this patch > because it seems to be a deeper server limitation: the ability to get > typmod data from calculation results like > > NUMERIC(8,3) '11.131' + NUMERIC(8,3) '12.123' But is the d

Re: [HACKERS] Show type in psql SELECT

On Sun, Feb 24, 2013 at 11:14 PM, Peter Eisentraut wrote: > On Sat, 2013-02-23 at 12:09 +1300, Mike Toews wrote: >> Has anyone else thought this was a missing feature? > > I have. It never occurred to me before what exactly was missing but I did regularly have to do CREATE TABLE AS (query...) jus

Re: [HACKERS] json generation enhancements

On 02/24/2013 06:33 PM, Craig Ringer wrote: On 02/24/2013 09:58 PM, Andrew Dunstan wrote: Adding a cast to json for a builtin type will have no effect unless you also change this code. We can relax that but my view was that we should know how to generate JSON from builtin types and just do it.

Re: [HACKERS] Show type in psql SELECT

On 02/25/2013 07:14 AM, Peter Eisentraut wrote: > On Sat, 2013-02-23 at 12:09 +1300, Mike Toews wrote: >> Has anyone else thought this was a missing feature? > I have. As have I, repeatedly. This would be a nice convenience, though pg_typeof can be used to achieve a similar effect a bit more clumsi

Re: [HACKERS] json generation enhancements

On 02/24/2013 09:58 PM, Andrew Dunstan wrote: > > Adding a cast to json for a builtin type will have no effect unless > you also change this code. We can relax that but my view was that we > should know how to generate JSON from builtin types and just do it. If json generation from built-in types i

Re: [HACKERS] Show type in psql SELECT

On Sat, 2013-02-23 at 12:09 +1300, Mike Toews wrote: > Has anyone else thought this was a missing feature? I have. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: unified vs context diffs (was Re: [HACKERS] Strange Windows problem, lock_timeout test request)

* Claudio Freire (klaussfre...@gmail.com) wrote: > > As another point, it's also the very first thing that we document in > > http://wiki.postgresql.org/wiki/Reviewing_a_Patch to check for. > > TBH, that wiki link seems to suggest that *having context* is the > point of the requirement (to be able

Re: [HACKERS] [DOCS] Contrib module "xml2" status

On Fri, 2013-02-22 at 08:25 +0900, Ian Lawrence Barwick wrote: > 2013/2/22 Andrew Dunstan : > > > > On 02/21/2013 12:56 PM, Magnus Hagander wrote: > >> > >> On Thu, Feb 21, 2013 at 6:39 PM, Robert Haas > >> wrote: > >>> > >>> On Wed, Feb 20, 2013 at 11:58 AM, Ian Lawrence Barwick > >>> wrote: > >

Re: unified vs context diffs (was Re: [HACKERS] Strange Windows problem, lock_timeout test request)

On 24 February 2013 08:44, Heikki Linnakangas wrote: > I can't speak for others, but I personally don't care whether a patch is > posted in unified or context diff format. Not as a general rule, anyway; > patches that modify a few lines here and there are generally more readable > in unified forma

Re: unified vs context diffs (was Re: [HACKERS] Strange Windows problem, lock_timeout test request)

On 02/24/2013 12:39 PM, Claudio Freire wrote: On Sun, Feb 24, 2013 at 11:08 AM, Stephen Frost wrote: * Heikki Linnakangas (hlinnakan...@vmware.com) wrote: So if you want to be kind to readers, look at the patch and choose the format depending on which one makes it look better. But there's no

Re: unified vs context diffs (was Re: [HACKERS] Strange Windows problem, lock_timeout test request)

On Sun, Feb 24, 2013 at 11:08 AM, Stephen Frost wrote: > * Heikki Linnakangas (hlinnakan...@vmware.com) wrote: >> So if you want to be kind to readers, look at the patch and choose >> the format depending on which one makes it look better. But there's >> no need to make a point of it when someone

Re: [HACKERS] Strange Windows problem, lock_timeout test request

2013-02-24 15:03 keltezéssel, Stephen Frost írta: * Boszormenyi Zoltan (z...@cybertec.at) wrote: 2013-02-24 03:23 keltezéssel, Stephen Frost írta: No, it isn't. Patches posted to the list should be in context diff format (and uncompressed unless it's too large) for easier reading. That avoids

Re: [HACKERS] pg_xlogdump

Andres Freund writes: > On 2013-02-23 14:54:51 -0800, Jeff Janes wrote: >> I don't know if the Makefile needs to be taught not to delete it, or taught >> how to recreate it once deleted. > It shouldn't be deleted, I came to the same conclusion and committed that a few minutes before you posted.

Re: unified vs context diffs (was Re: [HACKERS] Strange Windows problem, lock_timeout test request)

* Heikki Linnakangas (hlinnakan...@vmware.com) wrote: > So if you want to be kind to readers, look at the patch and choose > the format depending on which one makes it look better. But there's > no need to make a point of it when someone posts in "wrong" format. To be more precise- my main complai

Re: [HACKERS] Strange Windows problem, lock_timeout test request

* Boszormenyi Zoltan (z...@cybertec.at) wrote: > 2013-02-24 03:23 keltezéssel, Stephen Frost írta: > >No, it isn't. Patches posted to the list should be in context diff > >format (and uncompressed unless it's too large) for easier reading. > >That avoids having to download it, apply it to a git tr

Re: [HACKERS] pg_xlogdump

On 2013-02-23 14:54:51 -0800, Jeff Janes wrote: > If I run "make clean", or "make maintainer-clean", this deletes the file > contrib/pg_xlogdump/rmgrdesc.c. And then config/make doesn't know how to > get it back again. > > I don't know if the Makefile needs to be taught not to delete it, or taug

Re: [HACKERS] json generation enhancements

On 02/24/2013 02:15 AM, Craig Ringer wrote: On 02/24/2013 02:09 PM, Steve Singer wrote: Here is a review of this patch., Overview - This patch adds a set of functions to convert types to json. Specifically * An aggregate that take the elements and builds up a json array. *

Re: [HACKERS] Strange Windows problem, lock_timeout test request

Stephen, 2013-02-23 02:55 keltezéssel, Stephen Frost írta: Zoltán, * Zoltán Böszörményi (z...@cybertec.at) wrote: The patch now passed "make check" in both cases. Is v29 the latest version of this patch..? attached is v30, I hope with everything fixed. - List based enable/disable_multiple_t

unified vs context diffs (was Re: [HACKERS] Strange Windows problem, lock_timeout test request)

On 24.02.2013 05:07, Andrew Dunstan wrote: On 02/23/2013 01:15 PM, Boszormenyi Zoltan wrote: First off, it's not in context diff format, which is the PG standard for patch submission. Since moving to GIT, this expectation is obsolete. All PG hackers became comfortable with the unified diff fo

Re: [HACKERS] Strange Windows problem, lock_timeout test request

2013-02-24 03:23 keltezéssel, Stephen Frost írta: Zoltán, * Boszormenyi Zoltan (z...@cybertec.at) wrote: 2013-02-23 02:55 keltezéssel, Stephen Frost írta: First off, it's not in context diff format, which is the PG standard for patch submission. Since moving to GIT, this expectation is obsole