> > Displace yes. It would error out if someone says
> >
> > ALTER TABLE ONLY... CHECK ();
> >
> > suggesting to use the ONLY with the CHECK.
>
> I'd say the behavior for that case can revert to the PostgreSQL 9.1
> behavior.
> If the table has children, raise an error. Otherwise, add an inheritab
Jeff Davis writes:
> Proposed solution: a modified merge join that can handle ranges.
> 1. Order the ranges on both sides by the lower bound, then upper bound.
> Empty ranges can be excluded entirely.
> 2. Left := first range on left, Right := first range on right
> 3. If Left or Right is empt
On 16.04.2012 08:40, Jeff Davis wrote:
Does someone know of a spatial join algorithm (without IP claims) that
would be as good as this one for ranges?
I'd be happy with an algorithm that's specific to ranges, too, but my
gut geeling is that there has to be a lot of research on spatial join
al
Your proposal makes me think of something similar which might be useful,
INclusion constraints. As "exclusion constraints" might be thought of like a
generalization of unique/key constraints, "inclusion constraints" are like a
generalization of foreign key constraints. The "inclusion constrain
I hope this is not an inappropriate time for 9.3 discussions. The flip
side of asking for submissions in the first couple commitfests means
that I need to submit proposals now.
What is a Range Join?
See attached SQL for example. The key difference is that the join
condition is not equality, but o
Thanks!
Best regards,
Etsuro Fujita
> -Original Message-
> From: Peter Eisentraut [mailto:pete...@gmx.net]
> Sent: Saturday, April 14, 2012 7:07 AM
> To: Etsuro Fujita
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] typo fix
>
> On fre, 2012-04-13 at 17:27 +0900, Etsuro Fujit
Amit Kapila writes:
> That case is handled by make_rels_by_clauseless_joins
> It will be handled by make_rels_by_clauseless_joins() if given rel old_rel
> doesn't have any join clause.
> However if it has join clause but doesn't able to join with any other rels
> like in the example you have provi
2012-04-16 04:46 keltezéssel, Michael Meskes írta:
On Tue, Apr 10, 2012 at 07:56:35PM +0200, Boszormenyi Zoltan wrote:
With the above, it would be possible to use a comma separated list of "-r"
suboptions, e.g. "-r prepare,questionmarks,readahead=16" in one option.
Yes, that sounds like a good
>> That case is handled by make_rels_by_clauseless_joins
It will be handled by make_rels_by_clauseless_joins() if given rel old_rel
doesn't have any join clause.
However if it has join clause but doesn't able to join with any other rels
like in the example you have provided for relation c, it is n
Amit Kapila writes:
> I want to clarify small doubt in this regard.
> In function make_rels_by_clause_joins(..), it tries to join the given
> relation old_rel with other relations if there exist a join between them.
> What I can understand is, it is because if there exists a join condition its
>
I want to clarify small doubt in this regard.
In function make_rels_by_clause_joins(..), it tries to join the given
relation old_rel with other relations if there exist a join between them.
What I can understand is, it is because if there exists a join condition its
better to join with that relat
On Tue, Apr 10, 2012 at 07:56:35PM +0200, Boszormenyi Zoltan wrote:
> With the above, it would be possible to use a comma separated list of "-r"
> suboptions, e.g. "-r prepare,questionmarks,readahead=16" in one option.
Yes, that sounds like a good plan. But of course it's outside the scope of this
Excerpts from Alex's message of dom abr 15 01:52:16 -0300 2012:
>
> Jay Levitt writes:
>
> > Alex wrote:
> >> I didn't follow this whole thread, but have we considered Redmine[1]?
> >
> > As the resident "Ruby is shiny, let's do everything in Rails on my
> > MacBook" guy, I'd like to make a sta
On 04/15/2012 05:46 AM, Simon Riggs wrote:
Our problem is not lack of resource, it is ineffective
delegation. As Hannu points out, he didn't know the patch would be
rejected, so he didn't know help was needed to save something useful.
I considered that the job of the CF manager, but perhaps it is
On 04/14/2012 05:28 PM, Jay Levitt wrote:
I see now that the "Reviewing a Patch" wiki page explains this, but
maybe this info should be pushed higher into the docs and web site; a
"How can I contribute" page, open calls for reviewers on the non-hackers
mailing lists, things like that. Or maybe ju
On 04/14/2012 06:03 PM, Robert Haas wrote:
If someone's work is going to require substantial
revision, it is much better and much less work to do that revision
before the code goes into our repository (and particularly, before it
gets released) rather than after.
I would think one of the major
On Thu, Apr 12, 2012 at 10:50:31AM +0530, Nikhil Sontakke wrote:
> > > CHECK NO INHERIT sounds fine to me; will that display ALTER TABLE ONLY
> > > x as the one true way of doing this?
> >
> > s/display/displace/, I think you meant? Yeah, that's what I understand
> > the proposal to be.
+1 for th
On Sun, Apr 15, 2012 at 4:50 PM, Tom Lane wrote:
> I think this is a rather unfair summary of the history. It was clear
> very early in the CF that people thought Command Triggers had major
> design problems, and Dimitri was doing significant rewrites to try to
> fix that. Anyone who did not th
On fre, 2012-02-10 at 17:44 +0100, Jean-Baptiste Quenot wrote:
> Dear hackers,
>
> Thanks for the work on PLPython result metadata, it is very useful! I
> just came across a crash when trying to access this metadata on the
> result of an UPDATE, which obviously cannot return any tuple (unless
> y
2012/4/15 Heikki Linnakangas :
> On 15.04.2012 13:47, Pavel Stehule wrote:
>>
>> is somewhere documented sense of foo--unpackaged--version.sql files?
>
>
> See section 35.15.4. Extension Updates, paragraph starting with "The update
> mechanism can be used to solve an important special case: convert
Robert Haas writes:
> On Thu, Apr 5, 2012 at 2:39 AM, Hitoshi Harada wrote:
>> On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane wrote:
>>> Given the lack of complaints since 9.0, maybe we should not fix this
>>> but just redefine the new behavior as being correct? But it seems
>>> mighty inconsistent t
2012/4/15 Tom Lane :
> Pavel Stehule writes:
>> We can raise warning from CREATE OR REPLACE FUNCTION - but I would to
>> like have plpgsql_check_function inside core - and it is better place
>> for this and similar issues.
>
> I agree. This is a perfectly legal use of nested declaration scopes,
>
Simon Riggs writes:
> If we can do Triage Week at the beginning, that will keep out the ones
> that aren't ready and allow us to focus our attention on the ones we
> really care about.
I think there's some merit in this idea, but there needs to be time
allocated to examine all the large patches b
Simon Riggs writes:
> I completely agree that somebody has to be willing to say No, since we
> all agree that the default for any patch is non-acceptance.
> My first observation is that if No is received early enough for
> something to be done, then the outcome could be different. It was not
> cl
Pavel Stehule writes:
> We can raise warning from CREATE OR REPLACE FUNCTION - but I would to
> like have plpgsql_check_function inside core - and it is better place
> for this and similar issues.
I agree. This is a perfectly legal use of nested declaration scopes,
so it would be totally inappro
Dimitri Fontaine writes:
> Looks like we're missing out some operator properties, like the neutral
> element and if the operator is transitive, commutative or associative. I
> think I remember us talking about how knowing about operators being
> associative would also help optimize a class of join
On 15.04.2012 13:47, Pavel Stehule wrote:
is somewhere documented sense of foo--unpackaged--version.sql files?
See section 35.15.4. Extension Updates, paragraph starting with "The
update mechanism can be used to solve an important special case:
converting a "loose" collection of objects into
On Tue, Apr 10, 2012 at 3:26 PM, Kevin Grittner
wrote:
> Christopher Browne wrote:
>> Robert Haas wrote:
>
>>> CommitFests are a time for patches that are done or very nearly
>>> done to get committed, and a time for other patches to get
>>> reviewed if they haven't been already. If we make it
On Sat, Apr 7, 2012 at 9:51 PM, Robert Haas wrote:
> I think this basically just boils down to too many patches and not
> enough people. I was interested in Command Triggers from the
> beginning of this CommitFest, and I would have liked to pick it up
> sooner, but there were a LOT of patches to
On Sat, Apr 7, 2012 at 10:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> [ among other good points ]
>> ... On a related note, letting CommitFests go on for three
>> months because there's insufficient reviewer activity to get them done
>> in one or two is, in my opinion, not much of a solution.
On 04/15/2012 03:49 AM, Brendan Jurd wrote:
Hello hackers,
It turns out that in a PL/PgSQL function, you can DECLARE a variable
using the same name as one of the function parameters. This has the
effect of clobbering the parameter, for example:
...
I would suggest that if the user DECLARE
Hello
is somewhere documented sense of foo--unpackaged--version.sql files?
Regards
Pavel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Apr 11, 2012 at 6:59 PM, Robert Haas wrote:
> On Wed, Apr 11, 2012 at 1:39 PM, Joshua Berkus wrote:
>>> Ultimately, we're herding cats here. I don't think you're going to
>>> get
>>> the community to suddenly be willing to march in lockstep instead.
>>
>> If you, Peter, Simon, Robert, He
On Fri, Apr 13, 2012 at 5:33 PM, Robert Haas wrote:
> Currently, we have a problem with index-only scans in Hot Standby
> mode: the xmin horizon on the standby might lag the master, and thus
> an index-only scan might mistakenly conclude that no heap fetch is
> needed when in fact it is. I sugges
On Fri, Apr 6, 2012 at 8:19 AM, Tom Lane wrote:
> Greg Smith writes:
>> On 04/05/2012 04:27 PM, Simon Riggs wrote:
>>> It's shocking since after months of work and an especially extended
>>> edition CF, we expect people to deliver something, not just shunt the
>>> whole thing off as rejected with
2012/4/15 Brendan Jurd :
> On 15 April 2012 18:54, Pavel Stehule wrote:
>> 2012/4/15 Brendan Jurd :
>>> Perhaps it's a failure of imagination on my part, but I can't think of
>>> a legitimate reason for a programmer to deliberately use the same name
>>> to refer to a declared variable and a functi
2012/4/15 Boszormenyi Zoltan :
> 2012-04-14 18:15 keltezéssel, Peter Eisentraut írta:
>
>> On lör, 2012-04-14 at 08:23 -0400, Robert Haas wrote:
>>>
>>> On Sat, Apr 14, 2012 at 3:27 AM, Pavel Stehule
>>> wrote:
>
> It has a lot of sense. Without it, it's very difficult to do logical
>
2012-04-14 18:15 keltezéssel, Peter Eisentraut írta:
On lör, 2012-04-14 at 08:23 -0400, Robert Haas wrote:
On Sat, Apr 14, 2012 at 3:27 AM, Pavel Stehule wrote:
It has a lot of sense. Without it, it's very difficult to do logical
replication on a table with no primary key.
(Whether or not pe
On 15 April 2012 18:54, Pavel Stehule wrote:
> 2012/4/15 Brendan Jurd :
>> Perhaps it's a failure of imagination on my part, but I can't think of
>> a legitimate reason for a programmer to deliberately use the same name
>> to refer to a declared variable and a function parameter. What would
>> be
Tom Lane writes:
> More generally, I'm not prepared to buy into the idea that the planner
> should be expected to recognize alternate spellings of "the same"
> expression. There are too many variants of that idea that are
> infeasible either because the planner doesn't have the necessary
> knowle
2012/4/15 Brendan Jurd :
> On 15 April 2012 17:55, Pavel Stehule wrote:
>> 2012/4/15 Brendan Jurd :
>>> It turns out that in a PL/PgSQL function, you can DECLARE a variable
>>> using the same name as one of the function parameters. This has the
>>> effect of clobbering the parameter, for example:
On 15 April 2012 17:55, Pavel Stehule wrote:
> 2012/4/15 Brendan Jurd :
>> It turns out that in a PL/PgSQL function, you can DECLARE a variable
>> using the same name as one of the function parameters. This has the
>> effect of clobbering the parameter, for example:
>>
...
>>
>> I would suggest t
2012/4/15 Brendan Jurd :
> Hello hackers,
>
> It turns out that in a PL/PgSQL function, you can DECLARE a variable
> using the same name as one of the function parameters. This has the
> effect of clobbering the parameter, for example:
>
> CREATE OR REPLACE FUNCTION declare_clobber(foo int)
> RETU
Hello hackers,
It turns out that in a PL/PgSQL function, you can DECLARE a variable
using the same name as one of the function parameters. This has the
effect of clobbering the parameter, for example:
CREATE OR REPLACE FUNCTION declare_clobber(foo int)
RETURNS int LANGUAGE plpgsql AS $$
44 matches
Mail list logo
