LINUX.ORG.RU

PostgreSQL 14

 , ,


3

2

Спустя год разработки вышла новая стабильная версия реляционной СУБД PostgreSQL под номером 14.

PostgreSQL 14 содержит множество новых функций и улучшений, в том числе:

  • Хранимые процедуры теперь могут возвращать данные через параметры OUT.

  • Реализованы стандартные параметры SQL SEARCH и CYCLE для общих табличных выражений.

  • Теперь индексирование можно применять к любому типу данных, для которого это имеет смысл, а не только к массивам. Для типов jsonb и hstore добавлены операторы индексации.

  • Типы диапазонов расширены за счет добавления нескольких диапазонов, что позволяет отображать несмежные диапазоны данных.

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

  • Обновления индекса B-дерева управляются более эффективно, уменьшая раздувание индекса.

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

  • Теперь по выражениям можно собирать расширенную статистику, что позволяет лучше планировать результаты для сложных запросов.

  • Библиотека libpq теперь имеет возможность конвейерной обработки нескольких запросов, что может повысить пропускную способность соединений с высокой задержкой.

>>> Подробности



Проверено: hobbit ()
Последнее исправление: sudopacman (всего исправлений: 8)

Ответ на: комментарий от anonymous

Ну а ты попробуй на FB покрутить базу на пару десятков гигабайт

Почти полтерабайта на 100 соединений еще в древней версии FB v2.5 легко, что я делал ни таг?

anonymous
()
Ответ на: комментарий от vitalif

А что дадут пакеты?

В Оракле они дают: отсутсвие каскадных зависимостей и ненужных компиляций.

anonymous
()
Ответ на: комментарий от Dumppper001
-Кто лучше: армяне или грузины?
-Конечно, армяне лучше.
-А чем они лучше?
-Чем грузины.
LongLiveUbuntu ★★★★★
()

Не нужно, есть MariaDB.

anonymous
()
Ответ на: комментарий от iZEN

А что за ниша у FB?

Вот по мне как встроенная SQLite проще и удобнее. Что в лазарусе что в кутях что в питоне «быстрый старт» с SQLite легко, а с FB какие то телодвижения нужны… С FB 2.5 дак вообще тяжко, хоть 3 индексы автоматом генерировать научился, в то чувствовал себя как в 2000 год попал…

Как сетевая опять удобнее и проще юзать mysql

Ну и нафига оно такое нужно?

anonymous
()
Ответ на: комментарий от Partisan

https://www.datanyze.com/market-share/databases--272

Что показывается по этой ссылке?

По этой ссылке Oracle DB представлена 4-мя, Карл, пунктами (5) Oracle Database (RDBMS) - 5,38%, (10) Oracle Database - 2,22%, (13) Oracle 11g - 1,54%, (16) Oracle 12c - 1,21%. Суммарный % - 10,35%

Интересно, а почему вы таком случае они забыли про Oracle DB 21c, 19c, 18c, 10g, 9i, 8i, XE разных версий?

Ведрдикт - это ни о чем. Не надо такие «доказательства» предоставлять в дальнейшем.

anonymous
()
Ответ на: комментарий от anonymous

Как там с decimal numbers?

А что вы сразу с козырей заходите? :)

anonymous
()
Ответ на: комментарий от iZEN

есть что-то лучше чем Oracle RDBMS?

Посмотри Embarcadero InterBase 2020.

Игорёк, у меня 2 вопроса:

  1. Зачем на аватарке меняшь свой гендер?
  2. Какую школу клоунов ты заканчивал, чтобы давать такие советы?

И расскажи нам, пожалуйста, как в InterBase 2020 реализованы такие банальные для Oracle вещи как EM, AWR, ASH, RAC, Partitioning, Mat.View, Multitenant, In-Memory, Machine Larning for SQL & R,Spatial, Graph, e.t.c
Если что-то и есть из перечисленного в IB, то поясни в чем преимущества того что есть в IB, пере Oracle-овыми механизмами, если сможешь, конечно - чукча читатель, а не писатель, аднака :).

anonymous
()
Ответ на: комментарий от anonymous

И расскажи нам, пожалуйста

Тебе нужно — ты и рассказывай, гендерный фашист.

