views:

470

answers:

2

I have a single database field that contains a start date, end date, and exclusions in the form

available DD/MONTH/YYYY [to DD/MONTH/YYYY]?[, exclude WORD [, WORD]*]?

Meaning it always starts with "available DD/MONTH/YYYY", optionally has a single "to DD/MONTH/YYYY", and optionally has an exclude clause that is a comma separated list of strings. Think regular expression meanings for + , *, and ?

I have been tasked with extracting the data out so we will now have a "startdate" column, "enddate" column, and a new table that will contain the exclusions. It will need to fill the startdate and enddate columns with the values parsed from the availability string. It will also need to create multiple records in the new exclusion table, one for each of the comma separate values after the 'exclude' key word in the availability string.

Is this a migration I can do in SQL only (postgres 8.4)?

This is against postgres 8.4.

Update: With the help of a co-worker we now have a sql script that has as it's results sql to perform the insert statements based on the parsing of the exclusions. It uses a bunch of case statements and string manipulation within the sql to generate the results. I then send the output to a file and execute that file to perform the inserts. I am doing the same for the start and end date columns.

It's not 100% sql, but a simple .bat or .sh file that runs the first .sql file, then the generated one is all that is needed to get it to go.

Thanks for the input.

+1  A: 

why single SQL?

Write simple script in Ruby/Python/Basic to read data from the source, parse it, and put into destination database.

Or it is so big?

Igor Shubovych
Good question, and I may end up doing it that way. The current convention here is to create a SQL script that will be run at install time. Because it will require migration of production data I'd like to stick to convention simply because then there is less chance of getting things messed up, but if I have to introduce a special process for this one migration then I will.
digitaljoel
+1  A: 

You can probably do that with a combination of the regexp functions ( and the to_date() or to_timestamp() functions.

But it may be easier to just mangle the text in a function in say pl/perl. That'll get you access to the full manipulation functions in perl, while keeping the work inside the database as seems to be your specification.

Magnus Hagander