проблемы с php и postgres.

[stranger]

Вот решил с perl на php переход осуществить и заодно посмотреть, что это за заверь этот PHP. И есть маленькая проблема. Подробности далее.

Общая инфо:
Стоит php и postgres на шляпном linux не пересобранные.
postgres настроен на работу по udp.
Создал базу www в кодировке win.
Написал следующий код в php-странице...

Code: [Select]

<?
$uid=$HTTP_GET_VARS["id"];

$conn=pg_connect("dbname=... user=... password=...");
if (!$conn) {
echo 'Проблема с соединением с ...';
exit;
}

$shortinfo=pg_exec($conn,"SELECT fio,emailn,emaild,id from stuff");
for($i=0;$i<pg_numrows($shortinfo);$i++){
$fio=pg_result($shortinfo,$i,0);
$emailn=pg_result($shortinfo,$i,1);
$emaild=pg_result($shortinfo,$i,2);
$id=pg_result($shortinfo,$i,3);

print("Ф.И.О $fio".'<br>');
}
echo $uid;
?>

Работа с базой не проходит. В логах апача появляется следующая запись:

[client IP] PHP Warning: pg_exec(): Query failed: ERROR: \xc4\xcf\
xd3\xd4\xd5\xd0 \xda\xc1\xd0\xd2\xc5\xdd\xa3\xce \xc4\xcc\xd1 \xd3\xd7\xd1\xda\x
c9 stuff in /var/www/html/test1.php on line 33
[client IP] PHP Warning: pg_numrows(): supplied argument is not a v
alid PostgreSQL result resource in /var/www/html/test1.php on line 34

В чем может быть проблема?

[stranger]

Все проблема кажется решилась.
Я не много  ступил... Маленько от проблемы отстранился и понял...  :jjosh:

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

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

[One]

Зачем Вам этот PHP, простите за любопытстj? Чем Perl не устроил?

PS Вы сказали, что "переходите" c Perl... жалко наблюдать когда бросают Такое на такое... IMO.  

[demiurg]

Зачем Вам этот PHP, простите за любопытстj? Чем Perl не устроил?

PS Вы сказали, что "переходите" c Perl... жалко наблюдать когда бросают Такое на такое... IMO. 

[snapback]7052[/snapback]

Говорить "PHP -- гавно, Perl -- rulezz" или наоборот, по крайней мере глупо. Есть задачи для которых больше подходит perl, есть задачи для которых лучше использовать php. И если человек перешел на PHP -- значит у него были на то причины. Кроме того, там дальше же написано "и заодно посмотреть, что это за заверь этот PHP."
По своему опыту скажу, что на изучение PHP у меня ушло 2 дня. На третий я уже мог вести на нем разработку и читать чужой код (!). С perl я возился около месяца...но это конечно того стоило . Для моей задачи "чистый php" не удобен. А вот адская смесь из php+perl очень подошла.

[One]

Говорить "PHP -- гавно, Perl -- rulezz" или наоборот, по крайней мере глупо. Есть задачи для которых больше подходит perl, есть задачи для которых лучше использовать php. И если человек перешел на PHP -- значит у него были на то причины. Кроме того, там дальше же написано "и заодно посмотреть, что это за заверь этот PHP."
По своему опыту скажу, что на изучение PHP у меня ушло 2 дня. На третий я уже мог вести на нем разработку и читать чужой код (!). С perl я возился около месяца...но это конечно того стоило . Для моей задачи "чистый php" не удобен. А вот адская смесь из php+perl очень подошла.

[snapback]7055[/snapback]

Ну, тогда если не цели достигаемые, типа, приемуществом PHP над Perl, то хотя бы технологии выигрыша простоты/производительности PHP над Perl приведите, pls. А то, как тут меня "учат": "я - не телепат", да?

PS Ну, а какой я не PHP не обзывал. Просто достигнув высот Perl, до PHP ли обращаться...

[stranger]

Зачем Вам этот PHP, простите за любопытстj? Чем Perl не устроил?

PS Вы сказали, что "переходите" c Perl... жалко наблюдать когда бросают Такое на такое... IMO. 

[snapback]7052[/snapback]

Всем меня Perl устраивает - просто решил выучить новый язык за одно в целях самообразования  :rolleyes:  
Да и в php то же оказалось есть свои прелести и удобства...

[stranger]