iZEN ★★★★★
()
Ответ на: комментарий от anonymous

не нужно :) деньги я храню в копейках, а не в рублях :) подобным образом поступай с decimal и ты :)

anonymous
()
Ответ на: комментарий от anonymous

подобным образом поступай с decimal и ты :)

Прямо Forth-ом повеяло. Там это практически официальный подход по работе с дробями. Зато эффективно (наверное).

hobbit ★★★★★
()
Ответ на: комментарий от x-signal

Есть ли смысл переходить с MariaDB на неё?

Пока PostgreSQL все еще использует эту жуть с VACUUM и не оптимально хранит данные на диске (из-за чего рождаются разные костыли, типа HOT/WARM), то нет: https://habr.com/ru/company/devconf/blog/353682/

X-Pilot ★★★★★
()
Ответ на: комментарий от X-Pilot

Это не «неоптимальное хранение данных на диске». Это дизайнерское решение, которое позволяет иметь сложные типы данных и поддерживать их согласованно по всему стеку. И у такого решения есть своя цена.

Вообще, та история с Убером — это сплошная «рукалицо» для тех, кто в теме разбирается. В первую очередь в том отношении, что Убер не потрудился нанять людей, которые в теме разбираются. Разбираться в теме, значит, знать, что у каждой БД под капотом и для каких типов нагрузок хорошо то или другое. И что Уберу такое позорище не просто сошло с рук, а еще и PG в негативном свете выставили («они хайпуют, а мы повелись»), говорит о состоянии всей единороговой индустрии в целом. Они разбазаривают деньги инвесторов, что и самому Уберу неоднократно потом вменялось.

Проблема в том, что БД как абстракция является очень «текучей». Чтобы добиться от неё желаемых результатов, нужно хорошо знать и как она внутри устроена (по всему стеку от взаимодействия с железом до взаимодействия с клиентским ПО), и как она ведет себя в специфичных условиях. Например, тот же vaccuum в PG — амортизированный О(1), к тому же еще и асинхронный. Т.е. задержки высвобождения места могут быть астрономическими по меркам приложения. Но, нет. БД выбирают в лучшем случае по отзывам других людей, а не по результатам собственных бенчмарков и анализа архитектуры. Эти другие люди бенчмарков тоже не делали. И Убер их не делал. Точнее, он их стал делать уже в продакшене. Вот в чем проблема и Убера, и всех остальных, таких же особенных.

Мораль. Знайте свою БД. Это — залог успеха.

aist1 ★★★
()
Ответ на: комментарий от aist1

И что Уберу такое позорище не просто сошло с рук, а еще и PG в негативном свете выставили

Скорее, в негативном свете его выставило само коммьюнити: сами-то разработчики признали, что есть проблемы, а вот все остальные только и говорили, что «какой Uber позорный».

X-Pilot ★★★★★
()
Ответ на: комментарий от X-Pilot

Ну, Убер попытался выправить ситуацию в своей песочнице и даже свою БД стал клепать по образу и подобию Spanner/F1. Мол, мы всё можем, когда и если захотим. И сообществу PG тоже было полезно высокопрофильную критику послушать, а то зазвездились. Разумеется, они никому ничего не должны. Но если это понимать буквально, можно со временем обнаружить себя в интересном положении. Так что я, как пользователь и апологет PG, был доволен сложившейся ситуацией.

Но, в целом, от всей этой истории было легкое ощущение сюра, культурного шока и протрескивания шаблона. Попробуем заменить Убер на Гугл, и станет понятно. Такое (my->pg->my->...) может произойти в местном кружке занимательного программирования, где действие обычно довлеет над пониманием, но не в многомиллиарднном бизнесе, построенном над всей этой цифровой инфраструктурой.

Мораль всей этой истории в том, что и MySQL, и Postgres в своих ванильных вариантах не масштабируются на потребности единорогов. И их нужно еще пилить, и пилить, и пилить. Что и делается, тихо и незаметно. И эта работа — еще на долго.

В сухом остатке, мало кто заметил, что во всей этой истории больше всего был обосран Оракл. Его отовсюду выкидывают, предпочитая инвестировать в развитие своих домашних СУБД покупке лицензий этой, по отзывам, на всё способной СУБД. Это какую безумную ценовую политику надо иметь, чтобы миллиардные бизнесы шли на такое...

