On 10/11/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > Could you describe bit more? The is_visible_txid() works
> > on data returned by txid_current_snapshot()? How can there
> > be any subtrans id's if txid_current_snapshot() wont return
> > them?
>
> Ah
> > The results have nothing to do with whether the process was followed.
> > We do not ignore process violations just because the outcome was OK.
>
> Agreed. But reversing something that came out OK for no other reason
> than that the process was violated? I know you don't, but some people
>
Andy,
seems you're a right person for writing migration guide.
Oleg
On Wed, 10 Oct 2007, andy wrote:
andy wrote:
Andy Colson wrote:
Hi All,
You knew it was coming
I tried doing a pg_dump --schema-only and restoring just that, but still
got a bunch of errors (those above). If I clean
On 10/9/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
>
> Andrew Dunstan wrote:
> > Florian G. Pflug wrote:
> >>
> >> I think you're overly pessimistic here ;-) This classification can be
> done
> >> quite efficiently as long as your language is "static enough". The
> trick is
> >> not to execute
"Robert A. Klahn" <[EMAIL PROTECTED]> writes:
> I am interested in increasing the PostgreSQL TransactionID, as part
> of testing a (yet another) replication system that I am working on.
> (http://bruce.codehaus.org/ for the interested). I would like to test
> what happens when the transaction
Tatsuo Ishii wrote:
> I don't undrestand why the txid stuff is in 8.3beta(this is an unsual
> case right?), but if we decide to keep it, please consider updating
> release.sgml. Bruce explained me that release.sgml will not be updated
> until the official release, but this is the unusual case and w
I don't undrestand why the txid stuff is in 8.3beta(this is an unsual
case right?), but if we decide to keep it, please consider updating
release.sgml. Bruce explained me that release.sgml will not be updated
until the official release, but this is the unusual case and we need to
break the rule, I
On Wed, 10 Oct 2007 17:57:57 -0700
"Robert A. Klahn" <[EMAIL PROTECTED]> wrote:
> Greetings:
>
> I am interested in increasing the PostgreSQL TransactionID, as part
> of testing a (yet another) replication system that I am working on.
> (http://bruce.codehaus.org/ for the interested). I would
Greetings:
I am interested in increasing the PostgreSQL TransactionID, as part
of testing a (yet another) replication system that I am working on.
(http://bruce.codehaus.org/ for the interested). I would like to test
what happens when the transactionID crosses 2^31 and when it wraps
aroun
In bug #3662
http://archives.postgresql.org/pgsql-bugs/2007-10/msg00047.php
we see that it doesn't work to do nextval('seq') on a temp sequence
in a plpgsql function except via EXECUTE, because the sequence OID gets
embedded into the cached plan, same as any other temp table. This is to
be expect
Tom Lane wrote:
Florian Pflug <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I think txid_current_snapshot should read ActiveSnapshot. If the user
wants to get a beginning-of-xact rather than beginning-of-statement
snapshot from it, he should be required to call it in a serializable
transaction
On 10/10/2007 12:08 PM, 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.
Agreed. But reversing something that came out OK for no other reason
than that the process was violated? I kno
On Thu, 11 Oct 2007 01:43:16 +0300
Hannu Krosing <[EMAIL PROTECTED]> wrote:
> AH, now I see it , and I think I understand your concerns better ;)
>
> > this statement is obvious naivety.
>
> Then you should not feel threatened by including this in contrib
>
Please do not mistake my concerns f
Ühel kenal päeval, K, 2007-10-10 kell 17:17, kirjutas Tom Lane:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > Could you describe bit more? The is_visible_txid() works
> > on data returned by txid_current_snapshot()? How can there
> > be any subtrans id's if txid_current_snapshot() wont return
>
Ühel kenal päeval, K, 2007-10-10 kell 10:10, kirjutas Joshua D. Drake:
> 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,
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> We wouldn't be having this discussion at all if we had not had a
> horribly long period beween feature freeze and beta.
I'm not sure about that. The bottom line to me is that we are doing a
favor to the Slony and Skytools projects, who figured out *af
Florian Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think txid_current_snapshot should read ActiveSnapshot. If the user wants
>> to get a beginning-of-xact rather than beginning-of-statement snapshot from
>> it, he should be required to call it in a serializable transaction.
> Hm...
Tom Lane wrote:
andy <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Did the data transfer over? The declarations of the former contrib
functions would of course fail, but type tsvector is still there.
I would like to think that ignoring pg_restore's whining would get
you most of the way there.
andy <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Did the data transfer over? The declarations of the former contrib
>> functions would of course fail, but type tsvector is still there.
>> I would like to think that ignoring pg_restore's whining would get
>> you most of the way there.
> So I
andy wrote:
Andy Colson wrote:
Hi All,
You knew it was coming
I tried doing a pg_dump --schema-only and restoring just that, but
still got a bunch of errors (those above). If I clean that up of all
the old text search stuff, and then run it, then do the data, will
that work ok?
Fu
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> Could you describe bit more? The is_visible_txid() works
> on data returned by txid_current_snapshot()? How can there
> be any subtrans id's if txid_current_snapshot() wont return
> them?
Ah, I see: txid_current() never reports a subxact ID so there's
On Wed, 10 Oct 2007 17:10:17 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> Looking at the discussion, I think we should just keep it
> in /contrib. The code is tightly tied to our backend transaction
> system so there is logic to have it in /contrib rather than
> pgfoundry. I do think
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> It's been a while since I looked at it, but my recollection is that
> much of the standard date/time math which people assert can't handle
> practical use cases do work if the timestamps and times WITH TIME
> ZONE have a time zone in the offset-from-UT
Looking at the discussion, I think we should just keep it in /contrib.
The code is tightly tied to our backend transaction system so there is
logic to have it in /contrib rather than pgfoundry. I do think we
should just move it into core for 8.4 though.
-
>>> On Wed, Oct 10, 2007 at 2:51 PM, in message
<[EMAIL PROTECTED]>, "Kevin Grittner"
<[EMAIL PROTECTED]> wrote:
On Wed, Oct 10, 2007 at 12:23 PM, in message
> <[EMAIL PROTECTED]>, Magne
> Mæhre <[EMAIL PROTECTED]> wrote:
>> An interesting observation is that,
>> as far as I can tell, the o
Tom Lane wrote:
Andy Colson <[EMAIL PROTECTED]> writes:
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:
...
I didn't really expect it to totally work, but I'm not sure how to move
my db.
Did the data transfer over? The declar
On Wed, 10 Oct 2007 21:02:30 +0100
Gregory Stark <[EMAIL PROTECTED]> wrote:
>
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>
> > There are quite a few contributors that are upset that this whole
> > process went down the way that it did. I would say they are likely
> > in the majority versus
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> There are quite a few contributors that are upset that this whole
> process went down the way that it did. I would say they are likely in
> the majority versus the people that just want to leave it alone and
> move on.
> That means it is not comp
Andy Colson <[EMAIL PROTECTED]> writes:
> 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:
> ...
> I didn't really expect it to totally work, but I'm not sure how to move
> my db.
Did the data transfer over? The declarations of
On 10/10/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > On 10/10/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> * Why is txid_current_snapshot() excluding subtransaction XIDs? That
> >> might be all right for the current uses in Slony/Skytools, but it seems
>
>>> On Wed, Oct 10, 2007 at 12:23 PM, in message
<[EMAIL PROTECTED]>, Magne
Mæhre <[EMAIL PROTECTED]> wrote:
> An interesting observation is that,
> as far as I can tell, the original time zone is only applied when
casting
> the element to a string. Apart from that, it's not used.
It's been a w
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> On 10/10/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> * Why is txid_current_snapshot() excluding subtransaction XIDs? That
>> might be all right for the current uses in Slony/Skytools, but it seems
>> darn close to a bug for any other use.
> ...
> But I ag
Andy Colson wrote:
Hi All,
You knew it was coming
I tried doing a pg_dump --schema-only and restoring just that, but still
got a bunch of errors (those above). If I clean that up of all the old
text search stuff, and then run it, then do the data, will that work ok?
Further to this,
On Oct 10, 2007, at 13:30 , Tom Lane wrote:
That could perhaps be
addressed by merging it into 8.4 before anyone does any snapshot
fixing,
but our track record on causing such things to happen in a particular
sequence isn't great ...
Granted, everyone's focused on the 8.3 branch right now,
Tom Lane wrote:
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 mo
Hello,
Well this certainly turned into something bigger than I thought it ever
would. The questions that come into play with this whole thread are
larger than just, "the process wasn't followed, what do we do?"
We obviously don't want to make life difficult for our sibling projects
such as Slony
Tom Lane wrote:
The proposed behavior of txid_current_snapshot would defeat any possibility
of such an optimization, because we'd have to keep around the xact's oldest
snapshot on the off chance that txid_current_snapshot would be called later
in the xact.
I think txid_current_snapshot should re
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Ãhel kenal päeval, K, 2007-10-10 kell 12:18, kirjutas Tom Lane:
>> * Why is txid_current_snapshot() reading SerializableSnapshot rather
>> than an actually current snap as its name suggests?
> Why is SerializableSnapshot going away ?
> How will we do
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> wrote:
>> Putting it in core or contrib means that when we change the snapshot
>> mechanics in 8.4 the same developer will be able to fix the module at
>> the same time (and find out if his changes break it at the sam
Ü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 i
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 fo
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:
ERROR: could not access file "$libdir/tsearch2": No such file or directory
ERROR: function public.gtsq_in(cstring) does not exist
ERROR: cou
Ü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 <[EMA
Ü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 thi
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
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
>
=?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 co
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 o
"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
t
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 (c
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 change,
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
inv
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 wi
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 ther
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 s
"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, co
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:
"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 nul
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 -
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Hiroshi Saito" <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, October 10, 2007 9:55 PM
Subject: Re: [HACKERS] permission denied for tablespace pg_global?
"Hiroshi Saito" <[EMAIL PROTECTED]> writes:
postgres=# SELECT pg_size
"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 re
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
-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 nullabil
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 exis
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?
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
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
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 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:
> >>
>
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 c
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
>
"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 st
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
Po
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
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
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 sho
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 expecte
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
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 usef
>>> 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
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.
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 no
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
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
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
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.
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.
>
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
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 tha
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,
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, bu
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, I
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
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 b
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 wit
* 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
> s
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? A
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 hav
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 for
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 ver
1 - 100 of 131 matches
Mail list logo
