Pull to refresh
109
0.5
Send message

У него же челлендж был, упомянуть слово всуе; закрывает :).

Наверное, принц любитель или Mass Effect-а, или Halo, или того и другого.

А гит тут причём? Понятно, что всё лежит в системе контроля версий, но мне же накатить изменение надо, не уронив прод, как это делать? Простой create or replace не работает.

Ох уж эти практически всегда. Мне от этих ваших «практически всегда» ни тепло, ни холодно, для меня это — «хрен знает, что там». В отличие от, которое неоднозначностей не допускает.

Что за бред вы тут пишете. То есть, если я пишу класс работы с матрицами, мне вместо ясного и понятного Matrix4x4 надо выдумывать MatrixFourByFour, так? А то цифры что-то рябят.

Это очень опасно из-за полиморфизма. Совершенно в неожиданный момент можете получить SQL Error [42725]: ERROR: function ... is not unique.

Так я же об этом как раз и говорю. Я хотел просто добавить параметр в функцию, а вместо этого молча создалась новая (несмотря на фразу or replace — то есть, я явно выразил намерение заменить функцию). И я об этом узнаю только тогда, когда где-то запрос упадёт. Очень не интуитивно это.

Во избежании таких проблем вызов функций без указаний всех параметров в проектах категорически запрещается.

Это требование делает параметры по умолчанию совершенно бесполезными.

В таких редких и частных случаях никто не мешает её действительно убить в скрипте её же создания.

Я же говорю, что мешает. PostgreSQL не даст мне просто сделать drop function и создать новую, если она в представлении используется. Придётся сначала запомнить код представления, сделать drop view, сделать drop function, сделать create function, сделать create view по сохранённому ранее DDL. Причём сохранить DDL надо всех объектов рекурсивно, так как это представление может использоваться в другом представлении, а то — в следующем. Это решаемая задача, но огромный геморрой. А удалять функцию каскадно нельзя, потому что кто потом восстановит удалённые по каскаду представления?

Пользуйтесь макроопределениями вместо них.

Что ещё за макроопределения, впервые слышу о таком?

Не вижу ни одного преимущества в использовании VIEW, кроме как для внешних систем.

Дело в том, что система потихоньку мигрирует с Oracle, а там представления играют существенную роль. И нельзя просто так от них избавиться.

Пожалуйста, приведите пример такой зависимости.

К сожалению, иногда PostgreSQL ругается на функции, используемые в других функциях, а иногда нет. Я так и не смог понять, при каких условиях это происходит, но крови это мне попило изрядно, поэтому мне проще считать, что функция, использующая другую функцию, жёстко от неё зависит. Но там и код функций много сложнее вашего синтетического примера. Но ОК, допустим, это меня память подводит и PostgreSQL на это не ругается. Всё равно остаются представления.

Но в этом случае все равно необходимо удалять и заново создавать VIEW, так как она будет вызывать функцию с другим набором параметров.

Не будет. Я хочу добавить в функцию новый параметр со значением по умолчанию (флаг включения отладочного вывода, к примеру), на вызов функции в существующих местах это не влияет абсолютно никак. Но я не могу этого сделать. Создав новую функцию с добавочным дефолтным параметром, я сразу же нарушу вызовы во всех местах, так они вызываемая функция станет не уникальной. В общем, после Oracle всё это выглядит прямо скажем, не очень.

А вот удалять старую функцию совершенно не обязательно.

Функция внутренняя, извне её никто не вызывает. Она сугубо наша. Не вижу ни одной причины, почему я её должен оставлять, если она никем не используется, а вот пониманию мешает весьма сильно (а ещё её по ошибке может кто-то из разработчиков начать использовать вместо правильной).

А уж PR с VIEW на VIEW точно не пропущу.

В нашей системе представление на представлении — норма жизни, поэтому без этого никак.

Можете более развернуто объяснить о каких зависимостях Вы ведете речь?

