2009/12/21 Robert Haas :
> On Mon, Nov 16, 2009 at 5:01 PM, Pavel Stehule
> wrote:
>> Hello
>>
>> now - complete patch
>>
>> ToDo:
>> * enhance a documentation (any volunteer?)
>> * check name for backslash command
>
> I read through this patch tonight and I don't understand what the
> point of t
2009/12/20 Andrew Gierth :
>> "Pavel" == Pavel Stehule writes:
>
> > 2009/12/20 Tom Lane :
> >> I think that we've already expanded the capabilities of aggregates
> >> a great deal for 8.5, and we should let it sit as-is for a release
> >> or two and see what the real user demand is for ad
Robert Haas writes:
> Perhaps I should RTFP before sticking my neck out too far,
> but... will you serialize EXCLUDE (a =), EXCLUDE (a &&), and EXCLUDE
> (a ) differently?
No, and I'm not proposing to expose ASC/DESC/NULLS FIRST/LAST or
nondefault opclasses (to say nothing of non-btree AMs) or in
Tom Lane wrote:
> Bruce Momjian writes:
> > Basically there isn't much extra work to go from 8.3 to 8.4 compared to
> > 8.3 to 8.5.
>
> That might be true today, but it will stop being true once we replace
> the oid/relfilenode management hac^Wcode with the proposed new approach.
>
> > The other
On Mon, Dec 21, 2009 at 12:03 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Dec 20, 2009 at 10:17 PM, Tom Lane wrote:
>>> Attached is a WIP patch for addressing the problems mentioned in this
>>> thread:
>>> http://archives.postgresql.org/pgsql-hackers/2009-12/msg01764.php
>
>> I'm not re
Bruce Momjian writes:
> Basically there isn't much extra work to go from 8.3 to 8.4 compared to
> 8.3 to 8.5.
That might be true today, but it will stop being true once we replace
the oid/relfilenode management hac^Wcode with the proposed new approach.
> The other problem with moving to /contrib
On Sun, 20 Dec 2009, Bruce Momjian wrote:
The other problem with moving to /contrib is that I can't put out
pg_migrator updates independently of the main community release, which
could be bad.
Why not?
Marc G. FournierHub.Org Hosting Solutions S.A.
scra...@hub.or
Robert Haas writes:
> On Sun, Dec 20, 2009 at 10:17 PM, Tom Lane wrote:
>> Attached is a WIP patch for addressing the problems mentioned in this
>> thread:
>> http://archives.postgresql.org/pgsql-hackers/2009-12/msg01764.php
> I'm not really sure there's any point to this. Anyone who cares abou
2009/12/21 Greg Stark :
> Incidentally there are O(n) algorithms for finding the median (or any
> specific offset). It shouldn't be necessary to sort at all.
it is interesting information. It could to help with missing
optimalisations now.
Pavel
>
> I'm not sure which path this argues for - perh
Tom Lane wrote:
> Robert Haas writes:
> > I agree that pulling pg_migrator into contrib seems pretty sensible.
> > What I want to make sure we're on the same page about is which
> > versions the 8.5 pg_migrator will allow you to upgrade from and to. I
> > think we should at least support 8.3 -> 8
On Sun, Dec 20, 2009 at 10:17 PM, Tom Lane wrote:
> Attached is a WIP patch for addressing the problems mentioned in this
> thread:
> http://archives.postgresql.org/pgsql-hackers/2009-12/msg01764.php
>
> The main things that it does are (1) consider all index columns, not
> just the first one as f
On Sun, Dec 20, 2009 at 10:23 PM, Tom Lane wrote:
> Andres Freund writes:
>> On Monday 21 December 2009 02:23:39 Robert Haas wrote:
>>> A more important point is whether we really need to make this
>>> dependent on Perl 5.6 or later.
>
>> I dont see a platform without perl 5.6 where a new enough
On Sun, Dec 20, 2009 at 7:24 PM, Andres Freund wrote:
> On Monday 21 December 2009 04:23:57 Tom Lane wrote:
>> Andres Freund writes:
>> > On Monday 21 December 2009 02:23:39 Robert Haas wrote:
>> >> A more important point is whether we really need to make this
>> >> dependent on Perl 5.6 or later
On Thu, Dec 17, 2009 at 7:19 PM, Tom Lane wrote:
> KaiGai Kohei writes:
>> [ patch to remove EnableDisableRule's permissions check ]
>
> I don't particularly like this patch, mainly because I disagree with
> randomly removing permissions checks without any sort of plan about
> where they ought to
On Monday 21 December 2009 04:23:57 Tom Lane wrote:
> Andres Freund writes:
> > On Monday 21 December 2009 02:23:39 Robert Haas wrote:
> >> A more important point is whether we really need to make this
> >> dependent on Perl 5.6 or later.
> >
> > I dont see a platform without perl 5.6 where a new
Andres Freund writes:
> On Monday 21 December 2009 02:23:39 Robert Haas wrote:
>> A more important point is whether we really need to make this
>> dependent on Perl 5.6 or later.
> I dont see a platform without perl 5.6 where a new enough flex/bison is
> available...
That argument only holds wa
Attached is a WIP patch for addressing the problems mentioned in this
thread:
http://archives.postgresql.org/pgsql-hackers/2009-12/msg01764.php
The main things that it does are (1) consider all index columns, not
just the first one as formerly; and (2) try to generate a usable name
for index expre
Hi Simon, Hi all,
HS currently does the following in GetConflictingVirtualXIDs
TransactionId pxmin = proc->xmin;
/*
* We ignore an invalid pxmin because this means that backend
* has no snapshot and cannot get another one while we hold exclusive lock.
*/
if (TransactionIdIsValid(pxmin) && !
On Mon, Nov 16, 2009 at 5:01 PM, Pavel Stehule wrote:
> Hello
>
> now - complete patch
>
> ToDo:
> * enhance a documentation (any volunteer?)
> * check name for backslash command
I read through this patch tonight and I don't understand what the
point of this change is. That's something that shou
Hi,
On Monday 21 December 2009 02:23:39 Robert Haas wrote:
> A more important point is whether we really need to make this
> dependent on Perl 5.6 or later. What features are we using here that
> actually require Perl 5.6? I suspect the answer is "none, but we
> don't like writing the code in a
Incidentally there are O(n) algorithms for finding the median (or any
specific offset). It shouldn't be necessary to sort at all.
I'm not sure which path this argues for - perhaps Tom's position that
we need more optimiser infrastructure so we can see how to accomplish
this. Perhaps it means you s
On Sun, Dec 20, 2009 at 7:20 PM, John Naylor wrote:
> Greetings,
>
> Following up on my experimental patch last month to revamp the BKI
> infrastructure, I am proposing a less invasive set of changes with the
> hope of offering something committable. Some of these were discussed
> by Robert Haas a
(2009/12/19 12:05), Robert Haas wrote:
> On Fri, Dec 18, 2009 at 9:48 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Oh. This is more complicated than it appeared on the surface. It
>>> seems that the string "BLOB COMMENTS" actually gets inserted into
>>> custom dumps somewhere, so I'm not sure
On Sun, Dec 20, 2009 at 3:42 PM, Simon Riggs wrote:
> On Sat, 2009-12-19 at 20:59 +0200, Heikki Linnakangas wrote:
>> I put them on the TODO list at
>> https://wiki.postgresql.org/wiki/Hot_Standby_TODO, under the must-fix
>> category.
>
> I notice you also re-arranged other items on there, specifi
Michael Glaesemann writes:
> On Dec 20, 2009, at 13:58 , Tom Lane wrote:
>> * Append "_index" not "_key" if it's not a constraint-related index.
> "_idx" instead of "_index" keeps things a bit shorter (and a couple of
> keystrokes further from NAMEDATALEN). There's precedent for
> abbreviatio
> "Pavel" == Pavel Stehule writes:
> 2009/12/20 Tom Lane :
>> I think that we've already expanded the capabilities of aggregates
>> a great deal for 8.5, and we should let it sit as-is for a release
>> or two and see what the real user demand is for additional
>> features.
>>
>> I'm p
Martin Pihlak writes:
> Tom Lane wrote:
>> According to what? I can't find any documentation whatsoever on what
>> arguments that function is supposed to get.
> According to
> http://www.postgresql.org/docs/8.4/static/sql-createforeigndatawrapper.html:
> "The validator function must take two ar
Tom Lane wrote:
> According to what? I can't find any documentation whatsoever on what
> arguments that function is supposed to get.
>
> regards, tom lane
>
According to
http://www.postgresql.org/docs/8.4/static/sql-createforeigndatawrapper.html:
"The validator function m
On Dec 20, 2009, at 13:58 , Tom Lane wrote:
* Append "_index" not "_key" if it's not a constraint-related index.
"_idx" instead of "_index" keeps things a bit shorter (and a couple of
keystrokes further from NAMEDATALEN). There's precedent for
abbreviations with automatic naming in Postgr
Dimitri Fontaine writes:
> Le 20 déc. 2009 à 22:08, Tom Lane a écrit :
>> Another risk is that features added now might preclude adding others
>> later.
> Now, I have no idea if augmenting the aggregate properties with an optional
> sorting step is the right approach, but it sounds right on spot
Hi from a real user :)
Le 20 déc. 2009 à 22:08, Tom Lane a écrit :
> Pavel Stehule writes:
>> b) general support for "preordered aggregates".
>
> I think that we've already expanded the capabilities of aggregates
> a great deal for 8.5, and we should let it sit as-is for a release
> or two and s
2009/12/20 Tom Lane :
> Pavel Stehule writes:
>> I am thinking about implementation of median function. This function
>> should be implemented in two ways:
>
>> a) direct entering an ORDER BY clause for median funcall in gram.y
>> b) general support for "preordered aggregates".
>
>> I prefer plan
Pavel Stehule writes:
> I am thinking about implementation of median function. This function
> should be implemented in two ways:
> a) direct entering an ORDER BY clause for median funcall in gram.y
> b) general support for "preordered aggregates".
> I prefer plan b, because there are more simil
On Sat, 2009-12-19 at 23:22 +0900, Hiroyuki Yamada wrote:
> >Do people want more time to play with hot standby? Otherwise alpha3
> >should go out on Monday or Tuesday.
> >
>
> Well, I want to know whether the problem I refered to
> in http://archives.postgresql.org/pgsql-hackers/2009-12/msg01641
Hello
I am thinking about implementation of median function. This function
should be implemented in two ways:
a) direct entering an ORDER BY clause for median funcall in gram.y
b) general support for "preordered aggregates".
I prefer plan b, because there are more similar aggregates - like
Quant
On Sat, 2009-12-19 at 20:59 +0200, Heikki Linnakangas wrote:
> I put them on the TODO list at
> https://wiki.postgresql.org/wiki/Hot_Standby_TODO, under the must-fix
> category.
I notice you also re-arranged other items on there, specifically the
notion that starting from a shutdown checkpoint is
On Sat, 2009-12-19 at 14:20 +0200, Peter Eisentraut wrote:
> Do people want more time to play with hot standby? Otherwise alpha3
> should go out on Monday or Tuesday.
No thanks. There were no known bugs in the code I committed, excepting
the need to address VACUUM FULL. That will take longer tha
On 2009-12-20 18:20 +0200, Tom Lane wrote:
James William Pye writes:
But it doesn't seem to want to stop configure'ing on my fbsd8/amd64 box:
Usually that means timestamp skew, ie file timestamps are later than
your system clock.
I've hit this problem before and could not figure out what wa
On Dec 20, 2009, at 9:20 AM, Tom Lane wrote:
> Usually that means timestamp skew, ie file timestamps are later than
> your system clock.
Yep. It's working now.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/ma
Robert Haas writes:
> I agree that pulling pg_migrator into contrib seems pretty sensible.
> What I want to make sure we're on the same page about is which
> versions the 8.5 pg_migrator will allow you to upgrade from and to. I
> think we should at least support 8.3 -> 8.5 and 8.4 -> 8.5. If you
On Sat, 2009-12-19 at 20:59 +0200, Heikki Linnakangas wrote:
> Well, that was the criteria I used to decide whether to commit or not.
> Not everyone agreed to begin with, and the reason I used that criteria
> was a selfish one: I didn't want to be forced to fix loose ends after
> the commitfest my
On Sun, Dec 20, 2009 at 2:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Dec 20, 2009 at 1:49 PM, Tom Lane wrote:
>>> There's a reason to clutter, eg, pg_dump with multiple version support.
>>> I don't see the argument for doing so with pg_migrator. Separate source
>>> code branches se
Robert Haas writes:
> On Sun, Dec 20, 2009 at 1:49 PM, Tom Lane wrote:
>> There's a reason to clutter, eg, pg_dump with multiple version support.
>> I don't see the argument for doing so with pg_migrator. Separate source
>> code branches seem like a much better idea.
> I guess we have to look a
Hi
I've completed a (first) working version of a extension that allows
easier introspection of composite types from SQL and pl/PGSQL.
The original proposal and ensuing discussion can be found here:
http://archives.postgresql.org/pgsql-hackers/2009-11/msg00695.php
The extension can be found on:
On Sun, Dec 20, 2009 at 1:49 PM, Tom Lane wrote:
>> if (GET_MAJOR_VERSION(ctx.old.pg_version) <= 803 &&
>> GET_MAJOR_VERSION(ctx.new.pg_version) >= 804)
>
> Well, yeah, you can probably make it work if you're willing to carry
> enoguh version tests and alternate sets of logic in the so
I wrote:
> Although, having said that, I realize we just opened that can of worms
> with the exclusion-constraint patch:
> regression=# create table foo (f1 text, exclude (lower(f1) with =));
> NOTICE: CREATE TABLE / EXCLUDE will create implicit index "foo_exclusion"
> for table "foo"
> CREATE T
Bruce Momjian writes:
> Tom Lane wrote:
>> I think you're just creating useless work for yourself by imagining that
>> pg_migrator is backend-version-independent. In fact, I was thinking
>> about proposing that we pull it in as a contrib module. Because so much
>> of what it does is tied to deta
I just got done fixing a different problem in that area, and then I
noticed this:
regression=# create table src (f1 text);
CREATE TABLE
regression=# create index srclower on src(lower(f1));
CREATE INDEX
regression=# comment on column srclower.pg_expression_1 is 'a comment';
COMMENT
regression=# cr
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> What I had in mind was more like
> >>
> >> static Oid next_pg_class_oid = InvalidOid;
> >>
> >> void
> >> set_next_pg_class_oid(Oid oid)
> >> {
> >>next_pg_class_oid = oid;
> >> }
>
> > Does exporting a function buy us anythin
Bruce Momjian writes:
> Tom Lane wrote:
>> What I had in mind was more like
>>
>> static Oid next_pg_class_oid = InvalidOid;
>>
>> void
>> set_next_pg_class_oid(Oid oid)
>> {
>> next_pg_class_oid = oid;
>> }
> Does exporting a function buy us anything vs. exporting a variable?
Hmm, probab
Martin Pihlak writes:
> It appears that the function for validating generic options to a FDW,
> SERVER and USER MAPPING is always passed a catalog oid of 0. Whereas
> it should actually be passed the oid of the catalog that the options
> apply to.
According to what? I can't find any documentatio
James William Pye writes:
> But it doesn't seem to want to stop configure'ing on my fbsd8/amd64 box:
Usually that means timestamp skew, ie file timestamps are later than
your system clock.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
2009/12/19 Marko Tiikkaja :
> On 2009-12-15 23:10 +0200, Tom Lane wrote:
>>
>> Andrew Gierth writes:
>>>
>>> Notice that there are cases where agg(distinct x order by x) is
>>> nondeterministic while agg(distinct x order by x,y) is deterministic.
>>
>> Well, I think what you're really describing i
It appears that the function for validating generic options to a FDW,
SERVER and USER MAPPING is always passed a catalog oid of 0. Whereas
it should actually be passed the oid of the catalog that the options
apply to.
Attached patch fixes the issue by passing the proper catalog id from
transformGe
On Dec 20, 2009, at 1:36 AM, Peter Eisentraut wrote:
> Please check that it is sane.
I'm up, so:
Works for me on snow leopard.
But it doesn't seem to want to stop configure'ing on my fbsd8/amd64 box:
$ ./configure --prefix=/src/build/pg85a3
$ gmake # GNU make 3.81
... (last few lines before i
Peter Eisentraut wrote:
> Could we create an option to create index names automatically, so you'd
> only have to write
>
> CREATE INDEX ON foo (a);
>
> which would pick a name like foo_a_idx.
Why wouldn't it default to a name more like:
CREATE INDEX "foo(a)" on foo(a);
which would extend p
Alpha3 has been bundled and is available at
http://developer.postgresql.org/~petere/alpha/
Please check that it is sane.
No one has written an announcement yet. I will do it unless someone
feels inspired. Release should be Monday or Tuesday.
--
Sent via pgsql-hackers mailing list (pgsql-hac
On Dec 20, 2009, at 12:03 AM, Tom Lane wrote:
> Why not code a loop around one of the existing SPI execution functions?
*shrug* seemed nicer to push it on the parser than to force the user to split
up the statements/calls. Or split up the statements myself(well, the parser
does it so swimmingly
58 matches
Mail list logo
