> No, they developed it for marketing.
Perhaps, but towards whom? PostgreSQL wouldn't hurt if a lot of developers and
DBA's was lured into the trap by this new feature.
> Keep in mind that Oracle has six thousand full-time developers and an
> already extremely mature database. Stuff that they s
On Tue, Jul 15, 2008 at 2:17 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> I agree such improvements would be welcomed. I'm pretty sure they sat
> around saying we can already do that some other way at first, until the
> requests started to pile up.
Agreed.
>
>> > Stuff that they see fit to add is
On Mon, 2008-07-14 at 22:54 -0400, Jonah H. Harris wrote:
> On Mon, Jul 14, 2008 at 9:18 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Kaare Rasmussen <[EMAIL PROTECTED]> writes:
> >> But yes, it has to be enabled, and yes it has to have a performance cost
> >> somehow, but people are requesting it,
On Mon, Jul 14, 2008 at 9:18 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Kaare Rasmussen <[EMAIL PROTECTED]> writes:
>> But yes, it has to be enabled, and yes it has to have a performance cost
>> somehow, but people are requesting it, and somehow I don't think Oracle
>> developed the feature just for
Kaare Rasmussen <[EMAIL PROTECTED]> writes:
> But yes, it has to be enabled, and yes it has to have a performance cost
> somehow, but people are requesting it, and somehow I don't think Oracle
> developed the feature just for fun.
No, they developed it for marketing.
Keep in mind that Oracle ha
On Mon, 2008-07-14 at 22:38 +0200, Kaare Rasmussen wrote:
> > This sounds a lot like the functionality that a temporal data model
> > would give you. In this model you never delete tuples from your
> > database, your only insert and update tuples that are valid for
> > specific periods of time.
>
Lewis Cunningham wrote:
> --- On Mon, 7/14/08, Kaare Rasmussen <[EMAIL PROTECTED]> wrote:
>
> > But yes, it has to be enabled, and yes it has to have a
> > performance cost
> > somehow, but people are requesting it, and somehow I
>
> AFAIK, It is built from undo so there is no ADDITIONAL overhea
--- On Mon, 7/14/08, Kaare Rasmussen <[EMAIL PROTECTED]> wrote:
> But yes, it has to be enabled, and yes it has to have a
> performance cost
> somehow, but people are requesting it, and somehow I
AFAIK, It is built from undo so there is no ADDITIONAL overhead. It just saves
the undo that is cr
On Mon, Jul 14, 2008 at 1:38 PM, Kaare Rasmussen <[EMAIL PROTECTED]> wrote:
> Isn't this exactly what Alvaro describes? The time travel feature that was
> removed because it made Postgres too slow to use in production?
No, I imagine that time travel was built into the Postgresql
architecture and w
> This sounds a lot like the functionality that a temporal data model
> would give you. In this model you never delete tuples from your
> database, your only insert and update tuples that are valid for
> specific periods of time.
Isn't this exactly what Alvaro describes? The time travel feature t
> which "it would come in handy" wouldn't have enabled it. (FWIW this
> feature used to exist in the Berkeley code, under the cool name "time
> travel", and was removed a long time ago.)
No, it didn't AFAIK. Timetravel kept all tuples in the database with all
indexes and constraints active at al
On Mon, 2008-07-14 at 21:59 +0200, Kaare Rasmussen wrote:
> > I just lost a months worth of stats data myself, so join the club. It
> > wasn't critical data, but it would have been nice to have kept
> > around...
>
> I also think there could be a TODO item in it. If vacuum instead of removing
>
Kaare Rasmussen escribió:
> I don't say it's an important feature, but it would come in handy for people
> who really really need it. And perhaps a developer wouldn't mind scratching
> this itch some time in the future.
It would need to be enabled beforehand, and most people I've seen for
which
On Mon, Jul 14, 2008 at 12:59 PM, Kaare Rasmussen <[EMAIL PROTECTED]> wrote:
> I also think there could be a TODO item in it. If vacuum instead of removing
> items, somehow stashed them away in a storage limited archive it would be
> possible to do a SELECT...AS OF TIMESTAMP.
This sounds a lot lik
> I just lost a months worth of stats data myself, so join the club. It
> wasn't critical data, but it would have been nice to have kept
> around...
I also think there could be a TODO item in it. If vacuum instead of removing
items, somehow stashed them away in a storage limited archive it would
On Mon, Jul 14, 2008 at 9:20 AM, samantha mahindrakar
<[EMAIL PROTECTED]> wrote:
> I didnt no the thread would become a postgresVSoracle thing. I just lost
> couple of thousand rows and could not retrieve them back, so i wanted to
> know if postgres had some way to get it back. Iam just a few days
I didnt no the thread would become a postgresVSoracle thing. I just lost
couple of thousand rows and could not retrieve them back, so i wanted to
know if postgres had some way to get it back. Iam just a few days
expereinced in postgres hence iam still discovering its features.
No intention of compa
--- On Sat, 7/12/08, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> What I would appreciate as regards Oracle's flashback
> technology would
> have been a link to a well written review showing the warts
> as well as
> the beauty. I've found that Oracle stuff sounds good
> on paper, and
> turns into a
>
> Please don't put links to copyrighted material on our
> lists.
>
Postgres docs are copyrighted. The oracle docs are free to access just like
the postgres docs. What is the issue?
LewisC
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription
On Sat, Jul 12, 2008 at 3:20 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> On Sat, 2008-07-12 at 09:40 +0100, Dave Page wrote:
>> On Sat, Jul 12, 2008 at 8:56 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>> >
>> > Please don't put links to copyrighted material on our lists.
>>
>> That's an odd thing
On Sat, 2008-07-12 at 09:40 +0100, Dave Page wrote:
> On Sat, Jul 12, 2008 at 8:56 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> >
> > Please don't put links to copyrighted material on our lists.
>
> That's an odd thing to say, given that virtually every link on our
> lists probably points to mate
On Sat, Jul 12, 2008 at 8:56 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> Please don't put links to copyrighted material on our lists.
That's an odd thing to say, given that virtually every link on our
lists probably points to material copyrighted in some way.
--
Dave Page
EnterpriseDB UK: htt
On Fri, 2008-07-11 at 18:56 -0700, Lewis Cunningham wrote:
> In addition to allowing you to read old data, Flashback will allow you
> to rollback to a point in time, including returning a single table to
> a specific state. Flashback database is like PITR without the log
> files.
Like I said: y
http://postgres.enterprisedb.com/forum.do
--- On Fri, 7/11/08, Simon Riggs <[EMAIL PROTECTED]> wrote:
> From: Simon Riggs <[EMAIL PROTECTED]>
> Subject: Re: [SQL] Rollback in Postgres
> To: "Scott Marlowe" <[EMAIL PROTECTED]>
> Cc: "samantha mahindrakar&quo
On Fri, 2008-07-11 at 11:21 -0600, Scott Marlowe wrote:
> rollback after commit
Are you sure?
Personally I don't think its viable. If it really does that it will
would also need to rollback all transactions whose changes depend upon
the earlier transaction. It would also need to track transacti
On Fri, Jul 11, 2008 at 9:43 AM, samantha mahindrakar
<[EMAIL PROTECTED]> wrote:
> Hi all
> This is a very basic question.can we roll back data after we run a
> query.
> I know that a delete within a transaction can be rolled back. But how about
> independent delete queries???
> If i ran a
On Fri, 2008-07-11 at 11:43 -0400, samantha mahindrakar wrote:
> Hi all
> This is a very basic question.can we roll back data after we run a
> query.
> I know that a delete within a transaction can be rolled back. But how
> about independent delete queries???
> If i ran a delete statement
27 matches
Mail list logo
