| From: | Andreas Karlsson <andreas(at)proxel(dot)se> |
|---|---|
| To: | Jeremy Morton <postgres(at)game-point(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Support for DATETIMEOFFSET |
| Date: | 2020-04-17 09:57:12 |
| Message-ID: | 794695b8-00a9-2944-7f13-5d4cc1f2dd7f@proxel.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 4/17/20 11:00 AM, Jeremy Morton wrote:
>> I am not saying there isn't a use case for something like
>> datetimeoffset, I think that there is. For example in some kind of
>
> Surely the fact that you'll lose data if you try to store a common .NET
> datatype with any kind of ORM (eg. EF, which is pretty popular) right
> now, using "the world's most advanced open source relational database",
> is reason enough to support it?
No, because if PostgreSQL started adding supports for all data types in
all standard libraries of all programming languages it would become
virtually unusable. What if PostgreSQL shipped with 8 or 9 different
timestamp types? How would the users be able to pick which one to use?
It is better to have a few types which cover the use cases of most users
and then let extension authors add more specialized types.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2020-04-17 11:01:46 | pgstattuple: Have pgstattuple_approx accept TOAST tables |
| Previous Message | Fujii Masao | 2020-04-17 09:39:21 | Re: documenting the backup manifest file format |