Re: [HACKERS] json generation enhancements

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. > * Conversions from an hstore to jso

Re: [HACKERS] bugfix: --echo-hidden is not supported by \sf statements

2013/2/24 Stephen Frost : > * Pavel Stehule (pavel.steh...@gmail.com) wrote: >> it is not possible - both fragments has different purpose. Code in \ef >> or \sf should to select exactly one function based on complete >> function signature, \df try to show list of functions filtered by >> name. > >

Re: [HACKERS] [pgsql-advocacy] Call for Google Summer of Code mentors, admins

> Take a look at MADLib. My suggestion would be extending the MADlib > functions; there's plenty of unimplemented ML algrothims which could be > added to it. I went through the MADLib library and came up with the following two ideas which I feel could be potential GSoC 2013 projects: 1) MADlib c

Re: [HACKERS] json generation enhancements

On 13-01-11 11:03 AM, Andrew Dunstan wrote: On 01/11/2013 11:00 AM, Andrew Dunstan wrote: I have not had anyone follow up on this, so I have added docs and will add this to the commitfest. Recap: This adds the following: json_agg(anyrecord) -> json to_json(any) -> json hstore_

Re: [HACKERS] bugfix: --echo-hidden is not supported by \sf statements

* Pavel Stehule (pavel.steh...@gmail.com) wrote: > it is not possible - both fragments has different purpose. Code in \ef > or \sf should to select exactly one function based on complete > function signature, \df try to show list of functions filtered by > name. I don't buy that argument. You cou

Re: [HACKERS] bugfix: --echo-hidden is not supported by \sf statements

2013/2/24 Stephen Frost : > Pavel, > > * Pavel Stehule (pavel.steh...@gmail.com) wrote: >> I am looking on this code now, and it is not easy as I though - there >> are two possible errors: not found or found more - so returning >> InvalidOid is not enough - and then some "new lookup" function is no

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

* Andrew Dunstan (and...@dunslane.net) wrote: > Every unified diff can be turned into a context diff by passing it > though "filterdiff --format=context". On that point, annoyingly, it's not accurate for every diff. In particular, when I tried it with the diff for 'v29' of this lock_timeout patch

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

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 format, see references from the list. A lot

Re: [HACKERS] bugfix: --echo-hidden is not supported by \sf statements

Pavel, * Pavel Stehule (pavel.steh...@gmail.com) wrote: > I am looking on this code now, and it is not easy as I though - there > are two possible errors: not found or found more - so returning > InvalidOid is not enough - and then some "new lookup" function is not > simple or is ugly - and I am n

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

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 obsolete. No, it isn't. Patches posted to the

Re: [HACKERS] Show type in psql SELECT

David, * David Fetter (da...@fetter.org) wrote: > Not everyone uses libpq, so my argument for making it available at the > SQL level stands. Ok, if they're not using libpq then presumably they're using some custom-written app which speaks the PostgreSQL protocol- and guess what, this information

Re: [HACKERS] ERROR: invalid option "use_remote_estimate"

see tom's new commit: > Rename postgres_fdw's use_remote_explain option to > use_remote_estimate I think the problem should be solved. 2013/2/24 Jov > I test the postgresql_fdw extensi

Re: [HACKERS] Show type in psql SELECT

On Sat, Feb 23, 2013 at 12:07:35PM -0800, Jeff Janes wrote: > On Sat, Feb 23, 2013 at 9:55 AM, David Fetter wrote: > > On Sat, Feb 23, 2013 at 12:09:51PM +1300, Mike Toews wrote: > > > Hi hackers, > > > > > > Type info can be viewed with "\d mytable", however often I'd > > > like to see the type (

Re: [HACKERS] make: *** pg_xlogdump: No such file or directory. Stop.

2013/2/24 Andrew Dunstan > > On 02/23/2013 12:00 PM, Jov wrote: > >> when build the head contrib,I get follow error: >> >> make[1]: Entering directory `/data/myenv/postgresql/** >> contrib/pgstattuple' >> make[1]: Nothing to be done for `all'. >> make[1]: Leaving directory `/data/myenv/postg

