On Fri, Oct 7, 2011 at 21:30, Nikhil Sontakke nikkh...@gmail.com wrote:
Hi Alex,
I guess we both are in agreement with each other :)
After sleeping over it, I think that check is indeed dead code with this new
non-inheritable check constraints functionality in place. So unless you have
some
On Oct8, 2011, at 23:07 , Christopher Browne wrote:
General purpose queries are nowhere near so predetermined. Indeed, whether a
column is nullable may not be at all visible, as the value of a column may be
computed by a function and thereby be quite opaque to static analysis.
I don't
Hanada-san,
The proposed patch put an invocation of PlanForeignJoin on the
create_foreignjoin_path() being also called by match_unsorted_outer().
Is it a suitable position to make a decision whether a join can be
pushed-down?
I think; it needs an additional functionality to provide higher
Florian Pflug wrote:
Coming up with a reasonable algorithm isn't *that* hard.
Agreed. Our shop has used a home-grown framework for over a decade
where we parse queries using ANTLR ( http://www.antlr.org/ ) and we
tracked this trough all expressions. There really weren't that many
On Oct9, 2011, at 14:20 , Kevin Grittner wrote:
Florian Pflug wrote:
Coming up with a reasonable algorithm isn't *that* hard.
Agreed. Our shop has used a home-grown framework for over a decade
where we parse queries using ANTLR ( http://www.antlr.org/ ) and we
tracked this trough all
On Oct9, 2011, at 13:35 , Kohei KaiGai wrote:
I think; it needs an additional functionality to provide higher priority
on the foreign-join plan that other plans, when fdw determind a particular
join can be pushed-down.
(Sorry, I have no idea right now.)
Probably, the basic design is
On Fri, Oct 7, 2011 at 5:45 PM, Alex Hunsaker bada...@gmail.com wrote:
If I find the time maybe Ill submit something along these lines for
the next commit fest.
So i just picked up the non-inherited constraints patch and quickly
ran into the same problem and found this thread.
I think it
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Florian Pflug wrote:
I don't think the reply to a DESCRIBE message is currently
extensible, so we'd probably need to add a new version of the
message.
Or a new protocol version.
Exactly --- this *would* require a protocol version bump.
Florian Pflug f...@phlo.org writes:
On Oct9, 2011, at 14:20 , Kevin Grittner wrote:
Yeah. It would be nice to see at least one use case. The only
comment I recall is a vague suggestion that that people might want to
select data from a table and infer table attributes from the result
set
On 08.10.2011 21:51, Kevin Grittner wrote:
I tried to review the Optimizing box_penalty patch:
Thanks!
On the other hand, this patch leaves the code a few lines shorter and
eliminates some unnecessary Datum wrapping, PG_FUNCTION_ARGS
parameters on a static function, and allows that function
Jeff Davis pg...@j-davis.com writes:
On Sat, 2011-10-08 at 12:44 -0700, Jeff Janes wrote:
When I apply this to head, make check fails with:
create type textrange_en_us as range(subtype=text, collation=en_US);
+ ERROR: collation en_US for encoding SQL_ASCII does not exist
Thank you for
Marc Munro m...@bloodnok.com writes:
It seems that in order to create an object in a given schema, I must
have been granted create privilege on the schema. But in order to drop
that object I require usage privilege.
This means that with the right privilege settings I can create objects
On Oct9, 2011, at 17:56 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
On Oct9, 2011, at 14:20 , Kevin Grittner wrote:
Yeah. It would be nice to see at least one use case. The only
comment I recall is a vague suggestion that that people might want to
select data from a table and
On Sun, Oct 9, 2011 at 09:17, Greg Stark st...@mit.edu wrote:
On Fri, Oct 7, 2011 at 5:45 PM, Alex Hunsaker bada...@gmail.com wrote:
If I find the time maybe Ill submit something along these lines for
the next commit fest.
So i just picked up the non-inherited constraints patch and quickly
I created a patch corresponding FPW.
Fujii's patch (ver 9) is based.
Manage own FPW in shared-memory (on master)
* startup and walwriter process update it. startup initializes it
after REDO. walwriter updates it when started or received SIGHUP.
Insert WAL including a value of current
On Sun, Oct 9, 2011 at 17:51, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Yeah, it wouldn't be hard to produce a long list of things which
would take about the same effort which seem more beneficial to me.
It's a matter of whether this is causing
2011/10/9 Jun Ishiduka ishizuka@po.ntts.co.jp:
Insert WAL including a value of current FPW (on master)
* In the the same timing as update, they insert WAL (is named
XLOG_FPW_CHANGE). XLOG_FPW_CHANGE has a value of the changed FPW.
* When it creates CHECKPOINT, it adds a value of
On Sun, 2011-10-09 at 11:58 -0400, Tom Lane wrote:
Marc Munro m...@bloodnok.com writes:
It seems that in order to create an object in a given schema, I must
have been granted create privilege on the schema. But in order to drop
that object I require usage privilege.
This means that
On Tue, Sep 27, 2011 at 10:34 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Sep 26, 2011 at 7:45 PM, Peter Eisentraut pete...@gmx.net wrote:
On sön, 2011-09-25 at 12:58 -0400, Tom Lane wrote:
And it's not like we don't break configuration file
contents in most releases anyway, so I
I wrote:
I believe that we should rejigger things so that when an index-only scan
is selected, the executor *always* works from the data supplied by the
index. Even if it has to visit the heap --- it will do that but just to
consult the tuple's visibility data, and then use what it got from
On Sun, Oct 9, 2011 at 9:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
At the moment I'm leaning to approach #3, but I wonder if anyone has
a different opinion or another idea altogether.
Would any of these make it more realistic to talk about the crazy
plans Heikki suggested like doing two index
Greg Stark st...@mit.edu writes:
On Sun, Oct 9, 2011 at 9:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
At the moment I'm leaning to approach #3, but I wonder if anyone has
a different opinion or another idea altogether.
Would any of these make it more realistic to talk about the crazy
plans
On Sun, Oct 9, 2011 at 10:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't think it's particularly relevant --- we would not want to use
weird representations of the Vars outside the index scan nodes. Above
the scan they'd be just like any other upper-level Vars.
I can't say I fully
I wrote:
There are at least four things we could do: ...
2. Set varno = OUTER (or maybe INNER). This is safe because there's no
other use for OUTER/INNER in a table scan node. We would have to hack
things so that the index tuple gets put into econtext-ecxt_outertuple
(resp. ecxt_innertuple)
On Mon, Oct 10, 2011 at 2:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The need for this additional node list field also sways me in a
direction that I'd previously been on the fence about, namely that
I think index-only scans need to be their own independent plan node type
instead of sharing a
[ Thanks all for the very productive discussion in the thread
libpq, PQdescribePrepared - PQftype, PQfmod, no PQnullable
which I originated. Very useful. Now on something different. ]
About two years ago, I had to research some PostgreSQL failures on
HP-UX on a lame PA-RISC box. Looking
Alex Goncharov alex-goncha...@comcast.net writes:
About two years ago, I had to research some PostgreSQL failures on
HP-UX on a lame PA-RISC box. Looking at the PostgreSQL source code
then, I got an impression that running PostgreSQL on HP-UX was an open
question -- HP-UX didn't seem like a
Thanks...
,--- You/Tom (Sun, 09 Oct 2011 22:29:19 -0400) *
| Well, HP hasn't exactly been forthcoming with support on their own end,
| but we do have an HPUX 11.31 IA64 machine in the buildfarm,
Should I read the above as:
1. The PostgreSQL server will build on HPUX 11.31 IA64.
2. The
On Sun, Oct 9, 2011 at 1:56 PM, Alex Hunsaker bada...@gmail.com wrote:
So i just picked up the non-inherited constraints patch and quickly
ran into the same problem and found this thread.
I think it makes sense to hold off on this patch until these issues
are resolved. Because we really do
On Sat, Oct 8, 2011 at 12:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh j...@schemaverse.com writes:
[ unhappy about users being able to freely adjust work_mem etc ]
Really, if you're letting users issue arbitrary SQL queries, there
simply isn't any way to prevent them from beating your
Robert Haas robertmh...@gmail.com writes:
On Sat, Oct 8, 2011 at 12:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The reason that the specific variables you mention (as well as some
others that bear on such things) are USERSET and not SUSET is precisely
that we are not trying to constrain the
31 matches
Mail list logo
