Re: Creating redwood datestyle in Postgres 12

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
>>
>>