Consulta Postgre

Mie Jul 27 16:17:04 CEST 2005

Realmente se encuentra en el sys.path ?

CREATE FUNCTION pythonpath() RETURNS TEXT LANGUAGE plpythonu AS '
import sys; return sys.path
';

SELECT pythonpath();

Lo digo porque quizá el entorno con que arranca postgres no es el mismo 
que tú tienes como usuario. En todo caso, si usas postgres bajo Linux 
puedes modificar el archivo  .profile  del usuario postgres, o meterlo 
en postgres.conf o crearte una función para agregarlo al python path 
desde SQL.

Erny

Catalin Lungu escribió:

> Hola,
> Ya me he creado funciones en el servidor y las puedo llamar desde mis 
> programas. Ahora me gustaría poder importar mis módulos desde las 
> funciones. Puedo importar sys, time, etc. pero no puedo importar 
> random y tampoco mis módulos aunque la ruta de los módulos se 
> encuentra en sys.path
>
> Muchas gracia otra vez.
> Catalin
>

>
> ----- Original Message ----- From: "Ernesto Revilla" <erny en sicem.biz>
> To: "La lista de python en castellano" <python-es en aditel.org>
> Sent: Tuesday, July 26, 2005 9:01 PM
> Subject: Re: [Python-es] Consulta Postgre
>
>
>> Hola,
>>
>> Respecto a lo que dices, puedes usar una consulta parametrizada 
>> también, pero parece que pyPgSQL no lo soporta. Puedes usar PREPARE 
>> para crear una consulta optimizada. He hecho una prueba sobre la 
>> inserción de 10000 filas:
>>
>> SQL Normal:    10.9159998894 segundos
>> Params expandidos por pyPgSQL: 13.5299999714 segundos
>> autocommit habilitado: 20.1190001965 segundos
>> con plan preparado: 10.0750000477 segundos
>>
>> (fuente en 
>> http://www.sicem.biz/personal/erny/python/Recetas/testpyPgSQL)
>>
>> ¿Cómo calculas los precios? ¿Qué otras variables / tablas intervienen?
>>
>> Estos días he estado revisando la interfaz python de programación en 
>> servidor (SPI), y realmente tiene una pinta estupenda. Viene 
>> incluído/compilado en Debian Sarge (Postgresql 7.4.x) y Windows. Para 
>> Fedora Core 3 hay paquete instalable. Es bastante probable que esté 
>> incluido o que existe como paquete de binarios para la distribución 
>> que uséis.
>>
>> Cosas interesantes:
>> * todos los triggers se ejecutan en una transacción. Al fallar el 
>> trigger se realiza automáticamente un Rollback
>> * se puede realizar importaciones de módulos, y por tanto escribir 
>> toda la lógica del servidor con vuestro editor favorito, en un 
>> directorio cualquiera con lo que podáis usar fácilmente cvs, 
>> subversion o cualquier otro paquete de control de versiones
>> * los triggers pueden diseñarse genéricamente para inserción, borrado 
>> y modificación de registros:
>> * los datos de los triggers están disponibles en un simple 
>> diccionario (TD)
>> * se pueden intercambiar datos entre varias funciones a través de un 
>> diccionario global (GD)
>> * cada función dispone de un diccionario que mantiene su estado entre 
>> las llamadas a la función (ejemplo, contador)
>>
>> http://python.fyxm.net/pycon/dc2004/papers/23/
>>
>> Para tus cosas:
>> desde el sistema operativo, intenta instalar python como un lenguaje 
>> (entra como usuario postgres o el que sea tu superusuario de la BD):
>> $ createlang plpythonu <base de datos>
>>
>> desde psql o mandando consultas a la BD:
>> create function actualizaPrecios() returns void as $$
>> <código python aquí.
>> puedes usar plpy.execute para realizar consultas>
>> $$ language plpython;
>>
>> Un saludo,
>> Erny
>>
>>
>>
>>
>> Chema Cortes escribió:
>>
>>> Catalin Lungu escribió:
>>>
>>>> Si no hay mas remedio me servirá esto. La idea era hacer el UPDATE 
>>>> en un
>>>> solo comando SQL. El UPDATE modifica una columna entera en una sola
>>>> llamada sin hacer un bucle para cada fila. Pues esto mismo me gustaría
>>>> que pueda hacer, es decir evitar 10 millones de iteraciones para 
>>>> cada fila.
>>>>
>>>
>>> Si la tabla está indexada por el campo ID no serían tantas iteraciones.
>>> Si se agrupa todo en una sóla transacción no debería dar mayores 
>>> problemas.
>>>
>>> Pero parece que lo que buscas sean las funciones almacenadas de
>>> postgresql. Las puedes escribir en pl/pythonu, pero ten en cuenta que
>>> éso significaría cargar bastante el servidor, además de que seguramente
>>> tendrías que recompilar el postgresql para aceptar python. Si los
>>> cálculos no son muy complejos, podrías hacerlos con pl/pgsql.
>>> _______________________________________________
>>> Python-es mailing list
>>> Python-es en aditel.org
>>> http://listas.aditel.org/listinfo/python-es
>>>
>>>
>>
>>
>>
>>
>> ---
>> avast! Antivirus: Saliente mensaje limpio.
>> Base de datos de Virus (VPS): 0530-1, 26/07/2005
>> Comprobado en: 26/07/2005 21:01:04
>> avast! tiene los derechos reservados (c) 2000-2004 ALWIL Software.
>> http://www.avast.com
>>
>>
>> _______________________________________________
>> Python-es mailing list
>> Python-es en aditel.org
>> http://listas.aditel.org/listinfo/python-es
>>
>
>
> _______________________________________________
> Python-es mailing list
> Python-es en aditel.org
> http://listas.aditel.org/listinfo/python-es
>

---
avast! Antivirus: Saliente mensaje limpio.
Base de datos de Virus (VPS): 0530-1, 26/07/2005
Comprobado en: 27/07/2005 16:17:05
avast! tiene los derechos reservados (c) 2000-2004 ALWIL Software.
http://www.avast.com