Scott Bailey arta...@comcast.net wrote:
CREATE TYPE periodtz AS RANGE (timestamptz, '1 microsecond'::interval);
What does the second argument mean? Is it a default interval?
So basically I have a pg_range table to store the base typeid, a text
field for the granule value and the granule
On sön, 2009-12-13 at 19:20 +, Simon Riggs wrote:
Barring resolving a few points and subject to even more testing, this
is the version I expect to commit to CVS on Wednesday.
To clarify: Did you pick Wednesday so that it gets included before the
end of the commit fest (and thus into alpha3)
pg_ctl initdb crashes if no options are passed.
Do we need additional if-null test for pgdata_opt just like post_opts?
$ pg_ctl initdb
sh: -c: line 0: syntax error near unexpected token `null'
sh: -c: line 0: `/usr/local/pgsql/bin/initdb (null)'
pg_ctl: database system
On Sun, Dec 13, 2009 at 11:29 AM, Magnus Hagander mag...@hagander.net wrote:
On Sun, Dec 13, 2009 at 11:36, Dave Page dp...@pgadmin.org wrote:
On Sun, Dec 13, 2009 at 5:42 AM, Andrew Dunstan and...@dunslane.net wrote:
Yes. I spent a few cents and a few hours wrestling with it. AFAICT your are
On Mon, 2009-12-14 at 10:11 +0200, Peter Eisentraut wrote:
On sön, 2009-12-13 at 19:20 +, Simon Riggs wrote:
Barring resolving a few points and subject to even more testing, this
is the version I expect to commit to CVS on Wednesday.
To clarify: Did you pick Wednesday so that it gets
One more issue I found.
What row-level policy should be applied on inherited tables?
If inconsistent policy is applied on the parent and child table,
we can see different result set, although a part of result set
in the parent table come from the child table.
My idea is to copy row-level
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Dec 13, 2009 at 11:49:53PM -0800, Scott Bailey wrote:
I had proposed a temporal contrib module earlier and you wanted to see
support for many range types not just timestamptz [...]
So basically I have an anyrange pseudo type with the
Hi,
Jaime Casanova írta:
On Mon, Nov 16, 2009 at 5:59 AM, Boszormenyi Zoltan z...@cybertec.at wrote:
New version: rebased to current CVS.
This one no longer applies to HEAD, could you update it please?
Will post a new version soon, Michael asked to turn it
into an ECPG native
On mån, 2009-12-14 at 08:54 +, Simon Riggs wrote:
Wednesday because that seemed a good delay to allow review. Josh and I
had discussed the value of getting patch into Alpha3, so that was my
wish and aim.
I'm not aware of any particular date for end of commitfest, though
possibly you are
Simon Riggs wrote:
Enclose latest version of Hot Standby. This is the basic patch, with
no must-fix issues and no known bugs. Further additions will follow
after commit, primarily around usability, which will include additional
control functions for use in testing. Various thoughts discussed
On Mon, Dec 14, 2009 at 10:54, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
* Please remove any spurious whitespace. git diff --color makes them
stand out like a sore thumb, in red. (pgindent will fix them but always
better to fix them before committing, IMO).
+1 in general,
On Mon, Dec 14, 2009 at 4:06 AM, to...@tuxteam.de wrote:
As another approach, what about storing typeid in typmod?
(Oid can be assumed to be stored in int32.)
For example,
CREATE TABLE tbl ( r range(timestamp) );
SELECT '[ 2.0, 3.0 )'::range(float);
There might be some overhead to
On Mon, 2009-12-14 at 04:57 +, Greg Stark wrote:
On Sat, Dec 12, 2009 at 3:06 PM, Simon Riggs si...@2ndquadrant.com wrote:
Anyone acquiring a lock on a table should check the latestRemovedXid for
the table and abort if their xmin is too old. This prevents new lockers
from accessing a
Thanks for the further review, much appreciated.
On Mon, 2009-12-14 at 11:54 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Enclose latest version of Hot Standby. This is the basic patch, with
no must-fix issues and no known bugs. Further additions will follow
after commit, primarily
On Mon, 2009-12-14 at 11:09 +0100, Magnus Hagander wrote:
On Mon, Dec 14, 2009 at 10:54, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
* Please remove any spurious whitespace. git diff --color makes them
stand out like a sore thumb, in red. (pgindent will fix them but always
On Mon, Dec 14, 2009 at 8:07 PM, Simon Riggs si...@2ndquadrant.com wrote:
* Please remove any spurious whitespace. git diff --color makes them
stand out like a sore thumb, in red. (pgindent will fix them but always
better to fix them before committing, IMO).
What is your definition of
2009/12/14 KaiGai Kohei kai...@ak.jp.nec.com:
Robert Haas wrote:
One point. MAC is mandatory, so the table owner should not be able to
control whether row-level checks are applied, or not.
So, I used a special purpose system column to represent security label.
It is generated for each tables,
On Mon, Dec 14, 2009 at 6:11 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2009-12-14 at 11:09 +0100, Magnus Hagander wrote:
On Mon, Dec 14, 2009 at 10:54, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
* Please remove any spurious whitespace. git diff --color makes
On Mon, 2009-12-14 at 06:21 -0500, Robert Haas wrote:
On Mon, Dec 14, 2009 at 6:11 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2009-12-14 at 11:09 +0100, Magnus Hagander wrote:
On Mon, Dec 14, 2009 at 10:54, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
* Please
2009/12/14 KaiGai Kohei kai...@ak.jp.nec.com:
Robert Haas wrote:
2009/12/13 KaiGai Kohei kai...@ak.jp.nec.com:
Just to name a few really obvious problems (I only looked at the
01-database patch):
1. We have been talking for several days about the need to make the
initial patch in this area
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Dec 14, 2009 at 06:02:04AM -0500, Robert Haas wrote:
On Mon, Dec 14, 2009 at 4:06 AM, to...@tuxteam.de wrote:
[...]
This looks more natural to me too.
It 's very different than the way we've traditionally used typmod,
though, which
On Mon, Dec 14, 2009 at 6:35 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2009-12-14 at 06:21 -0500, Robert Haas wrote:
On Mon, Dec 14, 2009 at 6:11 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2009-12-14 at 11:09 +0100, Magnus Hagander wrote:
On Mon, Dec 14, 2009 at 10:54,
(2009/12/14 20:18), Robert Haas wrote:
* Foreign Key constraint(2)
FK is implemented as a trigger which internally uses SELECT/UPDATE/DELETE.
If associated tuples are filtered out, it breaks reference integrity.
So, we have to apply special care. In SE-PgSQL case, it raises an error
instead of
On Mon, Dec 14, 2009 at 12:51, Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 14, 2009 at 6:35 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2009-12-14 at 06:21 -0500, Robert Haas wrote:
On Mon, Dec 14, 2009 at 6:11 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2009-12-14
Dave Page wrote:
The other possible option that I hesitate to suggest is Windows
Services for Unix or SUA as I think it's now called.
You mean we should post flex to that? Or have you found someone who has already?
No idea if someone has done it already. I'm just throwing it
On Mon, Dec 14, 2009 at 12:10 PM, Andrew Dunstan and...@dunslane.net wrote:
Dave Page wrote:
The other possible option that I hesitate to suggest is Windows
Services for Unix or SUA as I think it's now called.
You mean we should post flex to that? Or have you found someone who has
--On 10. Dezember 2009 16:49:50 +0100 Zdenek Kotala zdenek.kot...@sun.com
wrote:
You need to determine which SLRU is used. Because SLRUs are initialized
during startup pointer should be same in all backends. If I think more
about it. Maybe it could be goot to add probe also into
On Mon, 2009-12-14 at 11:07 +, Simon Riggs wrote:
Thanks for the further review, much appreciated.
On Mon, 2009-12-14 at 11:54 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Enclose latest version of Hot Standby.
* LockAcquireExtended needs a function comment. Or at least
(2009/12/14 20:48), Robert Haas wrote:
2009/12/14 KaiGai Koheikai...@ak.jp.nec.com:
Robert Haas wrote:
2009/12/13 KaiGai Koheikai...@ak.jp.nec.com:
Just to name a few really obvious problems (I only looked at the
01-database patch):
1. We have been talking for several days about the need to
On Mon, Dec 14, 2009 at 7:22 AM, Simon Riggs si...@2ndquadrant.com wrote:
I am now unable to push these changes to the shared repo. What is
happening?
Perhaps you need to run cvs update on your local copy?
(I find this flavor the most useful: cvs -q update -d YMMV.)
If that's not it, error
On Mon, Dec 14, 2009 at 7:30 AM, KaiGai Kohei kai...@kaigai.gr.jp wrote:
(2009/12/14 20:48), Robert Haas wrote:
2009/12/14 KaiGai Koheikai...@ak.jp.nec.com:
Robert Haas wrote:
2009/12/13 KaiGai Koheikai...@ak.jp.nec.com:
Just to name a few really obvious problems (I only looked at the
On Mon, 2009-12-14 at 06:51 -0500, Robert Haas wrote:
On Mon, Dec 14, 2009 at 6:35 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2009-12-14 at 06:21 -0500, Robert Haas wrote:
On Mon, Dec 14, 2009 at 6:11 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2009-12-14 at 11:09 +0100,
On Mon, Dec 14, 2009 at 7:19 AM, Bernd Helmle maili...@oopsware.de wrote:
--On 10. Dezember 2009 16:49:50 +0100 Zdenek Kotala zdenek.kot...@sun.com
wrote:
You need to determine which SLRU is used. Because SLRUs are initialized
during startup pointer should be same in all backends. If I think
(2009/12/14 21:34), Robert Haas wrote:
On Mon, Dec 14, 2009 at 7:30 AM, KaiGai Koheikai...@kaigai.gr.jp wrote:
(2009/12/14 20:48), Robert Haas wrote:
2009/12/14 KaiGai Koheikai...@ak.jp.nec.com:
Robert Haas wrote:
2009/12/13 KaiGai Koheikai...@ak.jp.nec.com:
Just to name a few really
On Mon, 2009-12-14 at 07:33 -0500, Robert Haas wrote:
On Mon, Dec 14, 2009 at 7:22 AM, Simon Riggs si...@2ndquadrant.com wrote:
I am now unable to push these changes to the shared repo. What is
happening?
Perhaps you need to run cvs update on your local copy?
(I find this flavor the
On Mon, Dec 14, 2009 at 13:47, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2009-12-14 at 07:33 -0500, Robert Haas wrote:
On Mon, Dec 14, 2009 at 7:22 AM, Simon Riggs si...@2ndquadrant.com wrote:
I am now unable to push these changes to the shared repo. What is
happening?
Perhaps you
Scott Bailey arta...@comcast.net writes:
So basically I have an anyrange pseudo type with the functions prev, next,
last, etc defined. So instead of hard coding range types, we would allow the
user to define their own range types. Basically if we are able to determine
the previous and next
On Sun, Dec 13, 2009 at 11:49:53PM -0800, Scott Bailey wrote:
So basically I have an anyrange pseudo type with the functions prev,
next, last, etc defined. So instead of hard coding range types, we would
allow the user to define their own range types. Basically if we are able
to
On Sat, Dec 12, 2009 at 5:09 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Could we change the API of PQgetXLogData to be more like PQgetCopyData?
I'm thinking of removing the timeout argument, and instead looping with
select/poll and PQconsumeInput in the caller. That
Stephen Frost wrote:
* Bruce Momjian (br...@momjian.us) wrote:
I am not replying to many of these emails so I don't appear to be
brow-beating (forcing) the community into accepting this features. I
might be brow-beating the community, but I don't want to _appear_ to be
brow-beating. ;-)
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
The reason why I put on the security hook in ExecScan() is to avoid the
problem that row-cost user defined function can be evaluated earlier
than row-level security policy. (I believed it was a well-known problem
at that time yet.) So, I
Sorry if if's a double post, but I thought that it would be more likely I
would get an answer on the hackers list.
Thanks
Fred
-- --
From: Fred Janon fja...@gmail.com
Date: Mon, Dec 14, 2009 at 19:04
Subject: pgAdmin III: timestamp displayed in what time zone?
To:
On mån, 2009-12-14 at 17:25 +0900, Takahiro Itagaki wrote:
pg_ctl initdb crashes if no options are passed.
Do we need additional if-null test for pgdata_opt just like post_opts?
$ pg_ctl initdb
sh: -c: line 0: syntax error near unexpected token `null'
sh: -c: line 0:
On Mon, Dec 14, 2009 at 7:42 AM, Simon Riggs si...@2ndquadrant.com wrote:
There are no changes in this patch that are purely whitespace changes.
Those were removed prior to patch submission. This is all about code I
am adding or changing. My additions may disrupt their patches, but not
because
Fujii Masao masao.fu...@gmail.com writes:
On Mon, Dec 14, 2009 at 11:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Do we need a new PQgetXLogData function at all? Seems like you could
shove the data through the COPY protocol and not have to touch libpq
at all, rather than duplicating a nontrivial
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Pushing extra arguments around would create overhead of its own ...
overhead that would be paid even when not using EXPLAIN at all.
I cannot understand what you mean... The additional argument should
Greg Stark gsst...@mit.edu writes:
On Fri, Dec 11, 2009 at 6:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'll commit a fix for that shortly, but this reminds me once again that
the EvalPlanQual logic is desperately under-tested in our normal
regression testing. We really need some kind of
Greg Stark gsst...@mit.edu writes:
What happens on the slave when normal NOTIFYs are generated on the
master? IIRC NOTIFYs are wal-logged so I imagine LISTEN on the slave
would just work and a plain old NOTIFY/LISTEN would suffice for this
use case?
Nothing happens: NOTIFYs are *not*
Tom Lane wrote:
But my recollection of the parallel psql patch discussion is that it was
rejected because nobody felt comfortable with the API design. Do we
have any better ideas in that department yet?
It wasn't rejected AFAICT. A finalized API with which there was
(almost?) no dissent was
Scott Bailey arta...@comcast.net writes:
So basically I have an anyrange pseudo type with the functions prev,
next, last, etc defined. So instead of hard coding range types, we would
allow the user to define their own range types. Basically if we are able
to determine the previous and next
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
As another approach, what about storing typeid in typmod?
(Oid can be assumed to be stored in int32.)
No, it cannot --- you'd be one bit short. The general rule for typmod
is that all negative values are treated as unspecified. Even if
KaiGai Kohei kai...@ak.jp.nec.com writes:
One more issue I found.
What row-level policy should be applied on inherited tables?
Yup, that seems like an interesting problem.
Even if the inherited table has multiple parents, all the row-level
policies shall be applied, so here is no
On Mon, 2009-12-14 at 09:51 -0500, Tom Lane wrote:
This might be
an example of a case where we need that are we doing HS flag that
Simon insists we don't need.
Simon has put it there at your request, in the place you suggested.
Others did speak against it, not me.
--
Simon Riggs
On Mon, 2009-12-14 at 09:32 -0500, Robert Haas wrote:
If every patch perfectly matched the pgident style, then the pgindent
run would change nothing and we would all be VERY happy.
I've made all whitespace changes to the patch.
I understand the reason for acting as you suggest, but we either
Simon Riggs si...@2ndquadrant.com wrote:
If we are going to run pgindent anyway, what is the point?
Perhaps it would take less time to run this than to argue the point?:
sed -e 's/[ \t][ \t]*$//' -e 's/ *\t/\t/g' *
-Kevin
--
Sent via pgsql-hackers mailing list
On Mon, 2009-12-14 at 13:56 +0100, Magnus Hagander wrote:
Same issue can be it in git - did you do a git pull before? You may
need merging with what's on there, and for that to work you must pull
before you can push.
Found some merge conflicts and resolved them. I did fetch and merge at
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 14, 2009 at 4:06 AM, to...@tuxteam.de wrote:
As another approach, what about storing typeid in typmod?
(Oid can be assumed to be stored in int32.)
It 's very different than the way we've traditionally used typmod,
Aside from the problems
On Mon, 2009-12-14 at 09:51 -0500, Tom Lane wrote:
Greg Stark gsst...@mit.edu writes:
What happens on the slave when normal NOTIFYs are generated on the
master? IIRC NOTIFYs are wal-logged so I imagine LISTEN on the slave
would just work and a plain old NOTIFY/LISTEN would suffice for this
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 14, 2009 at 6:35 AM, Simon Riggs si...@2ndquadrant.com wrote:
Why is (1) important, and if it is important, why is it being mentioned
only now? Are we saying that all previous reviewers of my work (and
others') removed these without ever
On Mon, Dec 14, 2009 at 10:08 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2009-12-14 at 09:32 -0500, Robert Haas wrote:
If every patch perfectly matched the pgident style, then the pgindent
run would change nothing and we would all be VERY happy.
I've made all whitespace changes to
Tom Lane escribió:
The whole thing would be a lot easier if someone would put together an
easily-installable version of pgindent. Bruce has posted the patches he
uses but I don't know what version of indent they're against...
And we're still unclear on the typedef list that's going to be
Simon Riggs wrote:
On Mon, 2009-12-14 at 11:09 +0100, Magnus Hagander wrote:
On Mon, Dec 14, 2009 at 10:54, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
* Please remove any spurious whitespace. git diff --color makes them
stand out like a sore thumb, in red. (pgindent will
Greg Smith g...@2ndquadrant.com wrote:
I didn't really get any feedback on my proposal to add a new
Discussing review state
It seems like a good idea to me; it better models the reality.
http://wiki.postgresql.org/wiki/Running_a_CommitFest
It seems to me that a patch could move from
On Mon, 2009-12-14 at 09:14 -0600, Kevin Grittner wrote:
Simon Riggs si...@2ndquadrant.com wrote:
If we are going to run pgindent anyway, what is the point?
Perhaps it would take less time to run this than to argue the point?:
sed -e 's/[ \t][ \t]*$//' -e 's/ *\t/\t/g' *
Not
On Mon, Dec 14, 2009 at 11:09:49AM +0100, Magnus Hagander wrote:
On Mon, Dec 14, 2009 at 10:54, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
* Please remove any spurious whitespace. git diff --color makes
them stand out like a sore thumb, in red. (pgindent will fix them
On Mon, Dec 14, 2009 at 10:49 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2009-12-14 at 09:14 -0600, Kevin Grittner wrote:
Simon Riggs si...@2ndquadrant.com wrote:
If we are going to run pgindent anyway, what is the point?
Perhaps it would take less time to run this than to argue
Fujii Masao masao.fu...@gmail.com writes:
I'm going to set the new function calling ereport as the current notice
processor by using PQsetNoticeProcessor. But the problem is that only the
completed message like NOTICE: xxx is passed to such notice processor,
i.e., the error level itself is not
Simon Riggs si...@2ndquadrant.com writes:
I definitely wouldn't presume that anybody using Hot Standby would
necessarily want NOTIFY to reach the standby, especially if there was an
overhead to doing so. If using NOTIFY is the favoured approach, I would
add a separate parameter for it and/or
Martijn van Oosterhout wrote:
On Sun, Dec 13, 2009 at 11:49:53PM -0800, Scott Bailey wrote:
So basically I have an anyrange pseudo type with the functions prev,
next, last, etc defined. So instead of hard coding range types, we would
allow the user to define their own range types. Basically
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 14, 2009 at 6:35 AM, Simon Riggs si...@2ndquadrant.com wrote:
Why is (1) important, and if it is important, why is it being mentioned
only now? Are we saying that all previous reviewers of my work (and
others') removed
Scott Bailey arta...@comcast.net writes:
Because intervals (mathematical not SQL) can be open or closed at each
end point we need to know what the next an previous value would be at
the specified granularity. And while you can do some operations without
knowing this, there are many you
Fred Janon wrote:
Sorry if if's a double post, but I thought that it would be more
likely I would get an answer on the hackers list.
In that case just posting here would have been better than hitting
both. I usually ignore any request for help that is posted on more than
one list just to draw
Kevin Grittner wrote:
http://wiki.postgresql.org/wiki/Running_a_CommitFest
It seems to me that a patch could move from Discussing review to
Needs review -- if the reviewer decided to discuss the approach
before continuing the review process and the discussion confirms the
approach as
Heikki Linnakangas wrote:
I note that if it was easy to run pgindent yourself on a patch before
committing/submitting, we wouldn't need to have this discussion. I don't
know hard it is to get it working right, but I recall I tried once and
gave up.
What sort of problems did you run into?
--
On Mon, Dec 14, 2009 at 12:01 PM, Greg Smith g...@2ndquadrant.com wrote:
Kevin Grittner wrote:
http://wiki.postgresql.org/wiki/Running_a_CommitFest
It seems to me that a patch could move from Discussing review to
Needs review -- if the reviewer decided to discuss the approach
before
Robert Haas wrote:
I don't think there should be a transition from Returned with Feedback
back to Waiting for review. Granted we might allow that occasionally
as an exceptional case, but normally Returned with Feedback is a final
state.
I did throw some disclaimers in the notes about this
On Mon, Dec 14, 2009 at 12:38 PM, Greg Smith g...@2ndquadrant.com wrote:
Robert Haas wrote:
I don't think there should be a transition from Returned with Feedback
back to Waiting for review. Granted we might allow that occasionally
as an exceptional case, but normally Returned with Feedback
Because intervals (mathematical not SQL) can be open or closed at each
end point we need to know what the next an previous value would be at
the specified granularity. And while you can do some operations without
knowing this, there are many you can't. For instance you could not tell
whether
On Mon, Dec 14, 2009 at 11:07 AM, Simon Riggs si...@2ndquadrant.com wrote:
* vacuum_defer_cleanup_age is very hard to tune. You'll need an estimate
on your transaction rate to begin with. Do we really want this setting
in its current form? Does it make sense as PGC_USERSET, as if one
backend
Andrew Gierth and...@tao11.riddles.org.uk writes:
Updated version of the aggregate order by patch.
I'm starting to look at this now. I find it rather bizarre to merge
both the actual arguments of an aggregate and the optional ORDER BY
expressions into a single targetlist. It doesn't seem like
On Mon, 2009-12-14 at 11:25 -0500, Tom Lane wrote:
Scott Bailey arta...@comcast.net writes:
Because intervals (mathematical not SQL) can be open or closed at each
end point we need to know what the next an previous value would be at
the specified granularity. And while you can do some
Greg Smith wrote:
Heikki Linnakangas wrote:
I note that if it was easy to run pgindent yourself on a patch before
committing/submitting, we wouldn't need to have this discussion. I don't
know hard it is to get it working right, but I recall I tried once and
gave up.
What sort of problems
On Mon, 2009-12-14 at 09:58 -0500, Tom Lane wrote:
In particular, the granularity examples you give seem to assume that
the underlying datatype is exact not approximate --- which among other
things will mean that it fails to work for float timestamps. Since
timestamps are supposedly the main
Nathan Boley npbo...@gmail.com writes:
This statement seems to me to demonstrate that you don't actually
understand the concept of open and closed ranges.
IMHO the first question is whether, for integers, [1,2] UNION [3,5]
should be equal to [1,5]. In math this is certainly true, and defining
On Mon, 2009-12-14 at 10:00 -0800, Nathan Boley wrote:
IMHO the first question is whether, for integers, [1,2] UNION [3,5]
should be equal to [1,5]. In math this is certainly true, and defining
'next' seems like a reasonable way to establish this in postgres.
[ you say yes ]
Agreed.
The
Jeff Davis wrote:
So there are certainly some user-visible API differences between the
two, and I don't think those differences can be hidden.
ISTM you are saying we should have two types of range types.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The
Jeff Davis pg...@j-davis.com writes:
On Mon, 2009-12-14 at 11:25 -0500, Tom Lane wrote:
This statement seems to me to demonstrate that you don't actually
understand the concept of open and closed ranges.
Of course you can still define the obvious contains and overlaps
operators for a
Simon Riggs wrote:
On Mon, 2009-12-14 at 11:54 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
* Are you planning to remove the recovery_connections setting before
release? The documentation makes it sound like it's a temporary hack
that we're not really sure is needed at all. That's not
On Mon, 2009-12-14 at 18:02 +, Greg Stark wrote:
It doesn't seem any more wrong than using hash indexes right after
recovery, crash recovery or otherwise. It's certainly broken, but I
don't see much value in a partial fix. The bottom line is that hash
indexes should be WAL-logged.
On Sun, 2009-12-13 at 22:25 +, Simon Riggs wrote:
* Which exact tables are we talking about: just pg_class and the shared
catalogs? Everything else is in pg_class, so if we can find it we're OK?
formrdesc() tells me the list of nailed relations is: pg_database,
pg_class, pg_attribute,
I wrote:
On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote:
There was considerable debate earlier about whether we wanted to treat
Python 3 as a separate PL so it could be available in parallel with
plpython 2, because of the user-level coding incompatibilities. It
looks like this patch
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Updated version of the aggregate order by patch.
Tom I'm starting to look at this now. I find it rather bizarre to
Tom merge both the actual arguments of an aggregate and the optional
Tom ORDER BY expressions into a single targetlist. It doesn't
Tom Lane wrote:
The very, very large practical problem with this is that if you decide
to change the behavior at any time, the only way to be sure that the WAL
receiver is using the right libpq version is to perform a soname major
version bump. The transformations done by libpq will
On Mon, Dec 14, 2009 at 1:42 PM, Peter Eisentraut pete...@gmx.net wrote:
I wrote:
On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote:
There was considerable debate earlier about whether we wanted to treat
Python 3 as a separate PL so it could be available in parallel with
plpython 2,
Simon Riggs si...@2ndquadrant.com writes:
* Disallow clustering system relations. This will definitely NOT work
* for shared relations (we have no way to update pg_class rows in other
* databases), nor for nailed-in-cache relations (the relfilenode values
* for those are hardwired, see
I wrote:
On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote:
There was considerable debate earlier about whether we wanted to treat
Python 3 as a separate PL so it could be available in parallel with
plpython 2, because of the user-level coding incompatibilities. It
looks like this patch
Tom Lane wrote:
Scott Bailey arta...@comcast.net writes:
Because intervals (mathematical not SQL) can be open or closed at each
end point we need to know what the next an previous value would be at
the specified granularity. And while you can do some operations without
knowing this, there are
On Mon, 2009-12-14 at 20:32 +0200, Heikki Linnakangas wrote:
* You removed this comment from KnownAssignedXidsInit:
- /*
-* XXX: We should check that we don't exceed maxKnownAssignedXids.
-* Even though the hash table might hold a few more entries than that,
-* we use
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
It's going to be a bit more complicated in walsender/walreceiver to work
with the libpq COPY API. We're going to need a WAL sending/receiving
protocol on top of it, defined in terms of rows and columns passed
through the COPY
On Mon, 2009-12-14 at 13:48 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
* Disallow clustering system relations. This will definitely NOT work
* for shared relations (we have no way to update pg_class rows in other
* databases), nor for nailed-in-cache relations (the
1 - 100 of 151 matches
Mail list logo
