From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Karina Guardado <karina(dot)guardado(at)ues(dot)edu(dot)sv> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: problems with function pg_catalog.btrim(date) |
Date: | 2009-09-03 01:10:59 |
Message-ID: | 4234.1251940259@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Karina Guardado <karina(dot)guardado(at)ues(dot)edu(dot)sv> writes:
> I hope some one can help me, I have created the following function but
> I always get the error that there is not function
> pg_catalog.btrim(date), in the version postgresql 8.1 it worked but now
> it does not so I don't know if it is related with a configuration
> problem of the postgresql or somethin in the function code :
What in the world do you imagine that trim() on a date would be good
for? Just get rid of the "date(trim())" lines.
I think this accidentally failed to fail pre-8.3 because there was an
implicit cast from date to text, so it would convert the date to text,
remove leading/trailing blanks (which there wouldn't be any of), and
then convert the string back to date. An expensive and pointless no-op.
This bit is going to fail too:
> dia :=CAST(substring(hoy from 1 for 2) AS integer );
> nmes := CAST (substring(hoy from 4 for 2) AS integer);
> anho := CAST(substring(hoy from 7 for 4) AS integer );
While that sort of worked in 8.1, it was always bad coding style and
fragile as can be --- think what will happen if the user changes the
datestyle setting. Replace this with extract(day ... ) and so forth,
and you'll have code that is safer, faster, and more standard/portable.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2009-09-03 01:11:19 | Re: Add a serial column to a table based on a sort clause |
Previous Message | shane_china | 2009-09-02 23:58:56 | Re: install postgis in linux server without desktop |