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: I'm
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: I'm
On Wed, Nov 10, 2010 at 6:13 PM, Andrew Dunstan 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 old
> make did. It
On 11/11/2010 06:58 AM, Dave Page wrote:
On Wed, Nov 10, 2010 at 6:13 PM, Andrew Dunstan 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 vir
Robert Haas 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 people who wouldn
Robert Haas 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 shared_preload_libr
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 ba
On Thu, Nov 11, 2010 at 1:04 PM, Andrew Dunstan 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 objects I install
Peter Eisentraut 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 what I
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 the
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 t
Heikki Linnakangas 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 applicable to gist. Teodor described the
On Thu, Nov 11, 2010 at 8:28 AM, Andrew Dunstan 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 bugs that
shoul
Aidan Van Dyk 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:
FWIW, I was s
On Thu, Nov 11, 2010 at 17:24, Tom Lane 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 why I am unhapp
Aidan Van Dyk 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 yesterday's line_
Marti Raudsepp writes:
> On Thu, Nov 11, 2010 at 17:24, Tom Lane 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.
> Because git doesn't do "rename t
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
> wrote:
> > Log Message:
> > ---
> > Don't unblock SIGQUIT in the SIGQUIT handler
> >
> > This was possibly linked to a deadlock-like situation in glibc syslog code
> > invoked by th
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 sho
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
Windows
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 be
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 abo
On 11 November 2010 16:50, Marko Tiikkaja wrote:
> 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 consen
On Thu, Nov 11, 2010 at 4:51 PM, Andrew Dunstan 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 Slony. We're probably
Marko Tiikkaja 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 exactly
>>> wCTEs sh
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, bu
Dave Page wrote:
On Thu, Nov 11, 2010 at 4:51 PM, Andrew Dunstan 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 Slony.
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" 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 outer query. The th
Thom Brown 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 separate
statem
On 11 Nov 2010, at 19:13, Tom Lane wrote:
Marko Tiikkaja 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
On Thu, Nov 11, 2010 at 12:13 PM, Tom Lane 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
> INSERT/UPDATE/DELETE command
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
>
"David E. Wheeler" 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 work that way now
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 func
"David E. Wheeler" 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 making
>>
On 11.11.2010 17:16, Tom Lane wrote:
Heikki Linnakangas 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 applicable
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, loose
2010/11/11 David E. Wheeler :
> 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
Heikki Linnakangas 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 the way, so compared to that
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 an
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 subscriptio
On Thu, Nov 11, 2010 at 12:36:38PM -0500, Merlin Moncure wrote:
> On Thu, Nov 11, 2010 at 12:13 PM, Tom Lane 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 diff
On Thu, Nov 11, 2010 at 12:34:55PM -0500, Tom Lane wrote:
> Thom Brown 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 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 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
On Thu, Nov 11, 2010 at 1:53 PM, David Fetter 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 wrote:
>> > then the conclusion is foregone. To my mind, they should be thought of
>> > as running in parallel, or at least in an i
David Fetter 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.
> There are lot
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
On Thu, Nov 11, 2010 at 6:08 PM, Tom Lane wrote:
> Marti Raudsepp writes:
>> On Thu, Nov 11, 2010 at 17:24, Tom Lane 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
On Thu, Nov 11, 2010 at 5:19 PM, Mark Cave-Ayland
wrote:
> Dave Page wrote:
>
>> On Thu, Nov 11, 2010 at 4:51 PM, Andrew Dunstan
>> 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
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 scala
On Thu, Nov 11, 2010 at 3:42 PM, David E. Wheeler 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 lets yo
Merlin Moncure wrote:
On Thu, Nov 11, 2010 at 3:42 PM, David E. Wheeler 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 th
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 cont
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 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 changes to y
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
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=# selec
On Fri, Nov 12, 2010 at 03:05, Tom Lane wrote:
> "David E. Wheeler" 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.
>> 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
On Fri, Nov 12, 2010 at 06:06, Darren Duncan 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 design
> would be to make
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
> > addr
Magnus Hagander wrote:
> On Fri, Sep 17, 2010 at 05:51, Ashesh Vashi
> 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
> > 3. Create pgpa
Tom Lane wrote:
> Peter Eisentraut 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 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 wrote:
> > On Tue, 2010-10-26 at 22:03 -0400, Robert Haas wrote:
> >> On Tue, Oct 26, 2010 at 9:59 PM, Josh Berkus wrote:
> >> >
> >> >> If you set wal_keep_segments=0, archive_mode=on, and
> >> >> archive_command=, you might run o
On Thu, Nov 11, 2010 at 10:13 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Thu, Oct 28, 2010 at 1:13 AM, Josh Berkus 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 o
On Thu, Nov 11, 2010 at 10:02 AM, Itagaki Takahiro
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 standard doesn't mention abou
Bruce Momjian 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 (pgsql-hackers@p
Robert Haas writes:
> On Thu, Nov 11, 2010 at 10:02 AM, Itagaki Takahiro
> 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
On Fri, Nov 12, 2010 at 12:21 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Nov 11, 2010 at 10:02 AM, Itagaki Takahiro
>> 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 val
On Fri, Nov 12, 2010 at 03:49, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> On Fri, Sep 17, 2010 at 05:51, Ashesh Vashi
>> 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 Postgres
74 matches
Mail list logo