aist1 ★★★
()
Ответ на: комментарий от aist1

Его отовсюду выкидывают, предпочитая инвестировать в развитие своих

?! Кто эти все кроме Амазона (который пять лет на это потратил).

anonymous
()

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

anonymous
()
Ответ на: комментарий от anonymous

Да, согласен. Звучит вызывающе, на грани 4.2 (или даже за).

Есть куча проектов, где Оракл изначально был не нужен, но его выбрали или из-за того, что «еще никого не уволили за то, что он выбрал Оракл», или его втюхали ушлые консультанты, и просто разработчики выбрали то, что умели. А потом все забыли, зачем его выбрали.

Вот эта ниша и есть — еда для PG. По ряду причин компании не афишируют свои планы миграции, но вот настроения рядовых разработчиков в Сети вполне показательны: не использовать Оракл там, где в этом нет необходимости.

Что касается Amazon & Google (и теперь еще и Uber), то да, они способны свою домашнюю СУБД поднять и тянуть, для внутренних нужд. Само по себе для Оракла это проблемы в текущем моменте не составляет, просто это высвечивает потенциальную фундаментальную проблему в будущем. Патентная база, которая огораживает Оракл, постепенно протухает. А вместе с нею протухает и их монополия. С какого-то момента открытые СУБД дозреют до состояния, когда станут инструментом выбора даже во многих случаях, в которых сейчас «однозначно, Оракл».

Ну и о фактическом вытеснении Оракл можно косвенно судить по тому количеству различных коммерческих СУБД, которые сейчас массово появляются. Денюжка там крутится, и весьма немаленькая.

aist1 ★★★
()
Ответ на: комментарий от anonymous

Отправляйте пожелания разработчикам PostgreSQL, вместо тог, чтобы ныть тут. И обосновывайте, зачем это нужно. Вот здесь вы вместо обоснования написали «пусть лучше». Что лучше - неизвестно. Мне не понадобилось, и я не представляю, зачем нужно

Partisan ★★★★
()
Ответ на: комментарий от Partisan

Так с постгрей проблем нет. Знал бы ты что мне приходилось городить на PL/PGSQL. Генерация анонимной функции это самый лайток был.

anonymous
()
Ответ на: комментарий от anonymous

Не знаю, и разработчики PostgreSQL наверно не знают. Мне приходилось программировать процедуры для PostgreSQL, но дл чего нужны анонимные функции - не представляю. Возможно, то, что вы хотите делать анонимными функциями, можно сделать с аомощью CTE. В общем, хотите чтоб были анонимные функции - пошилите разработчикам предложенин с примером: что есть без анонимной функции и что улучшится, если её добавить.

Partisan ★★★★
()
Ответ на: комментарий от aist1

Естественно. К лицензии на Оракл нужен еще и дба. А пострге любой программер, ну судя по лору, - знатный одмин.

anonymous
()
Ответ на: комментарий от no-such-file

> или пару тысяч одновременных соединений

Вот зря ты так, в постгресе с этим туго.

:) Ничего страшного. Всё равно в базе НЕ ДОЛЖНО быть столько соединений. Плюс, какой-никакой пул нужен для режима «быстро открыл конекшн, считал, закрыл».

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

matumba ★★★★★
()
Ответ на: комментарий от matumba

Всё равно в базе НЕ ДОЛЖНО быть столько соединений

Это почему?

no-such-file ★★★★★
()
Ответ на: комментарий от anonymous

А пострге любой программер, ну судя по лору, - знатный одмин.

Вот ты смеешься, а это на самом деле здравое положение вещей. Программист должен знать, как внутри работает БД. Он должен знать и характеристики её эксплуатации. Оракл и прочие закрытые БД — «черные ящики», специально закрытые от программиста. Специально обученные шаманы опытным путем постигают их внутреннюю магию. Проблема в том, что DBA в целом — не программисты, БД видят примерно как менеджер — трансформатор: «Гудит, значит, работает.» С точки зрения программиста, DBA — тоже черный ящик, из которого хрен что вытащишь. С самой СУБД хотя бы поиграться можно в разных режимах.