Re: [HACKERS] make: *** pg_xlogdump: No such file or directory. Stop.

after I run git checkout -f，the really error message is： make -C pg_xlogdump all make[1]: Entering directory `/data/myenv/postgresql/contrib/pg_xlogdump' make[1]: *** No rule to make target `../../src/backend/access/transam/rmgrdesc.c', needed by `rmgrdesc.c'. Stop. make[1]: Leaving directory `/d

Re: [HACKERS] pg_xlogdump

On Fri, Feb 22, 2013 at 11:58 AM, Alvaro Herrera wrote: > Andres Freund wrote: > > On 2013-02-13 12:09:37 -0300, Alvaro Herrera wrote: > > > Here's an updated version of pg_xlogdump. This is rebased on top of > the > > > committed xlogreader, palloc restructuring and libpgcommon, PG_RMGR > > > st

Re: [HACKERS] [GENERAL] autoanalyze criteria

On 24/02/13 10:12, Stefan Andreatta wrote: On 02/23/2013 09:30 PM, Jeff Janes wrote: Moved discussion from General To Hackers. On Sat, Feb 23, 2013 at 10:41 AM, Stefan Andreatta mailto:s.andrea...@synedra.com>> wrote: On 02/23/2013 05:10 PM, Jeff Janes wrote: Sorry, I got tunnel vi

Re: [HACKERS] [GENERAL] autoanalyze criteria

On 02/23/2013 09:30 PM, Jeff Janes wrote: Moved discussion from General To Hackers. On Sat, Feb 23, 2013 at 10:41 AM, Stefan Andreatta mailto:s.andrea...@synedra.com>> wrote: On 02/23/2013 05:10 PM, Jeff Janes wrote: Sorry, I got tunnel vision about the how the threshold was c

Re: [HACKERS] [GENERAL] autoanalyze criteria

Moved discussion from General To Hackers. On Sat, Feb 23, 2013 at 10:41 AM, Stefan Andreatta wrote: > > On 02/23/2013 05:10 PM, Jeff Janes wrote: > > > Sorry, I got tunnel vision about the how the threshold was computed, and > forgot about the thing it was compared to. There is a "secret" data p

Re: [HACKERS] Show type in psql SELECT

On Sat, Feb 23, 2013 at 9:55 AM, David Fetter wrote: > On Sat, Feb 23, 2013 at 12:09:51PM +1300, Mike Toews wrote: > > Hi hackers, > > > > Type info can be viewed with "\d mytable", however often I'd like to > > see the type (and typmod) info in SELECT queries with psql, similar > > to pgAdmin II

Re: [HACKERS] make: *** pg_xlogdump: No such file or directory. Stop.

On Sat, Feb 23, 2013 at 9:00 AM, Jov wrote: > when build the head contrib,I get follow error: > > make[1]: Entering directory `/data/myenv/postgresql/contrib/pgstattuple' > make[1]: Nothing to be done for `all'. > make[1]: Leaving directory `/data/myenv/postgresql/contrib/pgstattuple' > make

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

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..? Yes, is was until you came up with your review... ;-) Looking through the patch, I've noticed

Re: [HACKERS] Show type in psql SELECT

On Sat, Feb 23, 2013 at 12:09:51PM +1300, Mike Toews wrote: > Hi hackers, > > Type info can be viewed with "\d mytable", however often I'd like to > see the type (and typmod) info in SELECT queries with psql, similar > to pgAdmin III. For example: I'm thinking we should add it as a SET parameter

Re: [HACKERS] [PATCH 0/3] Work around icc miscompilation

On Sat, Feb 23, 2013 at 5:25 PM, Tom Lane wrote: > Really? Can't "INT_MAX - a" overflow? I guess I shouldn't have tried summarizing the code and just pasted some real code in for fear of getting it wrong. I was thinking of unsigned arithmetic when I wrote that. The point being that the compiler

Re: [HACKERS] make: *** pg_xlogdump: No such file or directory. Stop.

On 02/23/2013 12:00 PM, Jov wrote: when build the head contrib,I get follow error: make[1]: Entering directory `/data/myenv/postgresql/contrib/pgstattuple' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/data/myenv/postgresql/contrib/pgstattuple' make -C pg_xlogdump all

