Re: [SQL] Rollback in Postgres

2008-07-16 Thread Kaare Rasmussen
 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 see fit to add is
 not necessarily going to be on our radar screen in the foreseeable
 future.

I wasn't proposing to add it in 8.4. Just to add it to the TODO. Perhaps 
someone would look at it some point in the future.

-- 

Med venlig hilsen
Kaare Rasmussen, Jasonic

Jasonic Telefon: +45 3816 2582
Nordre Fasanvej 12
2000 Frederiksberg  Email: [EMAIL PROTECTED]

-- 
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql


Re: [SQL] Rollback in Postgres

2008-07-14 Thread Kaare Rasmussen
 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 be 
possible to do a SELECT...AS OF TIMESTAMP.

The idea is of course to be able to retrieve rows that really are deleted, but 
are still on disk as non-vacuumed or vacuumed and not removed completely. And 
it would also take a 2. stage vacuumer to keep the storage within its limits.

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.

-- 

Med venlig hilsen
Kaare Rasmussen, Jasonic

Jasonic Telefon: +45 3816 2582
Nordre Fasanvej 12
2000 Frederiksberg  Email: [EMAIL PROTECTED]

-- 
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql


Re: [SQL] Rollback in Postgres

2008-07-14 Thread Kaare Rasmussen
 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 all time. That's not the case with the 
flashback technology. You put aside some storage space that you don't need 
for something else. When that space is spent, tuples start dropping off the 
edge.

I've talked to people who was very much happy with this feature. Mostly DBA's 
recovering from their own stupid mistakes of course :-)

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. If you plug into Postgres' vacuum it 
would be rather cheap to make, I recon. I wouldn't worry about query speed as 
I guess that the use cases for retrieving already deleted rows don't aren't 
performance dependant.

-- 

Med venlig hilsen
Kaare Rasmussen, Jasonic

Jasonic Telefon: +45 3816 2582
Nordre Fasanvej 12
2000 Frederiksberg  Email: [EMAIL PROTECTED]

-- 
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql


Re: [SQL] Rollback in Postgres

2008-07-14 Thread Kaare Rasmussen
 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 that was 
removed because it made Postgres too slow to use in production?

-- 

Med venlig hilsen
Kaare Rasmussen, Jasonic

Jasonic Telefon: +45 3816 2582
Nordre Fasanvej 12
2000 Frederiksberg  Email: [EMAIL PROTECTED]

-- 
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql


Re: [SQL] Scheduling Jobs In PostgreSQL

2004-11-08 Thread Kaare Rasmussen
 Is it possbile to schedule jobs in postgres?

I believe that the correct answer would be: Yes, it is possible, but No you 
wouldn't want to do that.

A scheduler for PostgreSQL colud be written in Perl, but a much better idea 
would to use cron or another external scheduler.

-- 
Kaare Rasmussen--Linux, spil,--Tlf:3816 2582
Kaki Datatshirts, merchandize  Fax:3816 2501
Nordre Fasanvej 12 Åben 12.00-18.00Email: [EMAIL PROTECTED]
2000 FrederiksbergLørdag 12.00-16.00   Web:  www.suse.dk

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


[SQL] to_number

2003-03-30 Thread Kaare Rasmussen
# SELECT * FROM pg_settings WHERE name LIKE 'lc_%';
name | setting
-+-
 lc_messages | unset
 lc_monetary | C
 lc_numeric  | C
 lc_time | C