OSS DBMS — совсем другая парадигма, «белый ящик». Там весь стек открыт, и, если что непонятно, можно почитать код и даже подебажить. Можно написать своё расширение. Там такие особые DBA-шаманы просто не нужны. Проблема в том, что программисты продолжают относиться к открытым БД, как к черным ящикам, перекладывая роль DBA друг на друга.

aist1 ★★★
()
Ответ на: комментарий от anonymous

Ой, спасибо тебе, добрый аноним. Я стараюсь. Но не ради похвалы, ессно. Во славу Железного Господина!

aist1 ★★★
()
Ответ на: комментарий от aist1

Для начала, чтобы изучить этот «белый ящик», нужно открыть официальное Руководство пользователя. Выбрать те фичи, которые тебя интересуют, и по ним уже основательно копать (возможно даже залезть в исходники).

Бегло сравнивая Руководства пользователя (а это основательные тома свыше 1000 стр., в PDF) у PGSQL и Firebird я обнаружил, что PGSQL буквально напичкан фичами, которые вряд ли нужны в программном коде. Firebird же имеет меньше фич, но расписывает подробно как с ними работать.

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

iZEN ★★★★★
()
Ответ на: комментарий от aist1

В сухом остатке, мало кто заметил, что во всей этой истории больше всего был обосран Оракл.

MySQL - это тоже Oracle, если чё.

Oracle DB выпиливают сейчас, в основном, из-за дороговизны - ну не нужен он на «департамент» в 10 человек. А как был он «базой уровня предприятия» так он и остался, особенно в банковской и телекоммуникационных сферах. Вторая причина - импортозамещение.

anonymous
()
Ответ на: комментарий от aist1

В сухом остатке, мало кто заметил, что во всей этой истории больше всего был обосран Оракл.

Такие «остатки» сухими не бывают …

anonymous
()
Ответ на: комментарий от anonymous

Oracle DB выпиливают сейчас, в основном из-за того, что на SSD и Postgres с MySQL работают очень даже сносно в плане абсолютной производительности. Тут даже in-memory нормально справляются, потому что большинство реляционных БД — операционные и небольшого размера. Остаются вопросы, связанные с миграцией между версиями, отказоустойчивостью и прочий «джентельменский набор». Но это уже не тот уровень разработки, который требуется, когда нужно по максимуму выжать всё из топового серверного железа ценою в миллионы условных енотов.

А как был он «базой уровня предприятия» так он и остался, особенно в банковской и телекоммуникационных сферах.

Этот «уровень предприятия» — это не совсем то, что думают. Это не СУБД уровня предприятия, а профессиональные сервисы, оказываемые производителем СУБД, — уровня предприятия. Это та самая проблема, решать которую интеграторы открытых СУБД не в состоянии хотя бы чисто организационно.

И даже далеко не все большие компании могут в профессиональные сервисы вокруг своих продуктов. Оракл — может. Микрософт — может. А, например, Амазон — нет (для своего облака). От этого у него были большие трудности переманивать Wall Street в своё облако. Амазон не способен предоставлять тот уровень сервисов, на который банки привыкли рассчитывать.

aist1 ★★★
()
Ответ на: комментарий от aist1

Программист должен знать, как внутри работает БД. Он должен знать и характеристики её эксплуатации.

а на деле он и sql-то не знает, как правило.

Проблема в том, что DBA в целом — не программисты

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

БД видят примерно как менеджер — трансформатор: «Гудит, значит, работает.»

это ты большинство погромистов описал так-то

С точки зрения программиста, DBA — тоже черный ящик, из которого хрен что вытащишь

когда ничего не понимаешь, то и спросить толком нечего, да, такое сплошь и рядом.

зы ничего личного, ты судя по комментам адекватный разработчик.

anonymous
()
Ответ на: комментарий от anonymous

Wow. Чувак, я приношу тебе свои извинения, и всем DBA в твоем лице :)

