On Wed, Nov 04, 2009 at 12:41:25PM +0330, shahrzad khorrami wrote:
> Column | Type |
> id | integer | not null default
> f1 | character varying(32) |
> f3 | character varying(32) |
> f4 | character varying(32) |
> f5 | character varying(32) |
> f6 | character varying(32) |
> f7 | character varying(32) |
> f8 | character varying(32) |
> f9 | character varying(32) |
> f11 | character varying(32) |
> f12 | character varying(32) |
> f13 | character varying(32) |
> f14 | character varying(32) |
> f2 | character varying(32) |
> f10 | character varying(32) |
I'd highly recommend giving these columns more human readable names and
appropriate data types. You suggest that f2 is a time and f10 a date,
with their values being "082234" and "121109" respectively. PG will be
able to help you *much* more if you do this. For example, I'd combine
those two fields into a "timestamp" field[1] and I'd guess its value would
be:
2009-11-12 08:22:34
there's a function called to_timestamp[2] that would help a lot here.
For example, you can run:
ALTER TABLE test ADD COLUMN datetime TIMESTAMP;
to add in a new column called "datetime" (I'm sure you can think of a
better name, for example creationtime or entrydate or similar). Then
you need to give it values:
UPDATE test SET datetime = to_timestamp(f10||f2,'ddmmyyhh24miss');
This will combine the opaque (to the database) text fields into
something that will give PG something to get its hands on. I'd
similarly store the numeric fields in appropriate types (i.e. numeric,
integer or float8). Note that || appends two strings (i.e. text or
your varchar fields) onto the the end of each other and its behavior is
documented in [3].
Once you've done that we'll have more of a chance of helping you! :)
--
Sam http://samason.me.uk/
[1] http://www.postgresql.org/docs/current/static/datatype-datetime.html
[2] http://www.postgresql.org/docs/current/static/functions-formatting.html
[3] http://www.postgresql.org/docs/current/static/functions-string.html
