On tis, 2009-11-10 at 16:22 +0900, Itagaki Takahiro wrote:
> I'm working on partitioning syntax, amd encountered a dependency issue.
> When we define partition, also create an implicit CHECK constraint.
> The constraint should be kept until the pg_inherits entry is removed.
> But we cannot have a d
I'm working on partitioning syntax, amd encountered a dependency issue.
When we define partition, also create an implicit CHECK constraint.
The constraint should be kept until the pg_inherits entry is removed.
But we cannot have a dependency from the constraint to the inheritance.
An idea is addi
On Mon, Nov 09, 2009 at 09:01:14PM -0500, Bruce Momjian wrote:
>
> I have applied the attached patch to document that FOUND is not affected
> by EXECUTE, while GET DIAGNOSTICS is.
One minor nit here:
> Index: doc/src/sgml/plpgsql.sgml
> ===
I wrote:
> My inclination is to continue assuming that the EINVAL is a new bug
> introduced in Snow Leopard. I sure hope they fix it in 10.6.2 though.
> If they don't, we may have to think about a workaround, messy as that
> will apparently be.
10.6.2 is out, and it appears to fix the bug --- if
Andrew Dunstan writes:
> Simon Riggs wrote:
>> HS writes a WAL record for subtransactions at the point that the subxid
>> cache overflows for any single transaction. Current cache size = 64.
>> Top-level transaction then writes one additional WAL record every
>> additional 64 subxids after that. T
I have applied the attached patch to document that FOUND is not affected
by EXECUTE, while GET DIAGNOSTICS is.
---
Robert Haas wrote:
> On Fri, Oct 23, 2009 at 12:05 PM, Pavel Stehule
> wrote:
> > 2009/10/23 Robert Haas :
Simon Riggs wrote:
On Thu, 2009-10-08 at 11:50 -0400, Tom Lane wrote:
Robert Haas writes:
Subcommitting every single row is going to be really painful,
especially after Hot Standby goes in and we have to issue a WAL record
after every 64 subtransactions (AIUI).
Yikes ... I ha
Robert Haas wrote:
> On Thu, Oct 22, 2009 at 2:28 PM, Josh Berkus wrote:
> > All,
> >
> > Wouldn't per *tablespace* costs make more sense?
> >
> > --Josh
>
> Yes, we already had several votes in favor of that approach. See upthread.
Added to TODO:
Allow per-tablespace random_page_cost
On Mon, 2009-11-09 at 12:15 +0200, Peter Eisentraut wrote:
> > Is this required by the standard or are we going past the standard?
>
> This is part of the SQL standard.
+1
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Tom Lane wrote:
> Under old-style semantics this will do what the programmer thought.
> Under Oracle semantics it will return the first table row. If
> do-something is security critical then this is enough to call it
> an exploit. The reverse direction (code meant for Oracle behavior
> breaks und
Andrew Dunstan wrote:
> >You can set the field separator to ',' but you can't do a
> > \pset format csv
> >and get CSV with correct quoting, escaping etc AFAICS. It'll
> >still break on line wrapping if wrapping is enabled, and with
> >newlines in the data.
> >
> >If that would be a useful addit
Tom Lane wrote:
> Greg Stark writes:
> > While i agree this looks nicer I wonder what it does to things like
> > excel/gnumeric/ooffice auto-recognizing table layouts and importing
> > files. I'm not sure our old format was so great for this so maybe this
> > is actually an improvement I'm asking
On Mon, 2009-11-09 at 18:03 +, Greg Stark wrote:
> Out of curiosity, is this feature at all similar to SQL assertions?
> What would we be missing to turn this into them?
I addressed that here:
http://archives.postgresql.org/pgsql-hackers/2009-11/msg00049.php
The exclusion constraint mechanis
> I would personally prefer not to be involved in the management of the
> next CommitFest. Having done all of the July CommitFest and a good
> chunk of the September CommitFest, I am feeling a bit burned out.
Dave, Selena and I will all be in Japan during the first week of the CF.
I can help af
Tom Lane escribió:
> Andrew Dunstan writes:
> > This is a pretty good short explanation of how to deal with shift/reduce
> > problems in bison. With your permission I'm going to copy it to the Wiki
>
> If you like, but I think the part about figuring out which production
> is the problem seemed
Greg Stark escribió:
> Out of curiosity, is this feature at all similar to SQL assertions?
> What would we be missing to turn this into them?
I see no relationship to assertions. Those are not tied to any
particular table, and are defined with any random expression you care to
think of.
--
Alv
On Mon, Nov 9, 2009 at 1:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Nov 9, 2009 at 10:57 AM, Tom Lane wrote:
>>> Too bad you don't have debug symbols ... it'd be interesting to see
>>> how long that list is.
>
>> I stopped it a couple of times. Lengths of list1, list2 respectively:
Robert Haas writes:
> On Mon, Nov 9, 2009 at 10:57 AM, Tom Lane wrote:
>> Too bad you don't have debug symbols ... it'd be interesting to see
>> how long that list is.
> I stopped it a couple of times. Lengths of list1, list2 respectively:
> 8876, 20
> 14649, 18
> 15334, 10
> 17148, 18
> 18173
Greg Stark writes:
> On Mon, Nov 9, 2009 at 3:01 PM, Tom Lane wrote:
>> That requires that you know how to copy the aggregate's state. You do
>> not. (In some cases the aggregate function has extra state besides the
>> nominal transition datum...)
> That's relatively unusual and usually a bad
On Mon, Nov 9, 2009 at 5:12 PM, David E. Wheeler wrote:
> On Nov 8, 2009, at 7:43 PM, Jeff Davis wrote:
>
>> Either of those names are fine with me, too. The current name is a
>> somewhat shortened version of the name "operator-based exclusion
>> constraints", so we can also just use that name. Or
On Mon, Nov 9, 2009 at 10:57 AM, Tom Lane wrote:
> Robert Haas writes:
>> I've stopped the query more than 10 times now and EVERY SINGLE ONE
>> finds it in list_concat_unique_ptr(). :-(
>
> Too bad you don't have debug symbols ... it'd be interesting to see
> how long that list is.
[ teaches se
On Nov 8, 2009, at 7:43 PM, Jeff Davis wrote:
Either of those names are fine with me, too. The current name is a
somewhat shortened version of the name "operator-based exclusion
constraints", so we can also just use that name. Or, just "exclusion
constraints".
(exclusion constraints)++
David
On Mon, Nov 09, 2009 at 10:01:53AM -0500, Tom Lane wrote:
> Heikki Linnakangas writes:
> > One idea is to take a copy of the state datum after each row. Then,
> > instead of initializing the aggregate from scratch, you can "roll back"
> > to an earlier copied state. It doesn't always help, but mig
On Mon, Nov 9, 2009 at 3:01 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> One idea is to take a copy of the state datum after each row. Then,
>> instead of initializing the aggregate from scratch, you can "roll back"
>> to an earlier copied state. It doesn't always help, but might be a part
Jan Otto writes:
> a quick check on mac os x 10.4 und 10.5 confirmed that this behaviour/
> bug is not present like described in this article. probably it was in
> 10.0.x... i have no older version of mac os x available here to check.
Yeah, I thought we'd probably have heard about it before now i
On Fri, Nov 06, 2009 at 09:53:20PM -0500, Andrew Dunstan wrote:
>
>
> Joshua Tolley wrote:
>> I looked through the
>> regression tests and didn't find any that used plperl -- should we add one
>> for
>> this (or for this and all kinds of other stuff)? Is there some way to make
>> running the regr
On Nov 7, 1:21 am, t...@sss.pgh.pa.us (Tom Lane) wrote:
> I believe we had consensus that plpgsql should offer the following three
> behaviors when a name in a SQL query could refer to either a plpgsql
> variable or a column from a table of the query:
> * prefer the plpgsql variable (plpgsq
Hey Jan, did you get any response to that bug report? Somebody else
dug up a document suggesting that this might be intentional on Apple's
part:
http://archives.postgresql.org/pgsql-bugs/2009-11/msg00040.php
i was not subscribed to pgsql-bugs list. i have read this message now
and
see he is r
Robert Haas writes:
> I've stopped the query more than 10 times now and EVERY SINGLE ONE
> finds it in list_concat_unique_ptr(). :-(
Too bad you don't have debug symbols ... it'd be interesting to see
how long that list is.
> It's also using about 12x as much RAM as the GEQO version.
No surpri
On Nov 7, 1:21 am, t...@sss.pgh.pa.us (Tom Lane) wrote:
> I believe we had consensus that plpgsql should offer the following three
> behaviors when a name in a SQL query could refer to either a plpgsql
> variable or a column from a table of the query:
> * prefer the plpgsql variable (plpgsq
On Monday 09 November 2009 16:28:46 Robert Haas wrote:
> On Mon, Nov 9, 2009 at 10:27 AM, Andres Freund wrote:
> > On Monday 09 November 2009 16:23:52 Robert Haas wrote:
> >> On Mon, Nov 9, 2009 at 10:21 AM, Andres Freund
wrote:
> >> > On Monday 09 November 2009 16:18:10 Robert Haas wrote:
> >>
On Mon, Nov 9, 2009 at 10:18 AM, Robert Haas wrote:
> I think I just ran smack dab into this bug on 8.3.8 (RPM:
> postgresql-8.3.8-1.fc10.i386). I had a query that wasn't coming out
> very well with the default settings so I raised the collapse limits
> and let GEQO have a crack at it. This was
ERROR: could not read directory "pg_tblspc/16464": Invalid
argument
STATEMENT: DROP TABLESPACE testspace;
Hmm ... can't reproduce this here, not even on OSX. From the
version
number I suspect you are using unreleased Snow Leopard. I'd venture
it's a newly-introduced kernel bug and you n
On Mon, Nov 9, 2009 at 10:27 AM, Andres Freund wrote:
> On Monday 09 November 2009 16:23:52 Robert Haas wrote:
>> On Mon, Nov 9, 2009 at 10:21 AM, Andres Freund wrote:
>> > On Monday 09 November 2009 16:18:10 Robert Haas wrote:
>> >> On Sun, Jul 19, 2009 at 4:00 PM, Tom Lane wrote:
>> >> > Log M
On Monday 09 November 2009 16:23:52 Robert Haas wrote:
> On Mon, Nov 9, 2009 at 10:21 AM, Andres Freund wrote:
> > On Monday 09 November 2009 16:18:10 Robert Haas wrote:
> >> On Sun, Jul 19, 2009 at 4:00 PM, Tom Lane wrote:
> >> > Log Message:
> >> > ---
> >> > Rewrite GEQO's gimme_tree f
2009/11/10 David Fetter :
> On Mon, Nov 09, 2009 at 11:20:39PM +0900, Hitoshi Harada wrote:
>> 2009/11/9 David Fetter :
>> > On Mon, Nov 09, 2009 at 06:39:54PM +0900, Hitoshi Harada wrote:
>> >> I'm not sure if it can be finished until the start of the next CF,
>> >> but I've been working on $subje
On Mon, Nov 9, 2009 at 10:21 AM, Andres Freund wrote:
> On Monday 09 November 2009 16:18:10 Robert Haas wrote:
>> On Sun, Jul 19, 2009 at 4:00 PM, Tom Lane wrote:
>> > Log Message:
>> > ---
>> > Rewrite GEQO's gimme_tree function so that it always finds a legal join
>> > sequence, even wh
On Monday 09 November 2009 16:18:10 Robert Haas wrote:
> On Sun, Jul 19, 2009 at 4:00 PM, Tom Lane wrote:
> > Log Message:
> > ---
> > Rewrite GEQO's gimme_tree function so that it always finds a legal join
> > sequence, even when the input "tour" doesn't lead directly to such a
> > sequen
On Sun, Jul 19, 2009 at 4:00 PM, Tom Lane wrote:
> Log Message:
> ---
> Rewrite GEQO's gimme_tree function so that it always finds a legal join
> sequence, even when the input "tour" doesn't lead directly to such a sequence.
> The stack logic that was added in 2004 only supported cases whe
On Mon, Nov 09, 2009 at 11:20:39PM +0900, Hitoshi Harada wrote:
> 2009/11/9 David Fetter :
> > On Mon, Nov 09, 2009 at 06:39:54PM +0900, Hitoshi Harada wrote:
> >> I'm not sure if it can be finished until the start of the next CF,
> >> but I've been working on $subject. This work intends to extend
Heikki Linnakangas writes:
> One idea is to take a copy of the state datum after each row. Then,
> instead of initializing the aggregate from scratch, you can "roll back"
> to an earlier copied state. It doesn't always help, but might be a part
> of the solution.
That requires that you know how t
2009/11/9 David Fetter :
> On Mon, Nov 09, 2009 at 06:39:54PM +0900, Hitoshi Harada wrote:
>> I'm not sure if it can be finished until the start of the next CF,
>> but I've been working on $subject. This work intends to extend
>> current limited frame types of window functions such like below;
>
>
2009/11/9 Andrew Gierth :
>> "Heikki" == Heikki Linnakangas
>> writes:
>
> Heikki> Yeah, we need the reinitialization support to handle the generic
> case.
>
> Heikki> One idea is to take a copy of the state datum after each row.
>
> Some existing aggregates, notably array_agg, rely on
> "Heikki" == Heikki Linnakangas
> writes:
Heikki> Yeah, we need the reinitialization support to handle the generic case.
Heikki> One idea is to take a copy of the state datum after each row.
Some existing aggregates, notably array_agg, rely on the assumption
that this never happens.
On Mon, Nov 09, 2009 at 06:39:54PM +0900, Hitoshi Harada wrote:
> I'm not sure if it can be finished until the start of the next CF,
> but I've been working on $subject. This work intends to extend
> current limited frame types of window functions such like below;
This is very, very exciting. Is
On Sun, 2009-11-08 at 21:17 +, Simon Riggs wrote:
> Not sure I see why this is good. Why is issuing CREATE TYPE so much
> easier than using CREATE TABLE? Is it worth the extra syntax and code to
> support it? Can we do anything additional as a result of this?
These are tools to improve databas
Hitoshi Harada wrote:
> That means moving average is initialized again on frame-off situation
> as the frame moves down. I know that may kill it's performance but
> reasons above result in my proposing design.
Yeah, we need the reinitialization support to handle the generic case.
One idea is to t
I'm not sure if it can be finished until the start of the next CF, but
I've been working on $subject. This work intends to extend current
limited frame types of window functions such like below;
- ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
- ORDER BY x RANGE BETWEEN CURRENT ROW AND f FOLLOWI
*snip*
One pretty major fly in the ointment is that neither Hot Standby nor
Streaming Replication has been committed or shows much sign of being
about to be committed. I think this is bad. These are big features
that figure to have some bugs and break some things. If they're not
committed in
49 matches
Mail list logo