Давай я поясню, что я имел в виду. Между DBA и программистами есть значимый разрыв компетенций, который я хочу сейчас показать. Здесь я имею в виду DBA вообще, а не конкретных людей. Конкретный DBA может досконально разбираться в своей СУБД, уметь её разобрать по винтикам и снова собрать с закрытыми глазами. Но, в целом, в компетенции DBA это не входит.

Ближе к делу. СУБД, не только реляционная, — сильно «текущая абстракция». Чтобы ими пользоваться эффективно, нужно хорошо знать, как оно внутри работает. Т.е. любая компания, которая более-менее серьезно завязана на СУБД, должна становиться немножечко database company. В моей истории, всякий раз, когда я этот вопрос поднимал, я слышал «мы не database company».

Что это значит? Что если используется тот же PG, то или должен быть на месте отдел (2+ человек), способный довести патчик до апстрима, или должен быть контракт с каким-нибудь постгрес-про. Т.е. нужен доступ к компетенциям по всему дата-стеку.

Звучит как overkill? Год назад под начало пандемии я менял работу. Так вот, 3 компании из 5, с которыми я говорил, или делали свою СУБД из подножных материалов (типа, блокчейн), или делали stateful microservices. Я разговаривал с их специалистами, и они соглашались, что stateful microservices — это полноценная СУБД по комплексу технических проблем, которые приходится решать. Сейчас практически всем приходится становиться database company. И проблемы у таких компаний растут из-за того, что люди с навыками разработки приложений без состояния начинают разрабатывать приложения, не только имеющие состояние, но и управляющие им. А это совсем другая инженерная культура. Это так не работает.

Теперь к самим DBA. Я ожидаю от DBA навыков разработки СУБД и жду от них компетенций по всему стеку данных, от железа и до приложения. Оптимизатор запросов — это классно, но этого не достаточно. DBA для закрытых СУБД, типа Oracle DB, просто не могут иметь эти компетенции, по причине закрытости. DBA, эксплуатирующие открытые СУБД, могут. Но не хотят, потому что переносят привычный для себя паттерн работы. Да и не ждет от них этого никто.

Разрыв компетенций состоит в том, что полный стек обработки данных не представляет себе никто. Ни программисты, ни DBA. И когда встают соответствующие вопросы, я от DBA слышу что-то типа «ты мне дай запрос, я сделаю тебе быстро».

Сейчас, правда, оформляется «инжиниринг данных», который пытается закрыть этот разрыв в компетенциях. Но там люди сфокусированы преимущественно на ETL и аналитике.

aist1 ★★★
()
Ответ на: комментарий от Turbid

я хз про ваш, но у мну в демьяне уже лет 10 как…

mumpster ★★★★★
()
Ответ на: комментарий от aist1

бенчмарков не делали… их стал делать уже в продакшене

ачотаковото! «Аякс, аякс - и в работу»

кстати, про pg & вакум - и как с ним предлагается бороться?

mumpster ★★★★★
()
Ответ на: комментарий от mumpster

кстати, про pg & вакум - и как с ним предлагается бороться?

Никак. Это сборщик мусора, а у них есть фундаментальная проблема — время работы O(N). И по мере роста N любые оптимизации, которые мы делаем для амортизации этого N, теряют эффективность для пользователей. Чем более интенсивная запись, тем хуже эффекты. Т.е. с какого-то значения N весь канал к диску будет тратиться только на сборку мусора. База встанет. Виртуозной эквилибристикой можно этот момент оттягивать, но он все равно заложен в саму архитектуру хранилища.

И это я еще не говорю про отдельную проблему «заворачивания» 32-битного TxnID. Бомба замедленного действия, про которую никогда не знаешь, когда она «жахнет».

Короче, с вакуумом и TxnID — только шардинг. Вот как раз перед глазами какая-то очередная история успеха на этом поприще, с аргументацией: https://www.notion.so/blog/sharding-postgres-at-notion

Я сейчас выскажу свое частное мнение. Проблема вокруг вакуумирования и заворачивания TxnID — одна из основных проблем, которые побудили меня прекратить интересоваться PG. Хотя я имел на него виды в плане разработки для него.