Re: [HACKERS] [PATCH 0/3] Work around icc miscompilation

It depends on the context. In the patches, `a' is known to be non-negative, so `INT_MAX - a' cannot overflow. If you ignore the context and talk about the general case, then it can. - xi On Sat, Feb 23, 2013 at 12:25 PM, Tom Lane wrote: > Greg Stark writes: >> He's changing things to do > >>

Re: [HACKERS] [PATCH 0/3] Work around icc miscompilation

Greg Stark writes: > He's changing things to do > if (INT_MAX - a > b) > PG_THROW ("a+b would overflow") > else > x=a+b; > Why would a smarter compiler be licensed to conclude that it can > optimize away anything? "INT_MAX-a > b" is always well defined. Really? Can't "INT_MAX - a" overflow

Re: [HACKERS] [PATCH 0/3] Work around icc miscompilation

On Thu, Jan 24, 2013 at 3:48 PM, Tom Lane wrote: > The fundamental problem here is that the compiler, unless told otherwise > by a compilation switch, believes it is entitled to assume that no > integer overflow will happen anywhere in the program. Therefore, any > error check that is looking for

[HACKERS] make: *** pg_xlogdump: No such file or directory. Stop.

when build the head contrib,I get follow error: make[1]: Entering directory `/data/myenv/postgresql/contrib/pgstattuple' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/data/myenv/postgresql/contrib/pgstattuple' make -C pg_xlogdump all make: *** pg_xlogdump: No such file or

[HACKERS] ERROR: invalid option "use_remote_estimate"

I test the postgresql_fdw extension,every thing is fine but when I add the remote estimate option I get a error: postgres=# alter foreign table test options (add use_remote_estimate 'true'); ERROR: invalid option "*use_remote_estimate*" HINT: Valid options in this context are: schema_name, table

Re: [HACKERS] Materialized views WIP patch

On Sat, Feb 23, 2013 at 9:55 PM, Greg Stark wrote: > On Sat, Feb 23, 2013 at 1:00 AM, Josh Berkus wrote: > > I prefer RESET, especially since it could eventually support RESET ALL > > MATERIALIZED VIEWS if that turns out to be useful. How does the parser > > like that? > > Isn't reset currently

Re: [HACKERS] Materialized views WIP patch

On Sat, Feb 23, 2013 at 1:00 AM, Josh Berkus wrote: > I prefer RESET, especially since it could eventually support RESET ALL > MATERIALIZED VIEWS if that turns out to be useful. How does the parser > like that? Isn't reset currently only used for GUCs? I think that makes for a strange crossover.

Re: [HACKERS] bugfix: --echo-hidden is not supported by \sf statements

2013/2/23 Tom Lane : > Pavel Stehule writes: >> 2013/2/23 Stephen Frost : >>> Why is that? lookup_function_oid() only collects the oid to pass to >>> get_create_function_cmd(), why not just issue one query to the backend? >>> And use PSQLexec() to boot and get --echo-hidden, etc, for free? And >

Re: [HACKERS] New hooks for snapshot and transaction ID acquisition from external source

Michael Paquier writes: > What do you think about adding hooks for transaction ID and snapshot > acquisition? Not much. Those places are not only hot spots but remarkably delicate. It's hard to see much that a plugin could do there that wouldn't be pretty deleterious to both performance and reli

Re: [HACKERS] bugfix: --echo-hidden is not supported by \sf statements

Pavel Stehule writes: > 2013/2/23 Stephen Frost : >> Why is that? lookup_function_oid() only collects the oid to pass to >> get_create_function_cmd(), why not just issue one query to the backend? >> And use PSQLexec() to boot and get --echo-hidden, etc, for free? And >> eliminate the one-off err