Pavel Stehule pavel.steh...@gmail.com writes:
2013/2/23 Stephen Frost sfr...@snowman.net:
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
Michael Paquier michael.paqu...@gmail.com 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
2013/2/23 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2013/2/23 Stephen Frost sfr...@snowman.net:
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
On Sat, Feb 23, 2013 at 1:00 AM, Josh Berkus j...@agliodbs.com 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
On Sat, Feb 23, 2013 at 9:55 PM, Greg Stark st...@mit.edu wrote:
On Sat, Feb 23, 2013 at 1:00 AM, Josh Berkus j...@agliodbs.com 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?
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,
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
On Thu, Jan 24, 2013 at 3:48 PM, Tom Lane t...@sss.pgh.pa.us 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
Greg Stark st...@mit.edu 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?
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 t...@sss.pgh.pa.us wrote:
Greg Stark st...@mit.edu writes:
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
On Sat, Feb 23, 2013 at 5:25 PM, Tom Lane t...@sss.pgh.pa.us 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
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 and
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
On Sat, Feb 23, 2013 at 9:00 AM, Jov am...@amutu.com 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
On Sat, Feb 23, 2013 at 9:55 AM, David Fetter da...@fetter.org 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
Moved discussion from General To Hackers.
On Sat, Feb 23, 2013 at 10:41 AM, Stefan Andreatta
s.andrea...@synedra.comwrote:
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
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
s.andrea...@synedra.com mailto:s.andrea...@synedra.com wrote:
On 02/23/2013 05:10 PM, Jeff Janes wrote:
Sorry, I got tunnel vision about the how
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
s.andrea...@synedra.com mailto:s.andrea...@synedra.com wrote:
On 02/23/2013 05:10 PM, Jeff Janes wrote:
On Fri, Feb 22, 2013 at 11:58 AM, Alvaro Herrera
alvhe...@2ndquadrant.comwrote:
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,
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
2013/2/24 Andrew Dunstan and...@dunslane.net
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
On Sat, Feb 23, 2013 at 12:07:35PM -0800, Jeff Janes wrote:
On Sat, Feb 23, 2013 at 9:55 AM, David Fetter da...@fetter.org 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
see tom's new commit:
Rename postgres_fdw's use_remote_explain option to
use_remote_estimatehttp://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=09a7cd409e762f0430a5d474f4d8d7c962369a8e
I think the problem should be solved.
2013/2/24 Jov am...@amutu.com
I test the
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
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 list
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 not
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
* 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,
2013/2/24 Stephen Frost sfr...@snowman.net:
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
* 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 could
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
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
2013/2/24 Stephen Frost sfr...@snowman.net:
* 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
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 json
For
35 matches
Mail list logo