Были предложения увеличить ширину TxnID до 64 бит, но оказалось, что для этого «нужно слишком много правок вносить в кодовую базу». И это фундаментальная проблема разработки на С, что типы данных вбиты в код гвоздями, даже если они typedef-нуты. В большинстве (нетривиальных) случаев вокруг типа нужно еще какие-то вычисления проводить в точке использования, чтобы нормально его поместить в конкретный storage в точке использования. И вот С, как язык программирования, для этого не предоставляет ничего. Тут уже C++ нужен с его TMP. C++ справляется с такими делами очень даже хорошо.

Но есть проблемка практических всех Си-сообществ — иррациональная ненависть к С++. И хотя постгресисты в этом, в целом, не замечены, огромная инерция кодовой базы все равно есть. Где-то в 2010-м я решил, что PG «застрянет в проблемах». Он, хоть и не застрял (мои пессимистичные ожидания не оправдались), но и всё равно не вышел за 10 лет на тот уровень, на котором мог бы быть. И лично я виню в этом Си. Если они не смогли TxnID расширить (слишком сложно), то я не понимаю, как они вообще собираются разбивать свой дата-стек на слои. Без чего необходимого сейчас уровня гибкости дата-архитектуры не достигнуть (привет от Убера).

В общем, я для себя решил с разработкой для PG не связываться. Только для других и только за большие деньги.

Ну а в остальном, хорошая база для своих задач. Предпочитаю её тому же Мускулю по умолчанию. Т.е. буду выбирать последний реже, чем первый.

aist1 ★★★
()
Ответ на: комментарий от aist1

не, не надо мне рассказывать, про то как космические корабли бороздят просторы WAL ))

я с вакуумом боролси ещё когда pg был версии 6.чего-то там. вот это точно был ад и изгаиль! и вроде в районе 8 боле-мене причесали вакум до приемлемого. потом, в районе 9ки, у нас с pg дороги разошлись. и тут я опять слышу про какие-то проблемы с вакумом.

про TxnID - никогда не слышал, ваще не знаю что это.

и да, с Ораклом как СУБД - тоже масса забавных и не очень историй связано. ибо сказано же, «nobody’s perfect».

mumpster ★★★★★
()
Ответ на: комментарий от mumpster

и тут я опять слышу про какие-то проблемы с вакумом.

Про них мы будем слышать еще долго. Фундаментальное ограничение дизайна. Проблему можно было бы полечить, запоминая для каждой страницы количество старых версий, и строя дальше b-tree-подобную структуру над страницами. На основе такого индекса можно потом скипать большие множества страниц при просмотре таблицы. Для CoW-MVCC характерна ситуация, когда «горячее» множество строк будет сосредотачиваться в «конце» таблицы.

Не знаю, может у них уже что-то такое есть сейчас.

aist1 ★★★
()
Ответ на: комментарий от aist1

Я к таким вещам отношусь прагматически. Если работает для твоих нагрузок — то и ОК. И не принципиально, что у него там в асимптотике заложено. Другое дело, что vacuum в PG трудно управляемая штука. Он, например, может останавливаться при репликации, в зависимости от настроек. И т.п.

aist1 ★★★
()
Ответ на: комментарий от hobbit

Хотелось бы, чтобы они что-то вроде оракловых пакетов запилили. Не знаю, как сейчас, а в середине нулевых после PL/SQL садиться за PL/pgSQL было не очень удобно. Вроде бы всё есть и всё можно сделать, но очень уж вырвиглазно.

Да пакетов не мешало бы, для более прозрачной миграции с оры…

Мне показалось они пытались в качестве так сказать компенсирующей альтернативы предоставить подключаемые языки (python, php и другие) вместо PL.

anonymous
()
Ответ на: комментарий от anonymous

Да пакетов не мешало бы, для более прозрачной миграции с оры…

Если бы причина была только в прозрачности миграции — это был бы не особо увесистый аргумент. PostgreSQL не обязан быть калькой Oracle Database, точно так же, как и LibreOffice не обязан быть калькой Microsoft Office. Это своя СУБД со своими особенностями.

Другое дело, что пакеты удобны и сами по себе. Как средство упорядочивания кода, как способ ухода от чрезмерного большого количества глобальных имён. Переменные, опять-таки. И вот с этой точки зрения — пакеты или подобную им структурную единицу очень желательно бы иметь.

hobbit ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.