Scott Bailey 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 typeid.
As another
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 initializa
On Sun, Dec 13, 2009 at 11:29 AM, Magnus Hagander wrote:
> On Sun, Dec 13, 2009 at 11:36, Dave Page wrote:
>> On Sun, Dec 13, 2009 at 5:42 AM, Andrew Dunstan wrote:
>>>
>>> Yes. I spent a few cents and a few hours wrestling with it. AFAICT your are
>>> hosed on 64bit Windows. I can't get flex bu
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
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 policie
-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 fu
Hi,
Jaime Casanova írta:
> On Mon, Nov 16, 2009 at 5:59 AM, Boszormenyi Zoltan 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 featur
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 yo
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 discus
On Mon, Dec 14, 2009 at 10:54, Heikki Linnakangas
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, not particularly for this patch
On Mon, Dec 14, 2009 at 4:06 AM, 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 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 cleaned relation
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, pr
On Mon, 2009-12-14 at 11:09 +0100, Magnus Hagander wrote:
> On Mon, Dec 14, 2009 at 10:54, Heikki Linnakangas
> 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 befo
On Mon, Dec 14, 2009 at 8:07 PM, Simon Riggs 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 spurious whitespac
2009/12/14 KaiGai Kohei :
> 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 table
On Mon, Dec 14, 2009 at 6:11 AM, 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
>> wrote:
>> > * Please remove any spurious whitespace. "git diff --color" makes them
>> > stand out like a sore thumb, in red. (pg
On Mon, 2009-12-14 at 06:21 -0500, Robert Haas wrote:
> On Mon, Dec 14, 2009 at 6:11 AM, 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
> >> wrote:
> >> > * Please remove any spurious whitespace. "git diff -
2009/12/14 KaiGai Kohei :
> Robert Haas wrote:
>> 2009/12/13 KaiGai Kohei :
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 strictly a code cl
-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, wrote:
[...]
> > This looks more natural to me too.
>
> It 's very different than the way we've traditionally used typmod,
> though, which Tom describe
On Mon, Dec 14, 2009 at 6:35 AM, Simon Riggs wrote:
> On Mon, 2009-12-14 at 06:21 -0500, Robert Haas wrote:
>> On Mon, Dec 14, 2009 at 6:11 AM, 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
>> >> wrote:
>
(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 f
On Mon, Dec 14, 2009 at 12:51, Robert Haas wrote:
> On Mon, Dec 14, 2009 at 6:35 AM, Simon Riggs wrote:
>> On Mon, 2009-12-14 at 06:21 -0500, Robert Haas wrote:
>>> On Mon, Dec 14, 2009 at 6:11 AM, Simon Riggs wrote:
>>> > On Mon, 2009-12-14 at 11:09 +0100, Magnus Hagander wrote:
>>> >> On Mon,
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 ou
On Mon, Dec 14, 2009 at 12:10 PM, Andrew Dunstan 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 ha
--On 10. Dezember 2009 16:49:50 +0100 Zdenek Kotala
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 SimpleLruInit to
catch name of S
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
(2009/12/14 20:48), Robert Haas wrote:
2009/12/14 KaiGai Kohei:
Robert Haas wrote:
2009/12/13 KaiGai Kohei:
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 stric
On Mon, Dec 14, 2009 at 7:22 AM, Simon Riggs 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 message?
...Robert
On Mon, Dec 14, 2009 at 7:30 AM, KaiGai Kohei wrote:
> (2009/12/14 20:48), Robert Haas wrote:
>>
>> 2009/12/14 KaiGai Kohei:
>>>
>>> Robert Haas wrote:
2009/12/13 KaiGai Kohei:
>>
>> Just to name a few really obvious problems (I only looked at the
>> 01-database patch):
>
On Mon, 2009-12-14 at 06:51 -0500, Robert Haas wrote:
> On Mon, Dec 14, 2009 at 6:35 AM, Simon Riggs wrote:
> > On Mon, 2009-12-14 at 06:21 -0500, Robert Haas wrote:
> >> On Mon, Dec 14, 2009 at 6:11 AM, Simon Riggs wrote:
> >> > On Mon, 2009-12-14 at 11:09 +0100, Magnus Hagander wrote:
> >> >> O
On Mon, Dec 14, 2009 at 7:19 AM, Bernd Helmle wrote:
> --On 10. Dezember 2009 16:49:50 +0100 Zdenek Kotala
> 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 b
(2009/12/14 21:34), Robert Haas wrote:
On Mon, Dec 14, 2009 at 7:30 AM, KaiGai Kohei wrote:
(2009/12/14 20:48), Robert Haas wrote:
2009/12/14 KaiGai Kohei:
Robert Haas wrote:
2009/12/13 KaiGai Kohei:
Just to name a few really obvious problems (I only looked at the
01-database patch):
1
On Mon, 2009-12-14 at 07:33 -0500, Robert Haas wrote:
> On Mon, Dec 14, 2009 at 7:22 AM, Simon Riggs 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: "cv
On Mon, Dec 14, 2009 at 13:47, Simon Riggs wrote:
> On Mon, 2009-12-14 at 07:33 -0500, Robert Haas wrote:
>> On Mon, Dec 14, 2009 at 7:22 AM, Simon Riggs 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
Scott Bailey 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 values of the base
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 deter
On Sat, Dec 12, 2009 at 5:09 PM, Heikki Linnakangas
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 probably means
> introducing a new sta
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-beati
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
Date: Mon, Dec 14, 2009 at 19:04
Subject: pgAdmin III: timestamp displayed in what time zone?
To: pgsql-gene...@postgresql.org
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: `"/usr
On Mon, Dec 14, 2009 at 7:42 AM, Simon Riggs 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 of the whitespace
Fujii Masao writes:
> On Mon, Dec 14, 2009 at 11:38 AM, Tom Lane 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 amount of code there.
> Yeah,
Takahiro Itagaki writes:
> Tom Lane 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
> not be a performance overhead because the c
Greg Stark writes:
> On Fri, Dec 11, 2009 at 6:08 PM, Tom Lane 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 testing infrastructure
>> that w
Greg Stark 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* WAL-logged, and it w
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 w
Scott Bailey 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 values of the ba
Takahiro Itagaki 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 you
managed to find and chan
KaiGai Kohei 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 inconsistency.
> (Needless t
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 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 (pgsql-hackers@postgresql.org)
To make changes
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
d
Robert Haas writes:
> On Mon, Dec 14, 2009 at 4:06 AM, 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 already pointed out, there's
On Mon, 2009-12-14 at 09:51 -0500, Tom Lane wrote:
> Greg Stark 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 c
Robert Haas writes:
> On Mon, Dec 14, 2009 at 6:35 AM, Simon Riggs 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 mentioning they had done so?
> pgiden
On Mon, Dec 14, 2009 at 10:08 AM, Simon Riggs 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 the patch.
>
> I
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 u
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
>> 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
>>>
Greg Smith 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 "Discussing review"
On Mon, 2009-12-14 at 09:14 -0600, Kevin Grittner wrote:
> Simon Riggs 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 certain that is exac
On Mon, Dec 14, 2009 at 11:09:49AM +0100, Magnus Hagander wrote:
> On Mon, Dec 14, 2009 at 10:54, Heikki Linnakangas
> 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 th
On Mon, Dec 14, 2009 at 10:49 AM, Simon Riggs wrote:
> On Mon, 2009-12-14 at 09:14 -0600, Kevin Grittner wrote:
>> Simon Riggs 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
Fujii Masao 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 passed.
Use PQ
Simon Riggs 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 an explicit option
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 i
Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Dec 14, 2009 at 6:35 AM, Simon Riggs 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 mentioning t
Scott Bailey 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 can't. For instance
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 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 continuing th
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 par
On Mon, Dec 14, 2009 at 12:38 PM, Greg Smith 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 is a final
>> s
>> 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
>>
On Mon, Dec 14, 2009 at 11:07 AM, Simon Riggs 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 uses a lower se
Andrew Gierth 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 that would
be an especially
On Mon, 2009-12-14 at 11:25 -0500, Tom Lane wrote:
> Scott Bailey 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 witho
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
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 ma
Nathan Boley 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
> 'next' se
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.
> Th
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 Post
Jeff Davis 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 continuous ran
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. Tha
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-l
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 thi
> "Tom" == Tom Lane 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 seem
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 essent
On Mon, Dec 14, 2009 at 1:42 PM, Peter Eisentraut 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, because of
Simon Riggs 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 relcache.c). It mig
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 thi
Tom Lane wrote:
Scott Bailey 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 can't. For
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,
> >>
Heikki Linnakangas 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 protocol.
AFAIR, libpq knows essenti
On Mon, 2009-12-14 at 13:48 -0500, Tom Lane wrote:
> Simon Riggs 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 va
1 - 100 of 151 matches
Mail list logo
