We allow /contrib to be more lax about beta changes.
the postgresql ecosystem is growing and there is a lot of people like
packagers that will be a quite irritated if we keep randomly adding
completely new code and modules during BETA.
Should packagers be concerned with /contrib at
Ühel kenal päeval, K, 2007-10-10 kell 07:44, kirjutas Magnus Hagander:
We allow /contrib to be more lax about beta changes.
the postgresql ecosystem is growing and there is a lot of people like
packagers that will be a quite irritated if we keep randomly adding
completely new code
On Tue, 2007-10-09 at 18:35 -0400, Andrew Dunstan wrote:
I think this project has got too big for us to make things up as we go
along. We need to follow processes that are well understood and
transparent.
Well said, I very much agree.
Mostly we do, but since we've just spent more than 6
On Wed, 2007-10-10 at 01:14 -0300, Euler Taveira de Oliveira wrote:
Simon Riggs wrote:
I would prefer that we backported pg_standby into 8.2 contrib, so the
solution is where people need it to be. If not...
Don't know about the policy to put things in already-released-version
but if
Hi,
On Tue, 2007-10-09 at 17:10 -0700, Joshua D. Drake wrote:
(Will all respect to pginstaller team, I'm *think* it won't take
much
time to add txid to installer, at least compared to the time that we
spent discussing this issue.)
With respect, you don't know. My understanding of the
Simon Riggs wrote:
I would prefer that we backported pg_standby into 8.2 contrib, so the
solution is where people need it to be. If not...
Don't know about the policy to put things in already-released-version
but if it's not the case, we could at least put the code somewhere in
We allow /contrib to be more lax about beta changes.
the postgresql ecosystem is growing and there is a lot of people like
packagers that will be a quite irritated if we keep randomly adding
completely new code and modules during BETA.
Should packagers be concerned
Simon Riggs wrote:
Personally, I want to see Jan contribute more, not less. The link with
Slony and related replication technology is critically important to
Postgres, which is why Jan has spent so long on it.
Generally we should be encouraging everybody to contribute; the project
must have
Alvaro Herrera schreef:
Deblauwe Gino wrote:
OS: Windows XP Pro SP2
CPU: AMD Athlon 64 3500+
RAM: 2GB
DB: PostgreSQL 8.3beta1, compiled by Visual C++ build 1400
I've come to the conclusion that it seems like a deadlock occurs when
dropping a column in a table the same moment that table is
Devrim GÜNDÜZ wrote:
(Will all respect to pginstaller team, I'm *think* it won't take much
time to add txid to installer, at least compared to the time that we
spent discussing this issue.)
Time is not the issue.
/D
---(end of broadcast)---
TIP
On Wed, 2007-10-10 at 07:08 +0100, Simon Riggs wrote:
On Tue, 2007-10-09 at 18:35 -0400, Andrew Dunstan wrote:
I think this project has got too big for us to make things up as we go
along. We need to follow processes that are well understood and
transparent.
Well said, I very much
Peter Eisentraut wrote:
Dave Page wrote:
setlocale(LC_CTYPE, English_United Kingdom.65001)
will return null (and not change anything) because it doesn't like
the combination of the locale and that encoding (UTF-8).
The reason that that call fails is probably that the operating system
Am Mittwoch, 10. Oktober 2007 schrieb Dave Page:
Latin1 is a perfectly valid encoding for my locale English_United
Kingdom. It is accepted by setlocale for LC_ALL.
Why does initdb reject it? Why does it insist the encoding is not valid
for the locale?
Because initdb works with a finite list
On 10/10/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
On Tue, 9 Oct 2007 18:35:52 -0500
Michael Glaesemann [EMAIL PROTECTED] wrote:
On Oct 9, 2007, at 0:06 , Bruce Momjian wrote:
I am surprised we are not backing
out the patch and requiring that the patch go through the formal
review
Peter Eisentraut wrote:
Am Mittwoch, 10. Oktober 2007 schrieb Dave Page:
Latin1 is a perfectly valid encoding for my locale English_United
Kingdom. It is accepted by setlocale for LC_ALL.
Why does initdb reject it? Why does it insist the encoding is not valid
for the locale?
Because
On Wed, 2007-10-10 at 14:57 +1000, Brendan Jurd wrote:
Wouldn't it be more useful if quote_literal(NULL) yielded the text value
'NULL'?
I don't think you can change that now. There could be code out there
that relies on that behaviour.
It isn't very helpful to return the word NULL in many
On 10/10/2007 12:05 AM, Shane Ambler wrote:
Devrim GÜNDÜZ wrote:
Hi,
On Tue, 2007-10-09 at 16:50 -0700, Joshua D. Drake wrote:
IMO, the patch is reverted, and submitted for 8.4 or pgfoundry.
You know, txid was discussed in Slony-I + Skytools lists for a
reasonably long time, and Tom also
Am Mittwoch, 10. Oktober 2007 schrieb Dave Page:
So is it just a case of us generating a list of matches that may be
Windows specific, or is there more to it than that?
You want to peruse src/port/chklocale.c. There is already explicit Windows
support in there, so maybe you just need to add
On 10/10/07, Simon Riggs [EMAIL PROTECTED] wrote:
On Wed, 2007-10-10 at 14:57 +1000, Brendan Jurd wrote:
Wouldn't it be more useful if quote_literal(NULL) yielded the text value
'NULL'?
I don't think you can change that now. There could be code out there
that relies on that behaviour.
hello
there are lot of spam. Can I remove it from my project?
http://pgfoundry.org/tracker/index.php?group_id=1000113atid=497
Pavel
---(end of broadcast)---
TIP 6: explain analyze is your friend
Hi,
I have tested pgstattuple with lot of scenarios want to clarify some
of the things.
In the Readme file you have explained clearly about pgstattuple
function. I mean explanation for each column.
But for some of the functions like btree index metapage,single btree
pages,bt page items are
Simon Riggs wrote:
My thoughts are that it doesn't need to. Typically we create objects and
then fill them. It isn't that frequent that we would load data, then
delete or update more than 20% of it, then attempt other DDL.
One scenario that comes to mind is a table that's used in OLTP fashion
On Wed, 2007-10-10 at 11:50 +0300, Marko Kreen wrote:
On 10/10/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
IMO, the patch is reverted, and submitted for 8.4 or pgfoundry.
Yes, reverting is an option
Reverting is only an option if we need to solve a technical problem. If
there is no
Heikki,
Thanks for your comments, we do need some review on the expected
behaviour.
On Wed, 2007-10-10 at 11:17 +0100, Heikki Linnakangas wrote:
Simon Riggs wrote:
My thoughts are that it doesn't need to. Typically we create objects and
then fill them. It isn't that frequent that we would
Khan, Mahmood Ahram wrote:
But for some of the functions like btree index metapage,single btree
pages,bt page items are not clear to me.
Those functions display the contents of b-tree pages. They're really
meant for debugging purposes. You'll need to understand the internal
structure of a
On Wed, Oct 10, 2007 at 11:50:12AM +0300, Marko Kreen wrote:
On 10/10/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
On Tue, 9 Oct 2007 18:35:52 -0500
Michael Glaesemann [EMAIL PROTECTED] wrote:
On Oct 9, 2007, at 0:06 , Bruce Momjian wrote:
I am surprised we are not backing
out the
Peter Eisentraut wrote:
Am Mittwoch, 10. Oktober 2007 schrieb Dave Page:
So is it just a case of us generating a list of matches that may be
Windows specific, or is there more to it than that?
You want to peruse src/port/chklocale.c. There is already explicit Windows
support in there, so
Magnus Hagander wrote:
On Wed, Oct 10, 2007 at 11:50:12AM +0300, Marko Kreen wrote:
On 10/10/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
On Tue, 9 Oct 2007 18:35:52 -0500
Michael Glaesemann [EMAIL PROTECTED] wrote:
On Oct 9, 2007, at 0:06 , Bruce Momjian wrote:
I am surprised we are not
Simon Riggs wrote:
OK, I've got this working now. It successfully handles this test case,
which trips up on an auto ANALYZE every time I run it.
...
I notice when we cancel an AV worker it always says cancelling
autovacuum of table, even when its just an ANALYZE. Wasn't important
before but
On Wed, 2007-10-10 at 11:04 +0200, Michael Paesold wrote:
Simon Riggs wrote:
OK, I've got this working now. It successfully handles this test case,
which trips up on an auto ANALYZE every time I run it.
...
I notice when we cancel an AV worker it always says cancelling
autovacuum of
Dave Page wrote:
Peter Eisentraut wrote:
Am Mittwoch, 10. Oktober 2007 schrieb Dave Page:
So is it just a case of us generating a list of matches that may be
Windows specific, or is there more to it than that?
You want to peruse src/port/chklocale.c. There is already explicit Windows
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Wednesday, October 10, 2007 07:09:20 +0100 Simon Riggs
[EMAIL PROTECTED] wrote:
On Wed, 2007-10-10 at 01:14 -0300, Euler Taveira de Oliveira wrote:
Simon Riggs wrote:
I would prefer that we backported pg_standby into 8.2 contrib, so
Am Mittwoch, 10. Oktober 2007 schrieb Dave Page:
my original question remains: why can I only select the
*default* encoding for the chosen locale, but not other ones that are
also be valid according to setlocale? Is this a bug, or is there some
technical reason?
One locale works only with one
On 10/10/07, Magnus Hagander [EMAIL PROTECTED] wrote:
All objections have been procedural, AFICS.
Lets not talk about mistakes we made for a moment.
And I agree with the rest of the objections in general. But I'd
like to summarise why I still hope the exception can be made
even this late.
This
Dave Page [EMAIL PROTECTED] writes:
However, setlocale() will also accept other valid combinations on
Windows, which initdb will not, for example:
English_United Kingdom.28591 (Latin1)
Is there any reason not to accept other combinations that setlocale() is
happy with?
Are you certain that
Peter Eisentraut wrote:
Am Mittwoch, 10. Oktober 2007 schrieb Dave Page:
my original question remains: why can I only select the
*default* encoding for the chosen locale, but not other ones that are
also be valid according to setlocale? Is this a bug, or is there some
technical reason?
One
On Wed, Oct 10, 2007 at 03:27:17PM +0300, Marko Kreen wrote:
On 10/10/07, Magnus Hagander [EMAIL PROTECTED] wrote:
All objections have been procedural, AFICS.
Lets not talk about mistakes we made for a moment.
And I agree with the rest of the objections in general. But I'd
like to
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
However, setlocale() will also accept other valid combinations on
Windows, which initdb will not, for example:
English_United Kingdom.28591 (Latin1)
Is there any reason not to accept other combinations that setlocale() is
happy with?
Are
Peter Eisentraut [EMAIL PROTECTED] writes:
We are not considering an interval scheduling system, we are considering a
database system. Such a system should have the basic property that if you
store A, it will read out as A.
I'm not sure that I think this sort of rigid thinking works very
Hiroshi Saito [EMAIL PROTECTED] writes:
postgres=# SELECT pg_size_pretty(pg_tablespace_size(1664));
ERROR: permission denied for tablespace pg_global
This is an intentional change, documented in the release notes:
* Put some security restrictions on the dbsize functions (Tom)
Restrict
Dave Page [EMAIL PROTECTED] writes:
Tom Lane wrote:
Are you certain that that acceptance actually represents support?
Have you checked that it rejects combinations involving real code
pages (ie, NOT 65001) that don't really work with the locale?
It fails with ones that Microsoft have decided
Gregory Stark [EMAIL PROTECTED] writes:
Long term I liked the idea from a few years ago of having a default format
which would be attached to a column just like a default collation can be
attached. Then you can declare your currency columns as regular integers but
mark them as being formatted
* Peter Eisentraut [EMAIL PROTECTED] [071010 09:58]:
If we make an appointment at 12-November-2007 at 10:00 CET (winter time) and
next week those in charge decide to postpone the change to winter time from
28-October-2007 to 25-November-2007, what becomes of the appointment? Do we
still
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
Tom Lane wrote:
Are you certain that that acceptance actually represents support?
Have you checked that it rejects combinations involving real code
pages (ie, NOT 65001) that don't really work with the locale?
It fails with ones that
Am Mittwoch, 10. Oktober 2007 schrieb Tom Lane:
I'm not sure that I think this sort of rigid thinking works very well in
the wonderland that is date/time behavior. When the rules of the game
(ie, DST laws) are changing underneath you, who is to say exactly what
reading out as A means?
Dave Page [EMAIL PROTECTED] writes:
OK so I added the appropriate entries (and posted the patch to
-patches), but my original question remains: why can I only select the
*default* encoding for the chosen locale, but not other ones that are
also be valid according to setlocale? Is this a bug,
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
OK so I added the appropriate entries (and posted the patch to
-patches), but my original question remains: why can I only select the
*default* encoding for the chosen locale, but not other ones that are
also be valid according to setlocale?
Marko Kreen wrote:
On 10/10/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
On Tue, 9 Oct 2007 18:35:52 -0500
Michael Glaesemann [EMAIL PROTECTED] wrote:
On Oct 9, 2007, at 0:06 , Bruce Momjian wrote:
I am surprised we are not backing
out the patch and requiring that the patch go
On Wednesday 10 October 2007 02:09, Simon Riggs wrote:
On Wed, 2007-10-10 at 01:14 -0300, Euler Taveira de Oliveira wrote:
Simon Riggs wrote:
I would prefer that we backported pg_standby into 8.2 contrib, so the
solution is where people need it to be. If not...
Don't know about the
Agreed. I think if we had followed procedure the code would have been
accepted post-beta1.
---
Marko Kreen wrote:
On 10/10/07, Magnus Hagander [EMAIL PROTECTED] wrote:
All objections have been procedural, AFICS.
Lets
Magnus Hagander wrote:
Now txid can change that. E.g. in Skype, it has become irreplaceable
tool for coordinating work between several databases. Here we are
probably going overboard with usage of queues...
If it is this irreplacable killer feature, it should *not* be in contrib.
It
Pavel Stehule wrote:
OK, how do we even explain this idea in the FAQ. It pulls 20 random
values from 1 to 1? That seems pretty hard to code to me. Where do
you get the 1 number from? How do you know you will hit a match in
20 tries?
Number 1 you have to store in
Magnus Hagander wrote:
If it is this irreplacable killer feature, it should *not* be in contrib.
It should be in the core backend, and we should be discussing if we can
bend the rules for that. This is the proper forum for discussing that, so
let's bring that question to the table.
Our beta-1
Magnus Hagander wrote:
If it is this irreplacable killer feature, it should *not* be in contrib.
It should be in the core backend, and we should be discussing if we can
bend the rules for that. This is the proper forum for discussing that, so
let's bring that question to the table.
+1 there,
Simon Riggs wrote:
On Tue, 2007-10-09 at 18:35 -0400, Andrew Dunstan wrote:
I think this project has got too big for us to make things up as we go
along. We need to follow processes that are well understood and
transparent.
Well said, I very much agree.
Mostly we do, but since
Aidan Van Dyk [EMAIL PROTECTED] writes:
* Peter Eisentraut [EMAIL PROTECTED] [071010 09:58]:
If we make an appointment at 12-November-2007 at 10:00 CET (winter time) and
next week those in charge decide to postpone the change to winter time from
28-October-2007 to 25-November-2007, what
Dave Page [EMAIL PROTECTED] writes:
In fact, it looks like it'll allow me to use anything thats installed,
regardless of whether they're liekly to be compatible. So much for
trusting setlocale() :-(
Yech :-(. Count on Microsloth to get this wrong. Anyone have any ideas
on how to tell if a
Robert Treat wrote:
On Wednesday 10 October 2007 02:09, Simon Riggs wrote:
On Wed, 2007-10-10 at 01:14 -0300, Euler Taveira de Oliveira wrote:
Simon Riggs wrote:
I would prefer that we backported pg_standby into 8.2 contrib, so the
solution is where people need it to be. If
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Oct 10, 2007 at 03:27:17PM +0300, Marko Kreen wrote:
Now txid can change that. E.g. in Skype, it has become irreplaceable
tool for coordinating work between several databases. Here we are
probably going overboard with usage of queues...
If
On Wed, Oct 10, 2007 at 4:57 AM, in message
[EMAIL PROTECTED], Brendan Jurd
[EMAIL PROTECTED] wrote:
On 10/10/07, Simon Riggs [EMAIL PROTECTED] wrote:
On Wed, 2007-10-10 at 14:57 +1000, Brendan Jurd wrote:
Wouldn't it be more useful if quote_literal(NULL) yielded the text value
'NULL'?
Tom Lane wrote:
Exactly ... there is more than one right answer here. The answer that
PG's TIMESTAMP WITH TIME ZONE code deems to be right is that UTC is
reality. That's a definition that is indeed useful for a wide variety
of real-world problems. In a lot of cases where it's not so useful,
Dave Page [EMAIL PROTECTED] writes:
... There is another issue
though as I mentioned in the post above - that it complains about an
invalid encoding specifier on the encoding name, then ignores it and
uses the default which seems wrong to me.
Yeah, if you look at chklocale() in initdb.c this
Bruce Momjian [EMAIL PROTECTED] writes:
Marko Kreen wrote:
Also I think several people are annoyed by the Jan asked permission
from -core part of the process.
I don't think this is accurate. Jan talked to Tom, not all of core, and
Tom just gave general approval. Tom still expected this to
Bruce Momjian [EMAIL PROTECTED] writes:
I also agree with this. We have to pretend it isn't in /contrib now,
figure out where want it, then put it there (contrib, pgfoundry, core).
Putting it in core now would mean forcing a post-beta1 initdb, which
I don't think adequate cause has been shown
On 10/10/07, Tom Lane [EMAIL PROTECTED] wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Oct 10, 2007 at 03:27:17PM +0300, Marko Kreen wrote:
Now txid can change that. E.g. in Skype, it has become irreplaceable
tool for coordinating work between several databases. Here we are
On Wed, Oct 10, 2007 at 11:30:47AM -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I also agree with this. We have to pretend it isn't in /contrib now,
figure out where want it, then put it there (contrib, pgfoundry, core).
Putting it in core now would mean forcing a
Hi,
On Wed, 2007-10-10 at 09:19 +0100, Simon Riggs wrote:
I should add that I'm not unhappy about how things have happened and I
have no complaints to lodge anywhere with anybody. Just wanted to give
Jan a bit of moral support
I have the same feelings, so +1.
Regards,
--
Devrim GÜNDÜZ
Marko Kreen [EMAIL PROTECTED] writes:
IMHO the core operations are already as stable as PostgreSQL use
of MVCC, as the module just exports backend internal state...
Well, it exports backend internal state that did not exist before 8.2
(ie, XID epoch). So it doesn't seem all that set in stone
On Wed, 2007-10-10 at 10:29 -0400, Bruce Momjian wrote:
Simon Riggs wrote:
Mostly we do, but since we've just spent more than 6 months between
Feature Freeze and Beta. There were no well understood or transparent
processes during that period, so nobody is on solid ground trying to
On Wednesday 10 October 2007 10:57, Andrew Dunstan wrote:
Robert Treat wrote:
On Wednesday 10 October 2007 02:09, Simon Riggs wrote:
On Wed, 2007-10-10 at 01:14 -0300, Euler Taveira de Oliveira wrote:
Simon Riggs wrote:
I would prefer that we backported pg_standby into 8.2 contrib, so the
On Wed, 2007-10-10 at 10:12 -0500, Kevin Grittner wrote:
On Wed, Oct 10, 2007 at 4:57 AM, in message
[EMAIL PROTECTED], Brendan Jurd
[EMAIL PROTECTED] wrote:
On 10/10/07, Simon Riggs [EMAIL PROTECTED] wrote:
On Wed, 2007-10-10 at 14:57 +1000, Brendan Jurd wrote:
Wouldn't it be more
On 10/10/07, Tom Lane [EMAIL PROTECTED] wrote:
The arguments that have been made for storing a zone along with the UTC
value seem to mostly boil down to it should present the value the same
way I entered it, but if you accept that argument then why do we have
DateStyle? If it's OK to
On 10/10/07, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
IMHO the core operations are already as stable as PostgreSQL use
of MVCC, as the module just exports backend internal state...
Well, it exports backend internal state that did not exist before 8.2
(ie, XID
Simon Riggs wrote:
On Wed, 2007-10-10 at 10:29 -0400, Bruce Momjian wrote:
Simon Riggs wrote:
Mostly we do, but since we've just spent more than 6 months between
Feature Freeze and Beta. There were no well understood or transparent
processes during that period, so nobody is on solid
Magnus Hagander [EMAIL PROTECTED] writes:
(Assuming it's technically sound - I still haven't checked the actual
code, but I'm assuming it's Ok since Jan approved it)
I hadn't looked at it either, but here are a few things that need
review:
* Why no binary I/O support for the new datatype? We
On Wed, Oct 10, 2007 at 11:47:15AM -0400, Tom Lane wrote:
Marko Kreen [EMAIL PROTECTED] writes:
IMHO the core operations are already as stable as PostgreSQL use
of MVCC, as the module just exports backend internal state...
Well, it exports backend internal state that did not exist before
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Perhaps have quote_nullable() then as well?
You then use quote_nullable() in INSERT and UPDATE SET clauses and
quote_literal() in SELECT WHERE clauses.
I still don't see the use case. Wouldn't your app still need to check
for nullability
Robert Treat [EMAIL PROTECTED] writes:
On Wednesday 10 October 2007 10:57, Andrew Dunstan wrote:
One of pgfoundry's explicit purposes is for backports of features.
I can't think of any contrib modules we've added that also required
backwards comptible modules to be released on foundry at the
Trevor Talbot [EMAIL PROTECTED] writes:
Actually, what I meant at least (not sure if others meant it), is
storing the value in the timezone it was entered, along with what zone
that was. That makes the value stable with respect to the zone it
belongs to, instead of being stable with respect
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
To: Hiroshi Saito [EMAIL PROTECTED]
Cc: pgsql-hackers@postgresql.org
Sent: Wednesday, October 10, 2007 9:55 PM
Subject: Re: [HACKERS] permission denied for tablespace pg_global?
Hiroshi Saito [EMAIL PROTECTED] writes:
On Oct 10, 2007, at 11:24 , Greg Sabino Mullane wrote:
(Aside: seems to me that
SET foo = NULL; really should be SET foo TO NULL; to be consistent
with WHERE foo IS NULL;)
The = character has different meanings in these two cases.
UPDATE foos
SET foo = NULL -- assignment
WHERE bar IS NULL
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Perhaps have quote_nullable() then as well?
You then use quote_nullable() in INSERT and UPDATE SET clauses and
quote_literal() in SELECT WHERE clauses.
I still don't see the use case. Wouldn't your app still need to check
for nullability
Hi.
Oops, I pursued the thread and was not competent.
I will inquire thoroughly. Thanks!!
Regards,
Hiroshi Saito
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
Hiroshi Saito [EMAIL PROTECTED] writes:
postgres=# SELECT pg_size_pretty(pg_tablespace_size(1664));
ERROR:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Oct 10, 2007 at 11:30:47AM -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I also agree with this. We have to pretend it isn't in /contrib now,
figure out where want it, then put it there (contrib, pgfoundry, core).
On Wed, 10 Oct 2007 11:04:53 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Oct 10, 2007 at 03:27:17PM +0300, Marko Kreen wrote:
Now txid can change that. E.g. in Skype, it has become
irreplaceable tool for coordinating work between several
On Wed, 10 Oct 2007 18:33:03 +0300
Marko Kreen [EMAIL PROTECTED] wrote:
Considering the core operations are now being in active use
some 6-7 years, I really fail to see how there can be anything
to tweak, unless you are speaking changing naming style.
Well that is the problem right there
On Wed, 10 Oct 2007 13:01:54 +0200
Stefan Kaltenbrunner [EMAIL PROTECTED] wrote:
yeah I agree that code like this should be either in core or
somewhere else (either pgfoundry or even shipped as part of the
replication solutions mentioned which is basically something slony
did for ages with
Am Mittwoch, 10. Oktober 2007 schrieb Tom Lane:
Peter's example of a future appointment time is a possible
counterexample, but as observed upthread it's hardly clear which
behavior is more desirable in such a case.
Whereas the most realistic solution to my example might be, the parties
Trevor Talbot wrote:
, what I meant at least (not sure if others meant it), is
storing the value in the timezone it was entered, along with what zone
that was. That makes the value stable with respect to the zone it
belongs to, instead of being stable with respect to UTC. When DST
rules
On Wed, 10 Oct 2007, Robert Treat wrote:
Simon Riggs wrote:
I would prefer that we backported pg_standby into 8.2 contrib, so the
solution is where people need it to be. If not...
If it was to go on pgfoundry (which I'd recommend) I'd suggest removing
it from 8.3 contrib before we release
Joshua D. Drake [EMAIL PROTECTED] writes:
If it doesn't need to be in core, in certainly has zero need to be in
contrib and can push to pgFoundry.
One advantage of having it in contrib is buildfarm testing, as indeed we
already found out ... although it's true that *keeping* it there now
that
On Wed, 2007-10-10 at 12:08 -0400, Bruce Momjian wrote:
The results have nothing to do with whether the process was followed.
We do not ignore process violations just because the outcome was OK.
And Jan did not come even close to following procedure. He just asked
core if they would
On 10/10/07, Tom Lane [EMAIL PROTECTED] wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
(Assuming it's technically sound - I still haven't checked the actual
code, but I'm assuming it's Ok since Jan approved it)
I hadn't looked at it either, but here are a few things that need
review:
*
Ühel kenal päeval, K, 2007-10-10 kell 12:18, kirjutas Tom Lane:
Magnus Hagander [EMAIL PROTECTED] writes:
(Assuming it's technically sound - I still haven't checked the actual
code, but I'm assuming it's Ok since Jan approved it)
I hadn't looked at it either, but here are a few things that
Ühel kenal päeval, K, 2007-10-10 kell 11:06, kirjutas Joshua D. Drake:
On Wed, 10 Oct 2007 18:01:34 +0100
Gregory Stark [EMAIL PROTECTED] wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Oct 10, 2007 at 11:30:47AM -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED]
=?ISO-8859-1?Q?Magne_M=E6hre?= [EMAIL PROTECTED] writes:
I would suggest that the WITH TIMEZONE elements are converted to UTC when
inserted into the database. Since all operations on it are based on
its UTC form, it's most efficient ( I believe) if the data is stored that
way. To be
On Wed, 10 Oct 2007 18:01:34 +0100
Gregory Stark [EMAIL PROTECTED] wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Oct 10, 2007 at 11:30:47AM -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I also agree with this. We have to pretend it isn't in /contrib
now,
Hi All,
You knew it was coming
I have an 8.2 database that has full text searching. I tried to
backup/restore it to 8.3 but got lots of errors:
snip
ERROR: could not access file $libdir/tsearch2: No such file or directory
ERROR: function public.gtsq_in(cstring) does not exist
ERROR:
On 10/10/07, Tom Lane [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
If it doesn't need to be in core, in certainly has zero need to be in
contrib and can push to pgFoundry.
One advantage of having it in contrib is buildfarm testing, as indeed we
already found out ...
Ühel kenal päeval, K, 2007-10-10 kell 18:23, kirjutas Magnus Hagander:
On Wed, Oct 10, 2007 at 11:47:15AM -0400, Tom Lane wrote:
Marko Kreen [EMAIL PROTECTED] writes:
IMHO the core operations are already as stable as PostgreSQL use
of MVCC, as the module just exports backend internal
1 - 100 of 138 matches
Mail list logo
