Re: Creating redwood datestyle in Postgres 12

From: Tim <timfosho(at)gmail(dot)com>
To: jim schmidt <txherper(at)gmail(dot)com>
Cc: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, legrand legrand <legrand_legrand(at)hotmail(dot)com>, posgres support <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Creating redwood datestyle in Postgres 12
Date: 2021-03-27 02:15:31
Message-ID: CAKhLO5gJeovfOygGfRMDEBAYqWK-3L9EAx3BahGnL=jDJWGOKg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Jim, all that is true but when it comes to application code you never know
what it'll be doing with the date. It can be getting casted, used as a
string, inserted as a string and casted. I doubt the devs even know all the
ways. Ive had to deal with switching from ISO to SQL and even that was
painful and required retroactive data fixes and code patches

On Fri, Mar 26, 2021 at 8:19 PM jim schmidt <txherper(at)gmail(dot)com> wrote:

> I am confused, don't dates that traverse the network get transported in
> canonical format and the client format the date?
>
>
> This obviously is not the case when one applies a to_char function but in
> jdbc the canonical format is translated to a java.sql.Date and formatting
> is a client responsibility. Same applies with pro*c.
>
> I would think if the formatting is done by the client that a server patch
> would do nothing.
>
> Also creating to_char views and programmatically is a trivial operation.
>
> How are clients getting strings from oracle dates without a to_char?
>
>
>
> On Fri, Mar 26, 2021, 3:21 PM Tim <timfosho(at)gmail(dot)com> wrote:
>
>> Yes anything that involves management at a table level is not practical
>> due to the size of our database and limited amount of resources (me). I was
>> not aware of the orafce extension and will keep it in mind.
>>
>> Tom, we currently are on EDB AS 12 but its becoming cost inefficient to
>> stay with EDB due to our scale, since their pricing reflects the size of
>> the production VMs that are used. So while this migration might be a pain
>> from the application side.. long run it would be cheaper.
>>
>> Jonah, I'm assuming a patch would only apply per Postgres version... so
>> any future PG version upgrade would require a new patch? While I'm sure
>> technically its doable.. long run it would be more practical to just move
>> away from these cursed Oracle dates.
>>
>> Thanks for your help everyone!
>>
>> On Fri, Mar 26, 2021 at 1:27 PM Jonah H. Harris <jonah(dot)harris(at)gmail(dot)com>
>> wrote:
>>
>>> On Fri, Mar 26, 2021 at 12:55 PM legrand legrand <
>>> legrand_legrand(at)hotmail(dot)com> wrote:
>>>
>>>> Isn’t this alteady proposed in extension oracfe ?
>>>> https://github.com/orafce/orafce
>>>
>>>
>>> I don't believe this can be done implicitly, across the entire server,
>>> by default via an extension. It could be done on a table-by-table or
>>> view-level basis using custom formatting (via a function), which it seems
>>> Tim would like to avoid.
>>>
>>> --
>>> Jonah H. Harris
>>>
>>>

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message legrand legrand 2021-03-27 07:50:45 Re: Password encryption in oracle_fdw extention
Previous Message jim schmidt 2021-03-27 00:19:46 Re: Creating redwood datestyle in Postgres 12