Re: Override system-defined cast?

From: Peter <peter(at)greatnowhere(dot)com>
To: David Fetter <david(at)fetter(dot)org>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Override system-defined cast?
Date: 2006-10-13 06:10:38
Message-ID: 452F2DDE.5070305@greatnowhere.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


>> Is there any way I can override system-defined casts?
>>
>> Tried
>>
>> create cast (varchar as timestamptz) with function
>> user_timestamptz(varchar) ;
>>
>> and got
>>
>> ERROR: cast from type pg_catalog.varchar to type timestamptz already exists
>>
>> DROP CAST does not work:
>>
>> ERROR: cannot drop cast from character varying to timestamp with time
>> zone because it is required by the database system
>>
>> (or are my permissions insufficient?)
>>
>> Basically my problem is converting '' (empty string) to
>> NULL::timestampz, and built-in cast cannot convert blank string to
>> timestamptz. Maybe I'm wondering up the wrong alley with casts?
>>
>> One solution I can see is create user-defined type (which would be the
>> same timestamptz) and define varchar->mytype cast, but that will require
>> rather extensive changes to database schema. Plus, our user-interface
>> currently relies on PG datatypes to format input/output data.
>>
>> Any suggestions?
>>
>
> How about a function with a CASE statement in it?
>
>

That wouldn't be The Way of The Dragon ;)

Most of my SQL statements are dynamically generated. Using CASE means I
will have to check target field datatype, and apply CASE whenever it's
timestamptz. Rather messy.

I tried defining my own base type using timestamptz _in and _out
functions, and it seems to work. Had to re-create half of my database
objects due to dependencies, but now that it's done it seems to work
quite well.

Peter

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Albe Laurenz 2006-10-13 07:23:29 Re: looping through query to update column
Previous Message Ivan Zolotukhin 2006-10-13 05:37:20 Re: Fwd: pg_dump VS alter database ... set search_path ...