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
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
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 pretty
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
keeps running configure again
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
2009/12/19 Marko Tiikkaja marko.tiikk...@cs.helsinki.fi:
On 2009-12-15 23:10 +0200, Tom Lane wrote:
Andrew Gierthand...@tao11.riddles.org.uk 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,
James William Pye li...@jwp.name 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
Martin Pihlak martin.pih...@gmail.com 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
Bruce Momjian br...@momjian.us 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, probably
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
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=#
Bruce Momjian br...@momjian.us 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
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 TABLE
On Sun, Dec 20, 2009 at 1:49 PM, Tom Lane t...@sss.pgh.pa.us 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
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:
Robert Haas robertmh...@gmail.com writes:
On Sun, Dec 20, 2009 at 1:49 PM, Tom Lane t...@sss.pgh.pa.us 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
On Sun, Dec 20, 2009 at 2:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Dec 20, 2009 at 1:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
There's a reason to clutter, eg, pg_dump with multiple version support.
I don't see the argument for doing so with
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
Robert Haas robertmh...@gmail.com 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
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:
On 2009-12-20 18:20 +0200, Tom Lane wrote:
James William Pyeli...@jwp.name 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
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 than
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
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
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.php
is
Pavel Stehule pavel.steh...@gmail.com 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
2009/12/20 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
Hi from a real user :)
Le 20 déc. 2009 à 22:08, Tom Lane a écrit :
Pavel Stehule pavel.steh...@gmail.com 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
Dimitri Fontaine dfonta...@hi-media.com 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
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 Postgres,
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 must
Martin Pihlak martin.pih...@gmail.com 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
Pavel == Pavel Stehule pavel.steh...@gmail.com writes:
2009/12/20 Tom Lane t...@sss.pgh.pa.us:
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
Michael Glaesemann g...@seespotcode.net 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
On Sun, Dec 20, 2009 at 3:42 PM, Simon Riggs si...@2ndquadrant.com 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
(2009/12/19 12:05), Robert Haas wrote:
On Fri, Dec 18, 2009 at 9:48 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haasrobertmh...@gmail.com 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
On Sun, Dec 20, 2009 at 7:20 PM, John Naylor jcnay...@gmail.com 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
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
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 way
On Mon, Nov 16, 2009 at 5:01 PM, Pavel Stehule pavel.steh...@gmail.com 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
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)
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
Andres Freund and...@anarazel.de 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
On Monday 21 December 2009 04:23:57 Tom Lane wrote:
Andres Freund and...@anarazel.de 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
On Thu, Dec 17, 2009 at 7:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
KaiGai Kohei kai...@ak.jp.nec.com 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
On Sun, Dec 20, 2009 at 7:24 PM, Andres Freund and...@anarazel.de wrote:
On Monday 21 December 2009 04:23:57 Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On Monday 21 December 2009 02:23:39 Robert Haas wrote:
A more important point is whether we really need to make this
On Sun, Dec 20, 2009 at 10:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@anarazel.de 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
On Sun, Dec 20, 2009 at 10:17 PM, Tom Lane t...@sss.pgh.pa.us 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
Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
2009/12/21 Greg Stark gsst...@mit.edu:
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
Robert Haas robertmh...@gmail.com writes:
On Sun, Dec 20, 2009 at 10:17 PM, Tom Lane t...@sss.pgh.pa.us 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
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.
Bruce Momjian br...@momjian.us 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
On Mon, Dec 21, 2009 at 12:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Dec 20, 2009 at 10:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Attached is a WIP patch for addressing the problems mentioned in this
thread:
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
Robert Haas robertmh...@gmail.com writes:
Perhaps I should RTFP before sticking my neck out too far,
but... will you serialize EXCLUDE (a =), EXCLUDE (a ), and EXCLUDE
(a some other operator) differently?
No, and I'm not proposing to expose ASC/DESC/NULLS FIRST/LAST or
nondefault opclasses (to
2009/12/20 Andrew Gierth and...@tao11.riddles.org.uk:
Pavel == Pavel Stehule pavel.steh...@gmail.com writes:
2009/12/20 Tom Lane t...@sss.pgh.pa.us:
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
2009/12/21 Robert Haas robertmh...@gmail.com:
On Mon, Nov 16, 2009 at 5:01 PM, Pavel Stehule pavel.steh...@gmail.com
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
58 matches
Mail list logo