Говорить "PHP -- гавно, Perl -- rulezz" или наоборот, по крайней мере глупо. Есть задачи для которых больше подходит perl, есть задачи для которых лучше использовать php.

[snapback]7055[/snapback]

Полностью согласен... Нужно выбирать под задачу язык, а не наоборот...

По своему опыту скажу, что на изучение PHP у меня ушло 2 дня. На третий я уже мог вести на нем разработку и читать чужой код (!). С perl я возился около месяца...но это конечно того стоило . Для моей задачи "чистый php" не удобен. А вот адская смесь из php+perl очень подошла.

[snapback]7055[/snapback]

Да, PHP в принципе не сложный язык и тем более тем кто работал на perl его изучить не сложно, так как синтаксис очень похож. Хотя, чтобы изучить все тонкости - нужно наверное потратить достаточно много времени.
Тем более как я изучаю языки. Я не стараюсь его изучать сразу. Есть проблема - решаю ее и изучаю только то, что нужно для решения этой проблемы и так потихоньку.

Кстати, ради интереса,  это какие нужно задачи, что бы использовать связку двух языков?

[stranger]

Ну, тогда если не цели достигаемые, типа, приемуществом PHP над Perl, то хотя бы технологии выигрыша простоты/производительности PHP над Perl приведите, pls. А то, как тут меня "учат": "я - не телепат", да?

[snapback]7056[/snapback]

Если пользовать perl без mod_perl в апаче, то производительность скорее всего будет меньше. А под mod_perl еще нужно уметь оптимизировать прогрмаммы. С mod_perl производительность во многих случаях примено одинаковая.

Простота... Хм... Так как PHP все-таки был разработан для создания сайтов, то его изначально пользовать проще, чем перл, который все-таки более универсальный.
Код php достаточно просто вставляется внутрь обычного html и его можно чередовать. А perl - это отдельный скрипт по обработке, который нужно писать и сама страница выводится тем или иным способом через операции вывода.

Это наверное основное. Я как начинающий в php могу сразу эти аргументы привести...

[Krueger]

Code: [Select]

$conn=pg_connect("dbname=... user=... password=...");if (!$conn) {echo 'Проблема с соединением с ...';exit;}попробуй заменить на

Code: [Select]

@$conn=pg_connect("dbname=... user=... password=...") or die ('Проблема с соединением с ..');с mysq_connect работает, должно работать и с postgres.
Но это так, для красоты:-)

[Krueger]

Код php достаточно просто вставляется внутрь обычного html и его можно чередовать. А perl - это отдельный скрипт по обработке, который нужно писать и сама страница выводится тем или иным способом через операции вывода.

Немного дополню. php скрипты также работают и из командной строки и, если хочется поизвращаться, можно их сделать, как сценарии cgi-bin.

[stranger]

Code: [Select]

@$conn=pg_connect("dbname=... user=... password=...") or die ('Проблема с соединением с ..');с mysq_connect работает, должно работать и с postgres.
Но это так, для красоты:-)

[snapback]7063[/snapback]

Хм... Как я не догадался - ведь синтаксис php очень на perl похож, а в перл я практически всегда die пользуюсь.
Спасибо! Буду так пробовать...

[Krueger]

И ещё обрати внимание на функцию pg_pconnect.
вот описание того, что такое постоянные соединения к БД и надо-ли оно.

Постоянные соединения представляют собой связи с базами данных, которые не закрываются при завершении скрипта. При получении запроса на постоянное соединение PHP вначале проверяет, имеется ли идентичное постоянное соединение (которое было открыто при предыдущих обращениях) и, если таковое было найдено, использует его. В случае, если идентичного соединения нет, PHP создает новое. Под "идентичным" подразумевается соединение, открытое на тот же хост с таким же именем пользователя и паролем (если они указаны).

Та часть разработчиков, которая не имеет четкого представления о том, как работает веб-сервер и как распределяется нагрузка, могут получить ошибочное представление о том, чем на самом деле являются постоянные соединения. В частности, постоянные соединения не предоставляют возможность открывать 'пользовательские сессии' в том же самом соединении, они не предоставляют возможность организовывать более эффективные транзакции, также они не предоставляют множества других полезных возможностей. Фактически, постоянные соединения не предоставляют никакой функциональности, которая была бы невозможна в непостоянных аналогичных соединениях.

Почему?

Это зависит от того, как происходит взаимодействие с веб-сервером. Существует три основных способа использования PHP сервером для генерации веб-страниц.

