Объясните RLS как различать какой сервер имеет в виду текущий запрос. А затем - как гарантировать, что этот признак выставляет только тот, кому это можно. Иначе любая безопасность здесь бесполезна. RLS никак не поможет, если клиент имеет возможность манипулировать списком собственных полномочий.
Дескриптор будет уничтожен. Потому последующий curl_setopt и жалуется. Переменная - нет, и будет содержать пустой zend_resource с невалидным type.
Лучше обнулить _ch явно после curl_close. Понятнее будет.
Впрочем соглашусь с ThunderCat , дизайн класса вызывает вопросы.
Для приведённого кода throw new Exception('Empty $_ch in MtargetOffers.'); недостижим никогда. Ни на первом ни на повторном вызове. Я уже написал почему.
идея в том, чтобы выбрать нужные 10 записей и только для них считать count по Unit, а не по всей таблице считать группировку и затем джойнить с нужными 10 записями. До появления lateral join это делалось как у вас в ответе дублированием условия, выносом условия в отдельный cte, или даже функцией. С lateral join немного удобнее это объяснять, в подзапросе в join появляется возможность сделать коррелированный запрос.
Да, в нормально спроектированной базе первичный ключ должен быть и да, его необходимо указывать явно. Так же как FK и прочие ограничения целостности. Потому что только разработчик схемы знает свои ограничения хранимых данных.
Счетчик в цикле не обязательно используется как индекс в массиве, так что всегда надо смотреть на ситуацию.
Так и я о том же самом пишу.
Из текста вопроса не следует (на мой взгляд), что вопрос касается исключительно работы с массивом в памяти. Вопрос про счётчик итераций.
Евгений Шатунов, потому что size_t - implementation-defined (гарантируется емнип вообще только 16 бит). Если вам заведомо необходимо 64-битное целое - то вам не по пути с implementation-defined вещами, вам нужно именно 64-битное целое.
если полей много - то тем более собирают необходимый запрос из необходимых частей (использованных пользователем фильтров), а не пытаются запутать планировщик описанием всего сразу.
rgzrgz, погуглите как найти установленные пакеты с конкретного репозитория. На память не подскажу.
И по этому списку пакеты от 7.2 будут в большинстве случаев иметь 7.2 в названии. А метапакеты - не будут иметь какой-то принадлежности в имени.
/etc/apt/sources.list.d/php.list ?
Это корректное место для адресов репозиториев, идентично /etc/apt/sources.list
А если мне нужен именно php 7.2. Это удалит поддержку 7.2?
Это удалит репозиторий. Пакеты останутся, но обновляться не будут.
А происходит у вас очевидно то, что вы добавили этот репозиторий, поставили пакеты типа libapache2-mod-php. По зависимостям прилетел 7.2. Прошло время. Вышел php 7.3. libapache2-mod-php теперь указывает на libapache2-mod-php7.3.
Совершенно очевидно apt хочет сказать, что для соответствия новым реалиям есть обновления - надо на 7.3 обновляться. Но upgrade это сделать не может, т.к. надо ставить новые пакеты. dist-upgrade предложит поставить 7.3
Если вы не готовы к 7.3 - то вам надо снести метапакеты без указанных версий, а на нужны проставить apt-mark manual метку