(4 rows

SELECT price, to_number(price,'D9)') FROM orderline WHERE sku = 
'01-0082-4';
 price | to_number
---+---
 429,5 |  4295
 429,5 |  4295
 429,5 |  4295
 429,5 |  4295
 429,5 |  4295
 429,5 |  4295
 429,5 |  4295
 429,5 |  4295
 429,5 |  4295
 429,5 |  4295
(10 rows)

How can to_number work with Danish locale?

-- 
Kaare Rasmussen--Linux, spil,--Tlf:3816 2582
Kaki Datatshirts, merchandize  Fax:3816 2501
Howitzvej 75   Åben 12.00-18.00Email: [EMAIL PROTECTED]
2000 FrederiksbergLørdag 12.00-16.00   Web:  www.suse.dk


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org


Re: [SQL] to_number

2003-03-30 Thread Kaare Rasmussen
  How can to_number work with Danish locale?
 It looks like you have C locale instead of Danish one. What happens when
 you change your system locale to Danish?.

Seems to use the settings in postgresql.conf, NOT pg_settings. I don't know 
what they are used for.

So it seems that PostgreSQL can handle one and only one locale setting per 
installation. Hmmm.

-- 
Kaare Rasmussen--Linux, spil,--Tlf:3816 2582
Kaki Datatshirts, merchandize  Fax:3816 2501
Howitzvej 75   Åben 12.00-18.00Email: [EMAIL PROTECTED]
2000 FrederiksbergLørdag 12.00-16.00   Web:  www.suse.dk


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly


Re: [SQL] number of days in a month

2001-05-11 Thread Kaare Rasmussen

  does it exist a date function  to determine the number of days in a
  Select, knowing a specifique date ?

January, 2001: 

select '2001-2-1'::datetime - '2001-1-1'::datetime; 

-- 
Kaare Rasmussen--Linux, spil,--Tlf:3816 2582
Kaki Datatshirts, merchandize  Fax:3816 2501
Howitzvej 75   Åben 14.00-18.00Web:  www.suse.dk
2000 FrederiksbergLørdag 11.00-17.00   Email: [EMAIL PROTECTED]

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



[SQL] PostgreSQL HOWTO

2001-01-18 Thread Kaare Rasmussen

Whoever wrote this is putting the PostgreSQL community in a bad light:

http://www.linux.org/docs/ldp/howto/PostgreSQL-HOWTO-4.html

Maybe someone can change the document, or make the author change it?

-- 
Kaare Rasmussen--Linux, spil,--Tlf:3816 2582
Kaki Datatshirts, merchandize  Fax:3816 2501
Howitzvej 75   ben 14.00-18.00Email: [EMAIL PROTECTED]
2000 FrederiksbergLrdag 11.00-17.00   Web:  www.suse.dk



Re: [SQL] PostgreSQL HOWTO

2001-01-18 Thread Kaare Rasmussen

 I do not see how it puts the Postgres community in a bad light, although I
 do see how the author is a moron.

People think that it's an official PostgreSQL document. It turned up in a 
discussion (PostgreSQL vs. MySQL round 1000) as "the PostgreSQL docs". 

-- 
Kaare Rasmussen--Linux, spil,--Tlf:3816 2582
Kaki Datatshirts, merchandize  Fax:3816 2501
Howitzvej 75   Åben 14.00-18.00Email: [EMAIL PROTECTED]
2000 FrederiksbergLørdag 11.00-17.00   Web:  www.suse.dk



[SQL] 7.1 feature?

2000-12-28 Thread Kaare Rasmussen

I need to do something like this:

SELECT n.name FROM 
(SELECT p.contact_seq AS contact_seq, p.lastname||', '||p.firstname AS name 
FROM person p
UNION 
 SELECT co.name AS name FROM company co) n;

Of course there's more; this is cut from the original select.
But PostgreSQL complains about SELECT (i guess it's the SELECT in the 
subquery)
In the dox I read:

A FROM item can also be a parenthesized sub-SELECT (note that an alias clause 
is required for a sub-SELECT!). This is an extremely handy feature since it's 
the only way to get multiple levels of grouping, aggregation, or sorting in a 
single query. 

Is this a 7.1 feature? Or is my typing wrong?
And will 7.1 support unions in subselects like above?

-- 
Kaare Rasmussen--Linux, spil,--Tlf:3816 2582
Kaki Datatshirts, merchandize  Fax:3816 2501
Howitzvej 75   Åben 14.00-18.00Email: [EMAIL PROTECTED]
2000 FrederiksbergLørdag 11.00-17.00   Web:  www.suse.dk



[SQL] Invoice number

2000-12-21 Thread Kaare Rasmussen

Hi

My, my. It works. How many times have I tried this mailing list with no 
success :-(

I'm wondering how people creates guaranteed sequential numbers - in my case 
for invoice numbers.

- Sequences are not rollback'able.
- It seems overkill to have a table just for this.
- What else?

tia



Re: [SQL] Invoice number

2000-12-21 Thread Kaare Rasmussen

 What do you do on the following scenario:

I don't enter !

 Client 1 is placing an order, gets invoice #1.

Wrong! He gets an order number

 Client 1 changes mind and cancels order.  Invoice #1 is not used.  Invoice
 #2 is.
 Client 3 comes along.  Do they use invoice #1, out of order, or invoice #3?

If Invoice 1 is cancelled for some reason, it is still an invoice. The right 
thing is to produce a credit note to balance off the cancelled invoice. 

For smaller quantities, I believe it is OK just to file the cancelled invoice 
with a clear note that it's been cancelled. But I have a feeling my 
accountant doesn't agree :-)

-- 
Kaare Rasmussen--Linux, spil,--Tlf:3816 2582
Kaki Datatshirts, merchandize  Fax:3816 2501
Howitzvej 75   Åben 14.00-18.00Email: [EMAIL PROTECTED]
2000 FrederiksbergLørdag 11.00-17.00   Web:  www.suse.dk