Вроде понятно написал, что от функции может зависеть другая функция (внутри вызывает нашу) и/или представление (внутри представления стоит вызов функции). Меняете тип параметра или даже просто добавляете новый — это создаст вам новую функцию, а не заменит старую. Для именно замены старую придётся удалять через drop function, а если она используется в представлении, то просто так PostgreSQl вам удалить её не даст. Удалите сначала представление, а потом свою функцию. И всё это может по рекурсии как снежный ком накапливаться. Ну или cascade пропишите у дропа, но тогда вы даже не узнаете, сколько системы у вас улетит в трубу при дропе.

CREATE OR REPLACE FUNCTION или CREATE OR REPLACE PROCEDURE. А как еще?

В PostgreSQL не сработает, если типы / количество параметров у функции / процедуры поменялись. Придётся дропать. А это тоже боль, так как зачастую другие объекты от них зависят (другие функции / процедуры, представления), поэтому дропать надо каскадно, а потом как-то восстанавливать дропнутое обратно.

1024 битный указатель?

С чего вы взяли, что это именно указатель должен быть? В мире полно задач, где встречаются ОГРОМНЫЕ числа и есть вполне понятное желание запихнуть их в регистр и что-то с ними посчитать (вместо того, чтобы мудохаться с длинной арифметикой). Так что не удивлюсь, если когда-нибудь и такие появятся.

После «Даже вот в таких мелочах как i8, i16, i32, i64, i128 - почему нельзя было просто оставить byte, short, int, long, wide ?» дальше можно не читать, всё и так ясно — вы просто не с той ноги встали, вот и бурчите.

Касательно вышеупомянутого примера — парни из Rust молодцы и сделали всё правильно: понятно, предсказуемо, логично и расширяемо. Завтра возникнет необходимость в 256-, 512-, 1024-х битных переменных и вы будете выдумывать очередные superwide, duperlongest, absurdlylongwide и иже с ними, тогда как в Rust уже всё продумали за вас.

относительно быстро устранит большинство ошибок диапазона

Ну и что же не устранили до сих пор? Или каков там порядок вашего "относительно"?

Страуструп словно специально не замечает, что проблема не в отсутствии механизмов, а в неадекватных параметрах по умолчанию. Прошли те времена, когда все можно было держать в голове.

Это просто у вас нет статистики, что было бы, если бы там с таким же подходом писали не на JavaScript. Практика-практикой, но доброе слово и пистолет практики и помощь от компилятора делают больше, чем просто доброе слово практики.

Проще тогда в самом проекте, если он такой важный, перед мерджем PR проверять, что его известные зависимости не ломаются. Насколько я знаю, компилятор Rust-а, например, пересобирает все пакеты с crates.io, чтобы убедиться в отсутствии регрессий. Ну и далее вместе с мейнтейнерами зависимостей решать, что делать.

11 февраля 2016 года главная цель проекта была достигнута: обсерватория впервые зафиксировала гравитационные волны от столкновения двух чёрных дыр с массами примерно в 30 солнечных каждая. Само это столкновение произошло в октябре 2015 года.

Это как вообще? Упомянутые чёрные дыры менее, чем в световом годе от нас находятся? Или гравитационные волны быстрее света бегут?

Может быть, всё же 11 февраля 2016 года наконец-то обработали все данные и сделали вывод о том, что наблюдалось слияние двух чёрных дыр, а не что-то ещё?

Причём исследовали выживаемость спор грибов — то есть, таких штук, которые специально приспособлены для выживания в неблагоприятных условиях, чтобы потом в благоприятных (!) дать новую жизнь. Это совсем не означает, что сам гриб выживет в тех же условиях — насколько я понял, споры выращивали в гриб уже в нормальных «земных».

Это значит, что просто ветка переместилась на новую историю (так как ветка — это просто указатель на голову). Старая история никуда не делась (ну, до первого git gc), вы можете отыскать её в удалённом репозитории и восстановить при желании.

Как будто бы в гите вы изменяете существующую историю. Точно так же создаёте абсолютно новую.

Эм, меняете фазу с public обратно на draft и спокойно правите / ребейзите коммиты. Потом пушите обратно. Или я чего-то не понял?

Information

Rating
1,534-th
Location
Магнитогорск, Челябинская обл., Россия
Registered
Activity