Первый способ заключается в том, чтобы использовать PHP как CGI-оболочку. При этом PHP-интерпретатор создается и уничтожается при каждом обращении к странице (PHP-скрипту). Поскольку интерпретатор уничтожается после каждого запроса к серверу, все используемые им ресурсы (в том числе и соединение с базой данных) закрывается. Следовательно, в этом случае вы не получите ничего от использования постоянных соединений - их просто нет.

Второй, и наиболее популярный способ - использовать PHP как модуль в сервере, который использует несколько процессов. В число таких серверов сейчас входит только Apache. В таком случае, можно выделить один процесс (родительский), который координирует работу всех остальных процессов (дочерних), которые фактически и выполняют работу по обслуживанию веб-страниц. При каждом обращении клиента к серверу запрос перенаправляется одному из дочерних процессов, который в данный момент не занят обслуживанием другого клиента. Это означает, что когда тот же самый клиент выполняет повторный запрос к серверу, он может быть обработан другим дочерним процессом, отличным от того, который был при первом обращении. После открытия постоянного соединения каждая последующая страница, требующая соединения с базой данных, может использовать уже установленное ранее соединение с SQL-сервером.

Третий способ - использовать PHP в качестве плугина в многопоточном веб-сервере. В настоящее время в PHP4 реализована поддержка ISAPI, WSAPI, и NSAPI (для Windows-платформ), которые позволяют подключать PHP к таким многопоточным серверам, как Netscape FastTrack (iPlanet), Microsoft's Internet Information Server (IIS) и O'Reilly WebSite Pro. В этом случае поведение PHP полностью аналогично рассмотренной ранее модели с использованием нескольких процессов. Следует заметить, что поддержка SAPI отсутствует в PHP 3.

Если постоянные соединения не предоставляют никакой дополнительной функциональности, чем же они тогда так хороши?

Ответ содержится в повышении эффективности. Постоянные соединения полезны в том случае, если при открытии большого количества SQL-соединений возникает ощутимая нагрузка на сервер. То, насколько велика эта нагрузка, зависит от многих факторов. Например, от того, какая именно база данных используется, находится ли она на том же компьютере что и ваш веб-сервер, насколько загружена машина, на которой установлен SQL-сервер, и так далее. В случае, если затраты на установку соединения велики, постоянные соединения могут вам существенно помочь. Они позволяют дочернему процессу на протяжении всего жизненного цикла использовать одно и то же соединение вместо того, чтобы создавать его при обработке каждой страницы, которая взаимодействует с SQL-сервером. Это означает, что каждый дочерний процесс, открывший постоянное соединение, будет иметь свое собственное соединение с сервером. Например, если у вас запущено 20 дочерних процессов, которые выполнили скрипт, использовавший постоянное соединение с SQL-сервером, вы получите 20 различных соединений с SQL-сервером, по одному на каждый дочерний процесс.

Следует заметить, что этот подход имеет некоторые недостатки: если вы используете базу данных с ограниченным количеством возможных подключений, оно может быть превышено количеством запрашиваемых дочерними процессами постоянных соединений. Например, если ваша база данных позволяет 16 одновременных соединений, и во время нагрузки на сервер 17 дочерних процессов попробуют открыть соединение, одна из попыток потерпит неудачу. Если в вашем коде содержатся ошибки, не позволяющие закрывать соединение (например, бесконечные циклы), база данных с 32 одновременными подключениями вскоре может оказаться заблокированной. Информацию о том, как обрабатывать открытые и неиспользумые соединения, вы можете найти в документации к вашей базе данных


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

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

[One]

Всем меня Perl устраивает - просто решил выучить новый язык за одно в целях самообразования  :rolleyes: 

[snapback]7059[/snapback]

Ну, это другое дело!

О скорости: сейчас уже mod_perl2 есть - оптимизация... - ну, она того стоит
Хотя есть свои "прелести" конечно.

Раз Вы сравниваете скорости perl/mod_perl и PHP - "тесты в студию!". Как можно "на пальцах" говорить?

Я понимаю, что PHP - простой (потому, наверное, и выжил, к моему удивлению). Но Вы же хотите стать серъёзным разработчиком? Или выше любителя, пусть даже опытного, подниматься не собираетесь? - Это не вопрос, можно не отвечать.

[-ud-]

Это ты про то что серьезные люди не пишут на php? :lol:

[stranger]

