| From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
|---|---|
| To: | Yury Bokhoncovich <byg(at)center-f1(dot)ru> |
| Cc: | <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: missed features and unhappy changes when pg 7.1->7.2 |
| Date: | 2002-09-20 14:34:44 |
| Message-ID: | 20020920072850.H40130-100000@megazone23.bigpanda.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Fri, 20 Sep 2002, Yury Bokhoncovich wrote:
> Maybe I missed something but what are reasons to change behaviour in 7.2
> in comparison with 7.1?
> I mean that early PG just truncated the rest (tail) of extra long string
> (i.e. where len(string)>char(this attr) but insert the head. Now inserting
> fails. Is it tunable somewhere in GUC so I could revert to old behaviour?
Not currently. This was a push to become more complient with sql's
desired handling for strings like that.
> And yet, what is the Right Way to deal with timestamp?
> Now I'm using Thomas's recipe \"timestamp\" but it loooks wierd and bad.
For most of the uses of timestamp(), you probably should now be using
either a timestamp literal (timestamp '...') or a cast (cast(... as
timestamp). The reason this changed was again an sql compatibility issue,
timestamp(n) in sql terms is a type with a particular precision.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-09-20 14:37:22 | Re: missed features and unhappy changes when pg 7.1->7.2 |
| Previous Message | Jeff Eckermann | 2002-09-20 14:21:50 | Re: REGEXP: returning match? |