Feeds:
Posts
Comments

Having not played around with CSS frameworks before I found this one very appealing.

Really, it accomplishes something I used to spend an inordinate time doing: creating a simple set of CSS rules that bring all browsers to a common level playing field.

My favorite aspect is the concept of 24 columns easily split into classes span-x where x is a number of columns.

Check out blueprintcss.com for more information.

This allows multiple data stores but without rewriting all sql queries. Note you have to create two functions, one to accept dates, the other to accept times.

Specifically the 4D SQL function DATE_TO_CHAR. Luckily PostgreSQL has the equivalent as a formatting function to_char.

For business reasons it’s not practical to replace all instances of DATE_TO_CHAR to to_char.

Solution

Create a function in the postgresql data base that maps the DATE_TO_CHAR function to to_char. Luckily the formatting options I need are available.

Now SELECT DATE_TO_CHAR(DateField1, "YYYY-MM-DD") FROM Table1 will return the correct value regardless of the database queried. It’s important to note this works great for getting integer values from dates and casting as date objects. If queries rely on returning non-iso formatting your mileage may vary.

-- Function: date_to_char(date, text)
CREATE OR REPLACE FUNCTION date_to_char(date, text)
  RETURNS text AS
$BODY$
  DECLARE
  BEGIN
       RETURN to_char($1,$2)::text;
  END;
  $BODY$
  LANGUAGE plpgsql VOLATILE
  COST 100;
ALTER FUNCTION date_to_char(date, text) OWNER TO postgres;
-- Function: date_to_char(time without time zone, text)
CREATE OR REPLACE FUNCTION date_to_char(time without time zone, text)
  RETURNS text AS
$BODY$
  DECLARE
  BEGIN
       RETURN to_char($1,$2)::text;
  END;
  $BODY$
  LANGUAGE plpgsql VOLATILE
  COST 100;
ALTER FUNCTION date_to_char(time without time zone, text) OWNER TO postgres;

Recently while importing a new physical schema from PostgreSQL 8.4 into Oracle Data Integrator(ODI) via JDBC driver all of the tables were reversing into the model without data types defined for text, double precision, smallint, integer and boolean.

If one or two fields are missing it’s easy enough to set the data type manually for the column, but for a whole mess of tables and thousands of fields it’s unrealistic.

The solution is to define the proper data types using the physical architecture tab with PostgreSQL internal names for the data types. Even though by default there is one for integer, looking at the data type definitions smallint maps to int2, integer maps to int4, double precision maps to float8, boolean maps to bool.

Using these aliases which are used internally by PostgreSQL for historical reasons in the ODI Physical Architecture will fix the missing data types during the reverse process.

Design a site like this with WordPress.com
Get started