И ещё обрати внимание на функцию pg_pconnect.
вот описание того, что такое постоянные соединения к БД и надо-ли оно.

[snapback]7069[/snapback]

Э... Про это я знаю...  Но все равно спасибо!

Я ведь работал в тестовом режиме, поэтому и использовал pg_connect, а как только скрипт был отработан, то заменял на pg_pconnect

[stranger]

Ну, это другое дело!

О скорости: сейчас уже mod_perl2 есть - оптимизация... - ну, она того стоит
Хотя есть свои "прелести" конечно.

Раз Вы сравниваете скорости perl/mod_perl и PHP - "тесты в студию!". Как можно "на пальцах" говорить?

[snapback]7081[/snapback]

В свое время я интересовался тестами на производительность (пару лет назад) и ситуация была примерно как я написал. Сейчас может, что-то изменилось, но не думаю, что сильно.

Я понимаю, что PHP - простой (потому, наверное, и выжил, к моему удивлению). Но Вы же хотите стать серъёзным разработчиком? Или выше любителя, пусть даже опытного, подниматься не собираетесь? - Это не вопрос, можно не отвечать.

[snapback]7081[/snapback]

А вам не кажеться, что может быть обратная ситуация. Я знаю и умею писать на perl, по крайней мере на среднем уровне. Но пользовать его для простых задач было бы не рентабельно - затраты достаточно большые. Это как пользовать оракляндию для таблицы из 200 строк или стрелять из пушки по воробьям.
Да и потом другим людям возможно придется еще с этим потом разбираться, а там вряд ли в ближайшее время появиться perl програмист. А php для той простой странички, хоть и с базой, само то...

Да и самосовершенствование (в данном случае по изучению нового языка) не помешает.

З.Ы. Изучив часть возможностей php - он меня честно говоря впечатлил - достаточно удобная штука. И не настолько простая, как некоторые думают.

[One]

В свое время я интересовался тестами на производительность (пару лет назад) и ситуация была примерно как я написал. Сейчас может, что-то изменилось, но не думаю, что сильно.
Если изменилась, то может и сильно. - Трудно говорить, когда не знаешь что там PHP делает.

А вам не кажеться, что может быть обратная ситуация. Я знаю и умею писать на perl, по крайней мере на среднем уровне. Но пользовать его для простых задач было бы не рентабельно - затраты достаточно большые. Это как пользовать оракляндию для таблицы из 200 строк или стрелять из пушки по воробьям.
Да и потом другим людям возможно придется еще с этим потом разбираться, а там вряд ли в ближайшее время появиться perl програмист. А php для той простой странички, хоть и с базой, само то...

Да и самосовершенствование (в данном случае по изучению нового языка) не помешает.

З.Ы. Изучив часть возможностей php - он меня честно говоря впечатлил - достаточно удобная штука. И не настолько простая, как некоторые думают.

[snapback]7084[/snapback]

Если изменилась, то может и сильно. - Трудно говорить, когда не знаешь что там PHP делает.

Вы правы: инструмент подбирается под задачу. Разница в подходе лишь в встривании кода в HTML либо HTML в код. - Для программера большой разницы нет. - Чего не скажешь о мощи. Ничего нет сложного в том, чтобы сделать запрос к БД с Perl. А при обилии его модулей - фактически просто берите "кубики" и собирайте свой "домик". Знаете я не просто не вижу смысла в изучении этого языка... Но! Ваша жизнь - Ваше дело. - Решайте, конечно, же сами. Лично я бы "убивал" своё время на изучение технологий Perl: его модули в той оьласти, которой работаю, дабы сократить переизобретений "колеса", тем самым, ДЕЙСТВИТЕЛЬНО сократить расходы на разработку.

[stranger]

Все-таки я решил ответить на этот пост.
Я в этих фразах слышу себя лет так 3-5 назад, но со временем я изменил свои взгляды.

Да программеру нет практически разницы на чем писать, но вот заказчику разница есть - это первое. Да CPAN это хорошо, но иногда бывает нужно затратить больше времени на поиск модуля, чем его самому написать. У PHP за несколько лет библиотека модулей то же не маленькая стала...

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


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

  Доводов в принципе можно приводить много, но я думаю этого хватит.
        И на этом обсуждение, что нужно использовать PHP или Perl я закончу.

З.Ы. По поводу баз из перл - я вообще-то знаю как с ними работать, так как работал через перл и с ораклом и с постгресом. Что такое DBI & DBD я знаю...