rusebor

Interestingly that linux kernel does not have caps for cpu in terms of instructions.

quote "don't give advice unless asked"

it is not you! i think most of the people feel the same way. at least i do

i suspect that in your case a review is mandatory as well as fixing its comments.

from my perspective a review should be optional. You should ask for a review if needed and ask whomever you consider worth making it. You should be responsible for your code and have authority to change it without any PRs.

> 2) languages such as PL/SQL are much poorer than any modern programming language

true but it is for a reason. For example you can replace/upgrade any piece of code on the running system transactionally. But in a modern programming language, let's say Java, it is not possible.

Should PL/SQL be similar to a "modern programming language" it would lose a lot of its perks.

Generally speaking PL/SQL is not much different from DDL like "create table ...". The latter is similar code describing "business logic"

many say that git has an intuitive/concise data model. But it seems that even git team itself has not quite got it.

Looking at one of the latest changes [1] in which a _new_ merge strategy (ort) was introduced and made default one can ask how is it possible that so fundamental change happened 15 years after git was created?

Maybe the model is not so simple as it wants to seem.

[1] https://github.blog/changelog/2022-09-12-merge-commits-now-c...

have been wondering for a while why HFTs exist when exchanges have holidays and trading hours [1]?

doesn't the sub-milisecond speed contradict to the several hours pause in trading?

wouldn't be possible to impose some kind of a delay (say an hour) on all participants?

[1] https://www.nyse.com/markets/hours-calendars

Erlang

before the change

CREATE TABLE the_table (was_char CHAR);

CREATE VIEW table_read_api AS SELECT was_char FROM the_table;

a client consumes data via:

select was_char from table_read_api;

after the change

alter table the_table modify was_char int;

alter table the_table rename column was_char to now_int;

CREATE VIEW table_read_api AS SELECT TO_CHAR(now_int) as was_char FROM the_table;

the client uses the same query

select was_char from table_read_api;

the type of the column has not changed

it is still a char

only "internal implementation" is changed

a view would allow you to change a field's type.

something like this

CREATE VIEW table_read_api AS SELECT TO_CHAR(now_int) as was_char FROM the_table;

not sure that the view is an internal structure because it will be exposed via API as it is.

SQL allows to swap the database at least if no specific SQL features are used.

what if we put the table behind a view? would it be count as a communication via API?

> which is going on the opposite direction as you would expect.

It looks like a bug which should be fixed. Git should create a merge commit when it sees that "the direction" changes.