On 11.11.2010 00:49, Tom Lane wrote:
I wrote:
What happens if you error out in between? Or is it assumed that the
*entire* sequence is a critical section? If it has to be that way,
one might wonder what's the point of trying to split it into multiple
WAL records.
Or, to be more concrete:
On 11.11.2010 00:49, Tom Lane wrote:
I wrote:
What happens if you error out in between? Or is it assumed that the
*entire* sequence is a critical section? If it has to be that way,
one might wonder what's the point of trying to split it into multiple
WAL records.
Or, to be more concrete:
On Wed, Nov 10, 2010 at 6:13 PM, Andrew Dunstan and...@dunslane.net wrote:
Yeah, it's complaining about not finding bison, but configure managed to
find bison just fine. Are you sure the right make was installed? It looks
suspicious because it's not talking about msys virtual maths like the
On 11/11/2010 06:58 AM, Dave Page wrote:
On Wed, Nov 10, 2010 at 6:13 PM, Andrew Dunstanand...@dunslane.net wrote:
Yeah, it's complaining about not finding bison, but configure managed to
find bison just fine. Are you sure the right make was installed? It looks
suspicious because it's not
Robert Haas robertmh...@gmail.com writes:
I think the big hurdle with contrib isn't
that it's called contrib but that it's not part of the core server
and, in many cases, enabling a contrib module means editing
postgresql.conf and bouncing the server. Of course, there are
certainly SOME
Robert Haas robertmh...@gmail.com writes:
work will help with that somewhat, but there's still that nasty
business of needing to update shared_preload_libraries and bounce the
server, at least for some modules.
We have 45 contribs (ls -l contrib | grep -c ^d), out of which:
auto_explain is
On 11/10/2010 07:51 PM, Robert Haas wrote:
(And no, don't you dare breathe a word about git making that
all automagically better. I have enough back-patching experience with
git by now to be unimpressed; in fact, I notice that its rename-tracking
feature falls over entirely when trying to
On Thu, Nov 11, 2010 at 1:04 PM, Andrew Dunstan and...@dunslane.net wrote:
No, all you need to unpack those is the basic-bsdtar package.
Ahh, OK. That seems to be in the MinGW (compiler) section of the
downloads for some reason.
But to save
you the pain of all this, I have copied the three
Peter Eisentraut pete...@gmx.net writes:
On tor, 2010-10-21 at 16:59 -0400, Tom Lane wrote:
Actually, the only reason this is even up for discussion is that
there's
no configure option to set DEFAULT_PGSOCKET_DIR. If there were, and
debian were using it, then pg_config --configure would tell
Postgres supports ARRAY data types well, but there are some
more array functions in the SQL standard. Also, the standard
has MULTISET data type, that is an unordered array.
It looks easy to support additional array functions. There
might be some confusion to treat multi-dimensional arrays
with
Hello list,
Sorry for not replying to the bug list, but I didn't receive that
message. It's about
http://archives.postgresql.org/pgsql-bugs/2010-11/msg00065.php
The test case there with remark about LBOUND is incorrect; we first
found the bug on a different result. In the process of finding
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
GiST is different. When you insert a key to a leaf page, you (sometimes)
need to adjust the parent pointer to reflect the new key as well. B-tree
tolerates incomplete splits with the 'next page' pointer, but that is
not
On Thu, Nov 11, 2010 at 8:28 AM, Andrew Dunstan and...@dunslane.net wrote:
It's intentional behavior. It gives up when there are too many
differences to avoid being slow.
And, it's configurable, at least to diff and merge. If it's not
available in all the other porcelains, yes, that would be
Aidan Van Dyk ai...@highrise.ca writes:
It's intentional behavior. It gives up when there are too many
differences to avoid being slow.
And, it's configurable, at least to diff and merge. If it's not
available in all the other porcelains, yes, that would be bugs that
should be fixed:
On Thu, Nov 11, 2010 at 17:24, Tom Lane t...@sss.pgh.pa.us wrote:
Given that we have, in fact, never renamed any files in the history of
the project, I'm wondering exactly why it thinks that the number of
potential rename/copy targets isn't zero. The whole thing smells
broken to me, which is
Aidan Van Dyk ai...@highrise.ca writes:
Can you share what commit you were trying to cherry-pick, and what
your resulting commit was? I can try and take a quick look at them
and see if there is something obviously fishy with how git's trying to
merge the new commit on the old tree...
See
Marti Raudsepp ma...@juffo.org writes:
On Thu, Nov 11, 2010 at 17:24, Tom Lane t...@sss.pgh.pa.us wrote:
Given that we have, in fact, never renamed any files in the history of
the project, I'm wondering exactly why it thinks that the number of
potential rename/copy targets isn't zero.
On 11/11/2010 10:17 AM, Aidan Van Dyk wrote:
We should adopt that philosophy. I suggest we limit all tables in future to
1m rows in the interests of speed.
As long as it's configurable, and if it would make operations on
smaller tables faster, than go for it.
And we should by defualt limit
On ons, 2010-11-10 at 20:30 +0900, Fujii Masao wrote:
On Thu, Dec 17, 2009 at 8:05 AM, Peter Eisentraut pet...@postgresql.org
wrote:
Log Message:
---
Don't unblock SIGQUIT in the SIGQUIT handler
This was possibly linked to a deadlock-like situation in glibc syslog code
On Thu, Nov 11, 2010 at 04:15:34AM +0200, Marko Tiikkaja wrote:
Hi all,
The discussion around wCTE during the last week or so has brought to
my attention that we don't actually have a consensus on how exactly
wCTEs should behave. The question seems to be whether or not a
statement should
Dave Page wrote:
Thanks - installed.
As a matter of policy, I do not want to drop support for a FOSS build tool
chain on Windows if at all avoidable.
Nor I, however I only have limited time to dedicate to that goal.
One thing to think about is that since PostGIS uses MingW/PGXS on
On 2010-11-11 6:41 PM +0200, David Fetter wrote:
On Thu, Nov 11, 2010 at 04:15:34AM +0200, Marko Tiikkaja wrote:
The discussion around wCTE during the last week or so has brought to
my attention that we don't actually have a consensus on how exactly
wCTEs should behave. The question seems to
On 11/11/2010 11:43 AM, Mark Cave-Ayland wrote:
Dave Page wrote:
Thanks - installed.
As a matter of policy, I do not want to drop support for a FOSS
build tool
chain on Windows if at all avoidable.
Nor I, however I only have limited time to dedicate to that goal.
One thing to think
On 11 November 2010 16:50, Marko Tiikkaja marko.tiikk...@cs.helsinki.fiwrote:
On 2010-11-11 6:41 PM +0200, David Fetter wrote:
On Thu, Nov 11, 2010 at 04:15:34AM +0200, Marko Tiikkaja wrote:
The discussion around wCTE during the last week or so has brought to
my attention that we don't
On Thu, Nov 11, 2010 at 4:51 PM, Andrew Dunstan and...@dunslane.net wrote:
Interesting. Doesn't EDB's PostgresPlus package include PostGIS, and isn't
its Windows version build with MSVC?
Yes - it's a PITA as we have to have a dummy build of the server in
mingw/msys to compile PostGIS and
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2010-11-11 6:41 PM +0200, David Fetter wrote:
On Thu, Nov 11, 2010 at 04:15:34AM +0200, Marko Tiikkaja wrote:
The discussion around wCTE during the last week or so has brought to
my attention that we don't actually have a consensus on how
On Nov 11, 2010, at 9:13 AM, Tom Lane wrote:
If we establish a precedent that WITHs can be thought of as executing
before the main command, we will eventually have to de-optimize existing
WITH behavior. Or else make up reasons why the inconsistency is okay in
some cases and not others, but
Dave Page wrote:
On Thu, Nov 11, 2010 at 4:51 PM, Andrew Dunstan and...@dunslane.net wrote:
Interesting. Doesn't EDB's PostgresPlus package include PostGIS, and isn't
its Windows version build with MSVC?
Yes - it's a PITA as we have to have a dummy build of the server in
mingw/msys to
On Nov 11, 2010, at 7:02 AM, Itagaki Takahiro wrote:
MULTISET supports are more difficult. We have corresponding
type IDs for each array, but we might not want to add additional
IDs for multiset for each type. Any ideas for the issue?
Why not?
If we reuse type IDs of arrays for multisets,
David E. Wheeler da...@kineticode.com writes:
I can see that, but if one can't see the result of the write, or can't
determine whether or not it will be visible in advance, what's the point of
writeable CTEs?
The writeable CTE returns a RETURNING set, which you can and should use
in the
Thom Brown t...@linux.com writes:
WITH t AS (UPDATE foo SET col = true)
SELECT * FROM foo WHERE col = false;
... Wouldn't this be more practical to have foo's UPDATEs applied prior to
SELECT? Otherwise what would the usecase be?
If that's what you want, you might as well just issue two
On 11 Nov 2010, at 19:13, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2010-11-11 6:41 PM +0200, David Fetter wrote:
On Thu, Nov 11, 2010 at 04:15:34AM +0200, Marko Tiikkaja wrote:
The discussion around wCTE during the last week or so has brought
On Thu, Nov 11, 2010 at 12:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
then the conclusion is foregone. To my mind, they should be thought of
as running in parallel, or at least in an indeterminate order, just
exactly the same way that different data modifications made in a single
On Nov 11, 2010, at 9:29 AM, Tom Lane wrote:
I can see that, but if one can't see the result of the write, or can't
determine whether or not it will be visible in advance, what's the point of
writeable CTEs?
The writeable CTE returns a RETURNING set, which you can and should use
in the
David E. Wheeler da...@kineticode.com writes:
So are you planning to implement multisets? It's a feature I'd love to see
What actual functionality does it buy? AFAICT from Itagaki-san's
description, it's an array only you ignore the specific element order.
So what? You can write functions that
On Nov 11, 2010, at 10:05 AM, Tom Lane wrote:
So are you planning to implement multisets? It's a feature I'd love to see
What actual functionality does it buy? AFAICT from Itagaki-san's
description, it's an array only you ignore the specific element order.
So what? You can write functions
David E. Wheeler da...@kineticode.com writes:
On Nov 11, 2010, at 9:29 AM, Tom Lane wrote:
The writeable CTE returns a RETURNING set, which you can and should use
in the outer query. The thing that is being argued about here is what
you see if you look directly at the target table rather than
On 11.11.2010 17:16, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
GiST is different. When you insert a key to a leaf page, you (sometimes)
need to adjust the parent pointer to reflect the new key as well. B-tree
tolerates incomplete splits with the 'next page'
I think that it would be best to implement MULTISET in the same way that a TABLE
is implemented. Logically and structurally they are the same thing, but that a
MULTISET typically is used as a field value of a table row. Aka, a table and a
multiset are just different names for a relation,
2010/11/11 David E. Wheeler da...@kineticode.com:
On Nov 11, 2010, at 10:05 AM, Tom Lane wrote:
So are you planning to implement multisets? It's a feature I'd love to see
What actual functionality does it buy? AFAICT from Itagaki-san's
description, it's an array only you ignore the
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Hmm, we don't currently keep track of that when we descend the tree to
choose the target page, but perhaps an extra Consistent call to check
that would be acceptable. We already call Penalty for every tuple on
each internal node
On Nov 11, 2010, at 10:19 AM, Darren Duncan wrote:
I think that it would be best to implement MULTISET in the same way that a
TABLE is implemented. Logically and structurally they are the same thing, but
that a MULTISET typically is used as a field value of a table row. Aka, a
table and a
On Nov 11, 2010, at 10:24 AM, Nicolas Barbier wrote:
Also, no dupes.
The multi in multiset indicates that duplicate elements are
explicitly allowed and tracked.
D'oh! Right.
D
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Thu, Nov 11, 2010 at 12:36:38PM -0500, Merlin Moncure wrote:
On Thu, Nov 11, 2010 at 12:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
then the conclusion is foregone. To my mind, they should be thought of
as running in parallel, or at least in an indeterminate order, just
exactly the same
On Thu, Nov 11, 2010 at 12:34:55PM -0500, Tom Lane wrote:
Thom Brown t...@linux.com writes:
WITH t AS (UPDATE foo SET col = true)
SELECT * FROM foo WHERE col = false;
... Wouldn't this be more practical to have foo's UPDATEs applied
prior to SELECT? Otherwise what would the usecase be?
David Fetter da...@fetter.org writes:
On Thu, Nov 11, 2010 at 12:36:38PM -0500, Merlin Moncure wrote:
On Thu, Nov 11, 2010 at 12:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
then the conclusion is foregone. To my mind, they should be thought of
as running in parallel, or at least in an
On Thu, Nov 11, 2010 at 1:53 PM, David Fetter da...@fetter.org wrote:
On Thu, Nov 11, 2010 at 12:36:38PM -0500, Merlin Moncure wrote:
On Thu, Nov 11, 2010 at 12:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
then the conclusion is foregone. To my mind, they should be thought of
as running in
David Fetter da...@fetter.org writes:
On Thu, Nov 11, 2010 at 12:34:55PM -0500, Tom Lane wrote:
If that's what you want, you might as well just issue two separate
statements. There is no use-case for this at all unless the WITH
produces some RETURNING data that the SELECT makes use of.
Excerpts from David E. Wheeler's message of jue nov 11 15:45:55 -0300 2010:
On Nov 11, 2010, at 10:19 AM, Darren Duncan wrote:
I think that it would be best to implement MULTISET in the same way that a
TABLE is implemented. Logically and structurally they are the same thing,
but that a
On Thu, Nov 11, 2010 at 6:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Marti Raudsepp ma...@juffo.org writes:
On Thu, Nov 11, 2010 at 17:24, Tom Lane t...@sss.pgh.pa.us wrote:
Given that we have, in fact, never renamed any files in the history of
the project, I'm wondering exactly why it thinks
On Thu, Nov 11, 2010 at 5:19 PM, Mark Cave-Ayland
mark.cave-ayl...@siriusit.co.uk wrote:
Dave Page wrote:
On Thu, Nov 11, 2010 at 4:51 PM, Andrew Dunstan and...@dunslane.net
wrote:
Interesting. Doesn't EDB's PostgresPlus package include PostGIS, and
isn't
its Windows version build with
On Nov 11, 2010, at 12:08 PM, Alvaro Herrera wrote:
That sounds like a composite type to me.
No, it's perpendicular in the sense that while a composite type allows
you to have different columns, this multiset thing lets you have rows
(I initially thought about them as sets of scalars, but
On Thu, Nov 11, 2010 at 3:42 PM, David E. Wheeler da...@kineticode.com wrote:
On Nov 11, 2010, at 12:08 PM, Alvaro Herrera wrote:
That sounds like a composite type to me.
No, it's perpendicular in the sense that while a composite type allows
you to have different columns, this multiset thing
Merlin Moncure wrote:
On Thu, Nov 11, 2010 at 3:42 PM, David E. Wheeler da...@kineticode.com wrote:
On Nov 11, 2010, at 12:08 PM, Alvaro Herrera wrote:
That sounds like a composite type to me.
No, it's perpendicular in the sense that while a composite type allows
you to have different
On 11/11/2010 03:19 PM, Dave Page wrote:
My hope is that one day CMake will enable us to come up with a universal
solution, but we're some way from that yet.
We used CMake for a couple of projects, but ended up abandoning it for
new stuff. It just didn't work as nicely as we wanted.
Yes,
I've been thinking about supporting automatic replan of cached plans
using specific parameter values, as has been discussed several times,
at greatest length in this thread:
http://archives.postgresql.org/pgsql-hackers/2010-02/msg00607.php
There doesn't seem to be full consensus about what the
Hi,
I' wondering if following delimited identifier brhavior is correct or
not:
test=# create table t1(i int);
create table t1(i int);
CREATE TABLE
test=# create table t1_foo(i int, j int);
create table t1_foo(i int, j int);
CREATE TABLE
test=# select * from t1;
select * from t1;
i
---
(0 rows)
Tatsuo Ishii is...@postgresql.org wrote:
It seems PostgreSQL thinks t1_foo is equivalent to t1.
It thinks you've given t1 an alias of _foo in that query, same
as if you'd had a space between t1 and _foo.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Tatsuo Ishii wrote:
test=# select * from t1_foo;
select * from t1_foo;
i
---
(0 rows)
It seems PostgreSQL thinks t1_foo is equivalent to t1. Is this an
expected behavior?
That code looks badly written in any event. Delimiters should be put around
each part of an identifier or chain as a
On 11/11/2010 06:03 PM, Tatsuo Ishii wrote:
Hi,
I' wondering if following delimited identifier brhavior is correct or
not:
test=# create table t1(i int);
create table t1(i int);
CREATE TABLE
test=# create table t1_foo(i int, j int);
create table t1_foo(i int, j int);
CREATE TABLE
test=#
On Fri, Nov 12, 2010 at 03:05, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
So are you planning to implement multisets? It's a feature I'd love to see
What actual functionality does it buy? AFAICT from Itagaki-san's
description, it's an array only you
It seems PostgreSQL thinks t1_foo is equivalent to t1.
It thinks you've given t1 an alias of _foo in that query, same
as if you'd had a space between t1 and _foo.
Oh, ok. I thought we always need at least one space character between
the table name and the alias.
--
Tatsuo Ishii
SRA OSS,
On Fri, Nov 12, 2010 at 06:06, Darren Duncan dar...@darrenduncan.net wrote:
This is one place that SQL made things more complicated than they needed to
be. Multisets have generally the same structure *and* operators (union,
etc) as tables, but they use different syntax for each. A better
Peter Eisentraut wrote:
On tor, 2010-10-14 at 07:30 +0200, Magnus Hagander wrote:
And I agree it's not very friendly in this specific case - I
wonder if we should log it as localhost (127.0.0.1) and localhost
(::1) (and similar for any other case that returns more than one
address).
Magnus Hagander wrote:
On Fri, Sep 17, 2010 at 05:51, Ashesh Vashi
ashesh.va...@enterprisedb.com wrote:
Hi Mark,
On of my college (Sujeet) has found a way to reproduce the same behaviour.
1. Installed PG 9.0 on Win XP SP3
2. Stop the Postgresql-9.0 service from service manager console
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On tor, 2010-10-21 at 16:59 -0400, Tom Lane wrote:
Actually, the only reason this is even up for discussion is that
there's
no configure option to set DEFAULT_PGSOCKET_DIR. If there were, and
debian were using it, then pg_config
Robert Haas wrote:
On Thu, Oct 28, 2010 at 1:13 AM, Josh Berkus j...@agliodbs.com wrote:
I sort of agree with you that the current checkpoint_segments
parameter is a bit hard to tune, at least if your goal is to control
the amount of disk space that will be used by WAL files. ?But I'm not
Robert Haas wrote:
On Wed, Oct 27, 2010 at 3:53 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2010-10-26 at 22:03 -0400, Robert Haas wrote:
On Tue, Oct 26, 2010 at 9:59 PM, Josh Berkus j...@agliodbs.com wrote:
If you set wal_keep_segments=0, archive_mode=on, and
On Thu, Nov 11, 2010 at 10:13 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Thu, Oct 28, 2010 at 1:13 AM, Josh Berkus j...@agliodbs.com wrote:
I sort of agree with you that the current checkpoint_segments
parameter is a bit hard to tune, at least if your goal is to
On Thu, Nov 11, 2010 at 10:02 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
If we reuse type IDs of arrays for multisets, the multisets would
have some special typmod. For example, typmod = 0 means multiset,
and positive value means array with max cardinality. Note that
the SQL
Bruce Momjian br...@momjian.us writes:
I have developed the attached patch to report whether IPv4 or IPv6 are
being used.
What's the use of that exactly? It doesn't really respond to Peter's
concern, I think.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Robert Haas robertmh...@gmail.com writes:
On Thu, Nov 11, 2010 at 10:02 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
If we reuse type IDs of arrays for multisets, the multisets would
have some special typmod. For example, typmod = 0 means multiset,
and positive value means array
On Fri, Nov 12, 2010 at 12:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Nov 11, 2010 at 10:02 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
If we reuse type IDs of arrays for multisets, the multisets would
have some special typmod. For
On Fri, Nov 12, 2010 at 03:49, Bruce Momjian br...@momjian.us wrote:
Magnus Hagander wrote:
On Fri, Sep 17, 2010 at 05:51, Ashesh Vashi
ashesh.va...@enterprisedb.com wrote:
Hi Mark,
On of my college (Sujeet) has found a way to reproduce the same behaviour.
1. Installed PG 9.0 on Win XP
74 matches
Mail list logo
