Wednesday, May 28, 2008

Re: [pgsql-www] 404s

On Wed, 2008-05-28 at 18:23 +0200, Stefan Kaltenbrunner wrote:
> Dave Page wrote:

> > Probably because noone checked the log recently (we know if errors
> > occur through other channels, but not 404 warnings).
>
> well the logs still have a fair number of false positives.
> This partly due to the mirror script being a bit careless at times in
> what it should consider a valid url and the other part is url's that we
> once had and referenced in say a press release that are no longer valid
> (be it website reorg or a decision to rename directories on the ftp site).
> otoh it seems that we have at least one really broken URL in the press
> FAQ page - will see if we can fix that ...
>

What if we used a rewrite rule on 404 to actually bring up a single
entry form that said, "Report broken page: <email> <submit>".


Sincerely,

Joshua D. Drake

>
> Stefan
>


--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

Re: [pgsql-www] 404s

Dave Page wrote:
> On Wed, May 28, 2008 at 10:25 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On Wed, 2008-05-28 at 10:09 +0100, Dave Page wrote:
>>> On Wed, May 28, 2008 at 9:55 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>>> Do we keep track of 404 errors on the .org website?
>>> The spider logs internal errors (or used to, I haven't looked at
>>> recent versions). Why, did you find one?
>> Yes. I'm trying to understand why we didn't spot the 404s, nor perform a
>> link check that would do that.
>
> Probably because noone checked the log recently (we know if errors
> occur through other channels, but not 404 warnings).

well the logs still have a fair number of false positives.
This partly due to the mirror script being a bit careless at times in
what it should consider a valid url and the other part is url's that we
once had and referenced in say a press release that are no longer valid
(be it website reorg or a decision to rename directories on the ftp site).
otoh it seems that we have at least one really broken URL in the press
FAQ page - will see if we can fix that ...


Stefan

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[GENERAL] Clustering with minimal locking

If I'm not totally off-base, here's one way to enable clustering on systems
that run 24/7:

1 cluster current rows
1.1 note current last committed transaction
1.2 copy all visible rows to new table in cluster order
1.3 build indexes on new table
2 add changes
2.1 note current last committed transaction
2.2 apply to new table (& indexes) all changes committed since 1.1
3 put new table into service
3.1 take exclusive lock on table
3.2 apply to new table (& indexes) all changes committed since 2.1
3.3 switch in new table
3.4 release lock
3.5 clean up old table storage

I don't know enough about pg internals to know how big a project this would
be, but it seems to me that the WAL provides many of the pieces needed to
support steps 1.1 and 2.2, for instance. (Even so, I know it's still not
trivial, just perhaps not huge.)

- I guess there's still the possibility that 3.1 could stall in the presence
of long-lived transactions--but this is certainly no worse than the current
situation where it would stall before starting the cluster operation.

- By "apply changes" I mean insert, update, delete rows--of course schema
changes would be locked out during the cluster, even if it takes days ;-)

--
Scott Ribe
scott_ribe@killerbytes.com
http://www.killerbytes.com/
(303) 722-0567 voice

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Open Source CRM - Options?

On May 28, 2008, at 8:52 AM, David Wall wrote:

> What about SugarCRM?

It's nice, but it's MySQL only, with a few desiccated corpses of ports
to PostgreSQL done by third parties littered in it's wake.

vTiger is a fork / knock-off of Sugar which has sorta-kinda support
for PostgreSQL in older versions, but not in the current version. http://wiki.postgresql.org/wiki/VTigerCRM

Cheers,
Steve


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[pgsql-www] replace training blurb with upcoming pug meetings?

In an effort to give more visibility to the pugs, one idea that was floated
around was replacing the training blurb on the main site with an "upcoming
pugs" section, modeled after the upcoming events. The training blurb would
then be changed to a direct link saying "looking for training?" (or similar)
which would take you to the full training page. There are some logistical
issues that would need to be worked out to make this happen, but before we go
down that path, I wanted to get a general consensus on the idea. thoughts?

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

Re: [PERFORM] GEQO Benchmark

Hi,

Of course, the geqo_threshold can be changed so that the geqo be performed in queries that have less than 12 tables. However, we aim to test the GEQO algorithm in conditions where the standard algorithm (dynamic programming) has a high cost to calculate the query plan.

--

Tarcizio Bini

2008/5/28 Tom Lane <tgl@sss.pgh.pa.us>:
tarcizioab@c3sl.ufpr.br writes:
> I'm using the TPC-H Benchmark for testing of performance in PostgreSQL.
> But it is composed of only 8 tables, which is not enough to call the GEQO
> algorithm.

See
http://www.postgresql.org/docs/8.3/static/runtime-config-query.html#RUNTIME-CONFIG-QUERY-GEQO

particularly geqo_threshold.

                       regards, tom lane

Re: [pgsql-es-ayuda] Instalacion desatendida

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Esto te puede ayudar:

http://pginstaller.projects.postgresql.org/silent.html

Lo que hace una búsqueda en google :D....

Ing. Eris J. Gomez escribió:
| Saludos al grupo.
| Esta vez tengo una pregunta, aunque no meramente de SQL, sino de
instalación desatendida.
| Como puedo especificar los parámetros para que Postgres se auto
instale es decir, que el usuario no tenga que digitar ninguna
información sino que yo las establezca.
|
| Gracias.
| *
|
| Ing. Eris J. Gómez
| Racol Computers, C x A.
| Símbolo de calidad en software.
| Av. 27 de febrero #37, Villa Progreso
| Santiago de los Caballeros, República Dominicana
| Tel.: (809) 971-3157, Fax: (809) 582-6636
| Email: racolsoftware@hotmail.com <mailto:racolsoftware@hotmail.com>
| *
|
| -------------------------
|
| --
| TIP 7: no olvides aumentar la configuración del "free space map"


- --
-
-------------------------------------------------------------------------------------------------
L.A. Jenaro Centeno Gómez Al-Día se
renueva con la Mejora Continua
Coordinador de Tecnologías de la Información
Alimentos La Concordia, S.A. de C.V.
www.aldia.com.mx

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIPYOl+nACvgizD48RAkGDAJoD8mxIEsZvyLUIggeosZ6pDpLtRwCgqabI
TWAO6gL9W3r3KV7ra4Klw/E=
=4I9u
-----END PGP SIGNATURE-----

--
TIP 4: No hagas 'kill -9' a postmaster

Re: [pgsql-es-ayuda] Instalacion desatendida

El día 28 de mayo de 2008 10:02, Ing. Eris J. Gomez
<eris_jose@hotmail.com> escribió:
> Saludos al grupo.
> Esta vez tengo una pregunta, aunque no meramente de SQL, sino de instalación
> desatendida.
> Como puedo especificar los parámetros para que Postgres se auto instale es
> decir, que el usuario no tenga que digitar ninguna información sino que yo
> las establezca.

eso depende del sistema operativo y los parámetros que deseas establecer....
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

Re: [pgsql-es-ayuda] PostgreSQL en Chile, jornadas

2008/5/28 Guido Barosio <gbarosio@gmail.com>:
> Desconozco, sinceramente me llego la nota y la comparti con el grupo.
>
> Quizas Alvaro o alguno de los chicos de Chile nos pueda dar una idea
>

solo preguntaba porque no se menciona en la nota.
--
TIP 4: No hagas 'kill -9' a postmaster

Re: [pgsql-es-ayuda] Problema con execute

mil gracias a todos.. anduvo perfecto.
saludazos.


__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

RE: [pgsql-es-ayuda] sobre ALTER TABLE

OK, OK, OK............

No lo habia leido bien, crei que pensaba "rescatar" algun valor del campo
TIME, pero que valor va a rescatar si no hay nada que rescatar de tipo DATE,
lo mas saludable y menos complicado y perder menos tiempo es dropearlo y
poner el campo que se necesite.

Miguel Canchas

-----Mensaje original-----
De: Jaime Casanova [mailto:systemguards@gmail.com]
Enviado el: Miércoles, 28 de Mayo de 2008 10:41 a.m.
Para: MIGUEL CANCHAS
CC: Marcos Saldivar; Mario Reyes (GENESYS);
pgsql-es-ayuda@postgresql.org
Asunto: Re: [pgsql-es-ayuda] sobre ALTER TABLE


On Wed, May 28, 2008 at 10:28 AM, MIGUEL CANCHAS <mcanchas@tsr.com.pe>
wrote:
> no seria mejor crear una columna con el tipo de dato que necesita y
> adicionarle los datos "casteados" desde la columna a "dropear"
>

y como harias el cast? si eres capaz de "castearlos" entonces puedes
usar la clausula USING del ALTER TABLE ... ALTER ... TYPE para hacer
el trabajo, sin columnas adicionales ni drops


--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 087171157
--
TIP 8: explain analyze es tu amigo

Re: [GENERAL] Open Source CRM - Options?

What about SugarCRM?

David

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Psql crashes with Segmentation fault on copy from

On 11:09 am 05/28/08 Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > I installed
> > compat-postgresql-libs-debuginfo-3-2PGDG.rhel4.x86_64.rpm
> > postgresql-debuginfo-8.2.7-1PGDG.rhel4.x86_64.rpm
>
> Do those *exactly* match the versions of the Postgres RPMs you're
> using?

I got them from the same directory as the rest of the 8.2.7 RPMs I
downloaded.

I am going to try uninstalling the RPMs and using the Source RPMS and
report back. There is no production data yet since I am working on testing
the machine and creating some benchmarks so I can redo the entire setup as
needed.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [pgsql-es-ayuda] sobre ALTER TABLE

On Wed, May 28, 2008 at 10:28 AM, MIGUEL CANCHAS <mcanchas@tsr.com.pe> wrote:
> no seria mejor crear una columna con el tipo de dato que necesita y
> adicionarle los datos "casteados" desde la columna a "dropear"
>

y como harias el cast? si eres capaz de "castearlos" entonces puedes
usar la clausula USING del ALTER TABLE ... ALTER ... TYPE para hacer
el trabajo, sin columnas adicionales ni drops


--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 087171157
--
TIP 7: no olvides aumentar la configuración del "free space map"

Re: [pgsql-es-ayuda] PostgreSQL en Chile, jornadas

Desconozco, sinceramente me llego la nota y la comparti con el grupo.

Quizas Alvaro o alguno de los chicos de Chile nos pueda dar una idea

Saludos!
gb.-

On Wed, May 28, 2008 at 6:08 AM, Marcos Saldivar
<baron.rojo.cuerdas.de.acero@gmail.com> wrote:
> El día 28 de mayo de 2008 8:52, Guido Barosio <gbarosio@gmail.com> escribió:
>> FYI
>>
>> http://www.transmedia.cl/noticia12=id270508.htm
>
> entrada liberada ?
>
>>
>> --
>> Guido Barosio
>> -----------------------
>> http://www.globant.com
>> guido.barosio@globant.com
>> --
>> TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net
>>
>

--
Guido Barosio
-----------------------
http://www.globant.com
guido.barosio@globant.com
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

Re: [pgsql-es-ayuda] Uso de ora2pg

2008/5/28 Richard Velasquez <rjvelasq@gmail.com>:

> Can't locate String/Random.pm in @INC (@INC contains: D:/Perl/site/lib
> D:/Perl/lib .) at Ora2Pg.pm line 1041.

Debes instalar el módulo "String::Random"[1]. Supongo que tienes el
perl de Activestate y este debe tener alguna herramienta automatizada
para este proceso. Lo siento, no puedo ser más específico porque no
uso perl en win.

> Si algunos de ustedes tiene documentación sobre el uso de éste script le
> agradezco enviármela por favor.

Y del perl supongo ;)

--
Saludos,
PP

[1] http://search.cpan.org/~steve/String-Random-0.22/lib/String/Random.pm
--
TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

[DOCS] psqlODBC homepage bad link on http://www.postgresql.org/docs/8.2/static/external-interfaces.html

http://odbc.postgresql.org/ no longer exists?

----
James Robinson
Socialserve.com


--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

RE: [pgsql-es-ayuda] sobre ALTER TABLE

no seria mejor crear una columna con el tipo de dato que necesita y
adicionarle los datos "casteados" desde la columna a "dropear"

Miguel Canchas

-----Mensaje original-----
De: Marcos Saldivar [mailto:baron.rojo.cuerdas.de.acero@gmail.com]
Enviado el: Miércoles, 28 de Mayo de 2008 10:25 a.m.
Para: Jaime Casanova
CC: Mario Reyes (GENESYS); pgsql-es-ayuda@postgresql.org
Asunto: Re: [pgsql-es-ayuda] sobre ALTER TABLE


2008/5/28 Jaime Casanova <systemguards@gmail.com>:
> On Wed, May 28, 2008 at 8:22 AM, Marcos Saldivar
> <baron.rojo.cuerdas.de.acero@gmail.com> wrote:
>> 2008/5/28 Jaime Casanova <systemguards@gmail.com>:
>>> On Tue, May 27, 2008 at 11:00 PM, Mario Reyes (GENESYS)
>>> <Genesys3@celulosa.cmpc.cl> wrote:
>>>>
>>>> ALTER TABLE "public"."presupuestos" ALTER COLUMN "pres_fecha_inicio"
TYPE
>>>> DATE;
>>>>
>>>> ERROR: column "pres_fecha_inicio" cannot be cast to type "date"
>>>>
>>>> La pregunta por lo tanto es Cual es la manera correcta de hacer el
Cast?. He
>>>> intentado con el USING de acuerdo a la documentación.
>>>>
>>>> ALTER TABLE "public"."presupuestos" ALTER COLUMN "pres_fecha_inicio"
TYPE
>>>> date USING "pres_fecha_inicio"::date;
>>>>
>>>> Sin embargo aparece otro error:
>>>> ERROR: cannot cast type time without time zone to date
>>>> (0,547 sec)
>>>>
>>>
>>> Si en esa columna aun no has grabado ningun dato, puedes hacer:
>>> ALTER TABLE "public"."presupuestos"
>>> ALTER COLUMN "pres_fecha_inicio" TYPE date USING NULL;
>>>
>>> Si ya hay datos, ahi si esta fregada la cosa...
>>
>> por qué ? acaso no puede hacer un simple drop de esa columna ?
>
> si, se puede...
> pero el ALTER TABLE tambien funciona con el USING NULL aunque tenga
> datos la columna, pero pierde los datos
>
>> imagino que si necesita un date, no puede tener mas que poca valides
>> la info de esa columna si es time
>
> ese es mi punto, esos datos son como poco no validos y seguramente no
> habra forma segura o confiable de recuperarlos como date... en otras
> palabras que ya los perdio...

entonces que use lo que le recomiendas que es mucho mas elegante que
lo que hacia yop de un drop column y luego un add column je je je

ALTER TABLE "public"."presupuestos" ALTER COLUMN "pres_fecha_inicio"
TYPE date USING NULL;

saludos.-

>
>
> --
> Atentamente,
> Jaime Casanova
> Soporte y capacitación de PostgreSQL
> Guayaquil - Ecuador
> Cel. (593) 087171157
>
--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?

http://archives.postgresql.org/pgsql-es-ayuda
--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

Re: [pgsql-es-ayuda] sobre ALTER TABLE

2008/5/28 Jaime Casanova <systemguards@gmail.com>:
> On Wed, May 28, 2008 at 8:22 AM, Marcos Saldivar
> <baron.rojo.cuerdas.de.acero@gmail.com> wrote:
>> 2008/5/28 Jaime Casanova <systemguards@gmail.com>:
>>> On Tue, May 27, 2008 at 11:00 PM, Mario Reyes (GENESYS)
>>> <Genesys3@celulosa.cmpc.cl> wrote:
>>>>
>>>> ALTER TABLE "public"."presupuestos" ALTER COLUMN "pres_fecha_inicio" TYPE
>>>> DATE;
>>>>
>>>> ERROR: column "pres_fecha_inicio" cannot be cast to type "date"
>>>>
>>>> La pregunta por lo tanto es Cual es la manera correcta de hacer el Cast?. He
>>>> intentado con el USING de acuerdo a la documentación.
>>>>
>>>> ALTER TABLE "public"."presupuestos" ALTER COLUMN "pres_fecha_inicio" TYPE
>>>> date USING "pres_fecha_inicio"::date;
>>>>
>>>> Sin embargo aparece otro error:
>>>> ERROR: cannot cast type time without time zone to date
>>>> (0,547 sec)
>>>>
>>>
>>> Si en esa columna aun no has grabado ningun dato, puedes hacer:
>>> ALTER TABLE "public"."presupuestos"
>>> ALTER COLUMN "pres_fecha_inicio" TYPE date USING NULL;
>>>
>>> Si ya hay datos, ahi si esta fregada la cosa...
>>
>> por qué ? acaso no puede hacer un simple drop de esa columna ?
>
> si, se puede...
> pero el ALTER TABLE tambien funciona con el USING NULL aunque tenga
> datos la columna, pero pierde los datos
>
>> imagino que si necesita un date, no puede tener mas que poca valides
>> la info de esa columna si es time
>
> ese es mi punto, esos datos son como poco no validos y seguramente no
> habra forma segura o confiable de recuperarlos como date... en otras
> palabras que ya los perdio...

entonces que use lo que le recomiendas que es mucho mas elegante que
lo que hacia yop de un drop column y luego un add column je je je

ALTER TABLE "public"."presupuestos" ALTER COLUMN "pres_fecha_inicio"
TYPE date USING NULL;

saludos.-

>
>
> --
> Atentamente,
> Jaime Casanova
> Soporte y capacitación de PostgreSQL
> Guayaquil - Ecuador
> Cel. (593) 087171157
>
--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?

http://archives.postgresql.org/pgsql-es-ayuda

Re: [pgsql-es-ayuda] Capturar transacciones durante un día

2008/5/28 Raul Andres Duque <ra_duque@yahoo.com.mx>:
> 4. Capturar TODAS las operaciones lectura/escritura realizadas por ejemplo
> durante un día.

Lo mejor que puedes hacer poner log_statement = all en
postgresql.conf, esto registrara en el log todas las sentencias
excepto las que tengan error de sintaxis... quiza se te facilite las
cosas si envias el log en formato cvs y lo subes a una tabla (esto es
posible desde 8.3)
http://www.postgresql.org/docs/current/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-CSVLOG

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 087171157
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

[COMMITTERS] pgsql: Set hidden field for guc enum missed in previous commit.

Log Message:
-----------
Set hidden field for guc enum missed in previous commit.

Modified Files:
--------------
pgsql/src/backend/access/transam:
xlog.c (r1.311 -> r1.312)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xlog.c?r1=1.311&r2=1.312)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [HACKERS] Remove redundant extra_desc info for enum GUC variables?

Magnus Hagander <magnus@hagander.net> writes:
> Tom Lane wrote:
>> Yeah: LOG level sorts differently in the two cases; it's fairly high
>> priority for server log output and much lower for client output.

> Ok, easy fix if we break them apart. Should we continue to accept
> values that we're not going to care about, or should I change that at
> the same time? (for example, client_min_messages doesn't use INFO,
> but we do accept that in <= 8.3 anyway)

I'd be inclined to keep the actual behavior the same as it was.
We didn't document INFO for this variable, perhaps, but it's accepted
and has a well-defined behavior.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Add dblink function to check if a named connection exists

Tommy Gildseth <tommy.gildseth@usit.uio.no> writes:
> One obvious disadvantage of this approach, is that I need to connect and
> disconnect in every function. A possible solution to this, would be
> having a function f.ex dblink_exists('connection_name') that returns
> true/false depending on whether the connection already exists.

Can't you do this already?

SELECT 'myconn' = ANY (dblink_get_connections());

A dedicated function might be a tad faster, but it probably isn't going
to matter compared to the overhead of sending a remote query.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[pgsql-es-ayuda] Uso de ora2pg

Buenos Días

Estoy probando el script ora2pg para hacer migración de esquemas de bd oracle a postgres y me da el siguiente error

Can't locate String/Random.pm in @INC (@INC contains: D:/Perl/site/lib D:/Perl/lib .) at Ora2Pg.pm line 1041.
BEGIN failed--compilation aborted at Ora2Pg.pm line 1041.
Compilation failed in require at ora2pg.pl line 16.
BEGIN failed--compilation aborted at ora2pg.pl line 16.

Si algunos de ustedes tiene documentación sobre el uso de éste script le agradezco enviármela por favor.


Saludos,

Atte,

Richard Velásquez
Venezuela.

Re: [pgsql-es-ayuda] sobre ALTER TABLE

On Wed, May 28, 2008 at 8:22 AM, Marcos Saldivar
<baron.rojo.cuerdas.de.acero@gmail.com> wrote:
> 2008/5/28 Jaime Casanova <systemguards@gmail.com>:
>> On Tue, May 27, 2008 at 11:00 PM, Mario Reyes (GENESYS)
>> <Genesys3@celulosa.cmpc.cl> wrote:
>>>
>>> ALTER TABLE "public"."presupuestos" ALTER COLUMN "pres_fecha_inicio" TYPE
>>> DATE;
>>>
>>> ERROR: column "pres_fecha_inicio" cannot be cast to type "date"
>>>
>>> La pregunta por lo tanto es Cual es la manera correcta de hacer el Cast?. He
>>> intentado con el USING de acuerdo a la documentación.
>>>
>>> ALTER TABLE "public"."presupuestos" ALTER COLUMN "pres_fecha_inicio" TYPE
>>> date USING "pres_fecha_inicio"::date;
>>>
>>> Sin embargo aparece otro error:
>>> ERROR: cannot cast type time without time zone to date
>>> (0,547 sec)
>>>
>>
>> Si en esa columna aun no has grabado ningun dato, puedes hacer:
>> ALTER TABLE "public"."presupuestos"
>> ALTER COLUMN "pres_fecha_inicio" TYPE date USING NULL;
>>
>> Si ya hay datos, ahi si esta fregada la cosa...
>
> por qué ? acaso no puede hacer un simple drop de esa columna ?

si, se puede...
pero el ALTER TABLE tambien funciona con el USING NULL aunque tenga
datos la columna, pero pierde los datos

> imagino que si necesita un date, no puede tener mas que poca valides
> la info de esa columna si es time

ese es mi punto, esos datos son como poco no validos y seguramente no
habra forma segura o confiable de recuperarlos como date... en otras
palabras que ya los perdio...


--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 087171157
--
TIP 5: ¿Has leído nuestro extenso FAQ?

http://www.postgresql.org/docs/faqs.FAQ.html

Re: [GENERAL] Open Source CRM - Options?

kaloyan@digsys.bg (Kaloyan Iliev) writes:
> And what about RT (Request Tracker - http://bestpractical.com/rt/)
> .
> AFAIK it is free and open-source, uses Postgres and is easy to setup.

RT has a very different purpose; it was designed to track work (e.g. -
"work tickets"), as opposed to managing web site content.

It *might* be used as a bug tracker, though with a considerably
different flavour from (say) Bugzilla; as a CRM, it would be pretty
unsuitable :-(.
--
output = reverse("moc.enworbbc" "@" "enworbbc")
http://cbbrowne.com/info/lisp.html
"Listen, strange women, lyin' in ponds, distributin' swords, is no
basis for a system of government. Supreme executive power derives
itself from a mandate from the masses, not from some farcical aquatic
ceremony." -- Monty Python and the Holy Grail

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Psql crashes with Segmentation fault on copy from

"Francisco Reyes" <lists@stringsutils.com> writes:
> (gdb) bt
> #0 0x0000003cc31723e6 in memcpy () from /lib64/tls/libc.so.6
> #1 0x000000364bf0e0ae in PQunescapeBytea () from /usr/lib64/libpq.so.5
> #2 0x000000364bf0e230 in PQunescapeBytea () from /usr/lib64/libpq.so.5
> #3 0x000000364bf0c09e in PQsendQuery () from /usr/lib64/libpq.so.5
> #4 0x000000364bf0c788 in PQexec () from /usr/lib64/libpq.so.5
> #5 0x0000000000406e95 in ?? ()
> #6 0x0000000000409dfa in ?? ()
> #7 0x000000000040408d in ?? ()

> Is that what you need?

Well, it would be if it were right; but PQsendQuery doesn't call
PQunescapeBytea, so there's something wrong with the debug info.
(The fact that we're not seeing any parameter values is another
tip that it's not right. Apparently gdb doesn't think the debuginfo
matches at all.)

> I installed
> compat-postgresql-libs-debuginfo-3-2PGDG.rhel4.x86_64.rpm
> postgresql-debuginfo-8.2.7-1PGDG.rhel4.x86_64.rpm

Do those *exactly* match the versions of the Postgres RPMs you're
using?

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [pgus-board] Feedback on draft bylaws

Michael Alan Brewer wrote:
> Other than Josh Berkus, has anyone else yet chimed in on the review
> bylaws? Admittedly, we're in a short work week (plus the week after
> PgCon); do we need to poke announce or planet?

To my knowledge we have only received feedback from Josh Berkus. I don't
think we should poke planet but perhaps a small email that is not part
of the existing thread as a reminder would be good.

Sincerely,

Joshua D. Drake


--
Sent via pgus-board mailing list (pgus-board@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgus-board

Re: [GENERAL] Psql crashes with Segmentation fault on copy from

On 6:28 pm 05/27/08 Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Can you get us a stack trace from the crash?

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182894175648 (LWP 4487)]
0x0000003cc31723e6 in memcpy () from /lib64/tls/libc.so.6
(gdb) bt
#0 0x0000003cc31723e6 in memcpy () from /lib64/tls/libc.so.6
#1 0x000000364bf0e0ae in PQunescapeBytea () from /usr/lib64/libpq.so.5
#2 0x000000364bf0e230 in PQunescapeBytea () from /usr/lib64/libpq.so.5
#3 0x000000364bf0c09e in PQsendQuery () from /usr/lib64/libpq.so.5
#4 0x000000364bf0c788 in PQexec () from /usr/lib64/libpq.so.5
#5 0x0000000000406e95 in ?? ()
#6 0x0000000000409dfa in ?? ()
#7 0x000000000040408d in ?? ()
#8 0x00000000004057cd in ?? ()
#9 0x0000000000406286 in ?? ()
#10 0x0000000000409f66 in ?? ()
#11 0x000000000040408d in ?? ()
#12 0x00000000004057cd in ?? ()
#13 0x0000000000406286 in ?? ()
#14 0x0000000000409f66 in ?? ()
#15 0x000000000040c687 in ?? ()
#16 0x0000003cc311c3fb in __libc_start_main () from /lib64/tls/libc.so.6
#17 0x0000000000403d2a in ?? ()
#18 0x0000007fbffff558 in ?? ()
#19 0x000000000000001c in ?? ()
#20 0x0000000000000001 in ?? ()
#21 0x0000007fbffff795 in ?? ()
#22 0x0000000000000000 in ?? ()

Is that what you need?
I installed
compat-postgresql-libs-debuginfo-3-2PGDG.rhel4.x86_64.rpm
postgresql-debuginfo-8.2.7-1PGDG.rhel4.x86_64.rpm

What is compat-postgresql-libs-debuginfo?
Neither of those two RPMs are described in the RPM install PDF by Devrim
and Lamar.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] Capturar transacciones durante un día

--------------------------------------------------
From: "Marcos Saldivar" <baron.rojo.cuerdas.de.acero@gmail.com>
Sent: Wednesday, May 28, 2008 8:43 AM
To: "Raul Andres Duque" <ra_duque@yahoo.com.mx>
Cc: <pgsql-es-ayuda@postgresql.org>
Subject: Re: [pgsql-es-ayuda] Capturar transacciones durante un día

> El día 28 de mayo de 2008 9:30, Raul Andres Duque
> <ra_duque@yahoo.com.mx> escribió:
>> Cordial Saludo.
>>
>> Quisiera generar unos benchmarks de mi base de datos pero generado a
>> partir
>> de por ejemplo las operaciones realizadas durante un día. Mi idea es:
>>
>> 1. Restringir la conexiones (asegurar que NADIE modifique mi DB)
>> 2. Generar un backup full de la DB.
>> 3. Habilitar nuevamente las conexiones a mi DB de producción
>> 4. Capturar TODAS las operaciones lectura/escritura realizadas por
>> ejemplo
>> durante un día.
>> 5. Restaurar una copia de mi DB original.
>> 6. Ejecutar las mismas operaciones en el backup restaurado de mi DB
>> original
>> (midiendo tiempos).
>> 7. Cambiar configuración de mi DB
>> 8. Repetir los pasos 4-6 para las pruebas que quiera realizar.
>>
>> La ayuda que pido es qué herramientas podrían ayudarme en mi tarea.
>>
>> De inicio tengo estas pregunta:
>>
>> ¿Cómo puedo capturar las operaciones realizadas por la DB de una forma
>> más
>> adecuada para ser reproducida/ejecutada que la que me suministra el log
>> de
>> postgresql (me tocaría quitar las columnas de fecha/hora y hacer otras
>> cosillas para dejarlo de forma adecuada para ser ejecutada por el psql).?
>>
>> ¿Qué herramienta me podría ayudar en la generación de estadísticas o
>> tabulación de los tiempos de respuesta obtenidos en las operaciones, por
>> ejemplo dividiéndolas por escrituras/lecturas, por tabla, por ubndices,
>> seqscan, por tiempo de ejecucción ,etc?
>>
>> Espero que mi idea no sea muy loca que digamos ... pero más o menos así
>> es
>> que trabaja el PERFORMANCE ADVISOR DE MSSQL.
>
> me quedo la duda si esto lo vas hacer en un db de producción ? porque
> para mi inocente cabecita y inexperta, esto es demasiado arriesgado de
> bajar conexiones hacer dump y restaurar una db en producción...
>
> saludos.-
>
> ps: porque no partir de algo mas sencillo como un catastro de todas
> las query's que hace el o los sistemas y partir por ahí o partir por
> donde los usuarios reclaman ???
>

No .. la idea es hacer en una DB de pruebas (apartir de una Db de producción
restaurada)..

Esta bien lo que dices, sin embargo mi prueba va tambien a ver el efecto de
diferentes cambios de configuración, por lo que require que se reproduzca
TODA la aoperación para que las operaciones sea consistentes.

Atentamente,

RAUL DUQUE
Bogotá, Colombia

>>
>> Gracias.
>>
>> Atentamente,
>>
>> RAUL DUQUE
>> Bogotá, Colombia
>
> __________ Information from ESET Smart Security, version of virus
> signature database 3139 (20080528) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>
>
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

[ADMIN] psql var ON_ERROR_ROLLBACK effect in pg_restore

Hello list,
I don't found anything about that in the archives, so...
I need to restore an binary backup that is generating errors.
The pg_restore utility is doing a rollback when he found errors.
Can i stop this?
With the psql utility i just set the ON_ERROR_ROLLBACK to get this effect.
Is that possible?
Sorry about my bad english.

--
Álvaro Guimarães
Santa Bárbara D'Oeste - SP - Brazil

Re: [HACKERS] pg_regress: dbname in PostgreSQL test suite

Jorgen Austvik - Sun Norway wrote:
> Hi.
>
> pg_regress has a --dbname option (which actually take a list of
> database names):
>
> --dbname=DB use database DB (default \"regression\")
>
> ... but the PostgreSQL regression test suite does not really support
> this:
>
> [jaustvik@host:regress] ggrep -R "regression" sql/* | grep -v
> regression_ | grep -v :--
> sql/prepare.sql:EXECUTE q2('regression');
> sql/privileges.sql:\c regression
> sql/temp.sql:\c regression
>
> I suggest we replace @dbname@ with the first element in the dblist
> linked list in convert_sourcefiles_in(). What do you think?
>
> (I can provide a patch if you think it is an acceptable solution.)
>
>

We have more than one set of regression tests. This feature is used by
the PL regression tests and the contrib regression tests to run using a
different database name.

I'm not quite sure why it's a list.

cheers

andrew

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [COMMITTERS] pgsql: Add a field to guc enums to allow hiding of values from display

Tom Lane wrote:
> mha@postgresql.org (Magnus Hagander) writes:
> > Add a field to guc enums to allow hiding of values from display
> > while still accepting them as input, used to allow alternate syntax
> > for the same setting.
>
> Aren't there some config_enum_entrys elsewhere (like xlog.c)?
> I think they'd default to false, but still it'd be better practice
> to fill them in.

Hmm. I thought I was going to get warnings if I missed any, but it
seems not. Will fix.

//Magnus

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [HACKERS] pg_regress: dbname in PostgreSQL test suite

Jorgen Austvik - Sun Norway <Jorgen.Austvik@Sun.COM> writes:
> pg_regress has a --dbname option (which actually take a list of database
> names):

> --dbname=DB use database DB (default \"regression\")

> ... but the PostgreSQL regression test suite does not really support this:

That option is intended for running other sets of regression tests
(eg, the contrib ones are customarily run in contrib_regression).
I see zero value in trying to make the standard tests run under
some other database name.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_regress: referencing shared objects from tests

Jorgen Austvik - Sun Norway <Jorgen.Austvik@Sun.COM> writes:
> we would like to be able to use and ship pg_regress and the PostgreSQL
> test suite independently of the PostgreSQL build environment, for
> testing and maybe even as a separate package to be build and shipped
> with the OS for others to test their setup. Does this sound like a sane
> and OK thing to do?

The RPM packages have done this since approximately forever. You might
want to look at the patches used there.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [JDBC] How embarrassing: optimization of a one-shot query doesn't work

Dave Cramer <pg@fastcrypt.com> writes:
> On 23-May-08, at 9:20 AM, Tom Lane wrote:
>> There was some discussion a week or so back about scheduling a set of
>> releases in early June, but it's not formally decided.

> Now that PGCon is over has there been any more discussion ?

Yeah, I just posted an announcement about it on -hackers.

regards, tom lane

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: [COMMITTERS] pgsql: Add a field to guc enums to allow hiding of values from display

mha@postgresql.org (Magnus Hagander) writes:
> Add a field to guc enums to allow hiding of values from display while
> still accepting them as input, used to allow alternate syntax for the
> same setting.

Aren't there some config_enum_entrys elsewhere (like xlog.c)?
I think they'd default to false, but still it'd be better practice
to fill them in.

regards, tom lane

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [torontopug] Toronto PU[GB]

The mailing list should be up real soon now(TM), and I should become
the admin as well. In the meantime, the archives appear to be up now,
which is how I found out I still appear to be not subscribed:

http://archives.postgresql.org/torontopug/

Thanks for putting together that table Steve. I'd just like to add
that there are Rails nights on the second Tuesday and third Monday's
of the month. I agree that we should try and stick to early week as
well. Based on what we've got so far, how does the 4th Monday of the
month sound? The chance of it falling on a holiday is pretty low,
except for Christmas (around which people are pretty busy anyways). It
doesn't appear to conflict with anything that I can find.

~Ian

On Tue, May 27, 2008 at 10:48 PM, Steve Singer <ssinger_pg@sympatico.ca> wrote:
>
> On Tue, 27 May 2008, [utf-8] Jonathan Fuerth wrote:
>
> I looked at some of the local user groups with regularly scheduled meetings. That second week is already pretty active. I also suspect pubs will be more accomidating on a Monday,Tuesday or Wednesday.
>
> M T W T F
> 1 J
> 2 A L U
> 3 P B
> 4 p
>
> p=Perl
> P=Python
> J=Java User group
> L=Toronto Lug
> U=Unix Unanimous
> B=gtabug
> A=Ajax pub night
> Ruby: Second sunday of each month
>
> http://gtalug.org/wiki/Other_Opensource_Computing_groups
> http://www.geekstreet.ca/usergroups.php
>
>> To throw out another option, I've been attending GTABUG regularly for years. We've had a great experience at Olympic 76 Pizza (near Yonge and Bloor). Friendly staff, good pizza, and 3 kinds of beer on tap. GTABUG meets there on the 3rd Wednesday of evey month. A number of GTABUG regulars are PostgreSQL enthusiasts.
>>
>> There's also a long-standing group, "Unix Unanimous," that meets on the second Wednesday of the month. They start the evening in a small lecture room at UofT, then go for dinner as a group at a restaurant near Bloor and Spadina. I bring this up because a number of PostgreSQL enthusiasts also regularly attend that meeting.
>>
>> -Jonathan

--
Sent via torontopug mailing list (torontopug@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/torontopug

[HACKERS] pg_regress: dbname in PostgreSQL test suite

begin:vcard
fn;quoted-printable:J=C3=B8rgen Austvik
n;quoted-printable:Austvik;J=C3=B8rgen
org:Sun Microsystems;Database Group
adr:;;Haakon VII gt. 7b;Trondheim;;NO-7485;Norway
email;internet:jorgen.austvik@sun.com
title:Senior Engineer
tel;work:+47 73 84 21 10
tel;fax:+47 73 84 21 01
tel;cell:+47 901 97 886
note:http://www.austvik.net/
x-mozilla-html:FALSE
url:http://blogs.sun.com/austvik/
version:2.1
end:vcard

Hi.

pg_regress has a --dbname option (which actually take a list of database
names):

--dbname=DB use database DB (default \"regression\")

... but the PostgreSQL regression test suite does not really support this:

[jaustvik@host:regress] ggrep -R "regression" sql/* | grep -v
regression_ | grep -v :--
sql/prepare.sql:EXECUTE q2('regression');
sql/privileges.sql:\c regression
sql/temp.sql:\c regression

I suggest we replace @dbname@ with the first element in the dblist
linked list in convert_sourcefiles_in(). What do you think?

(I can provide a patch if you think it is an acceptable solution.)

-J
--

Jørgen Austvik, Software Engineering - QA
Sun Microsystems Database Group

http://blogs.sun.com/austvik/
http://www.austvik.net/

[HACKERS] Upcoming back-branch update releases

Yup, we're overdue for that, so:

After some discussion among core and the packagers list, we have
tentatively set June 9 as the release date for minor updates of
all supported PG release branches (back to 7.4). As has been the
recent practice, code freeze will occur the preceding Thursday, June 5.

If you've got any bug fixes you've been working on, now is a good time
to get them finished up and sent in...

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[pgsql-es-ayuda] Instalacion desatendida

Saludos al grupo.
Esta vez tengo una pregunta, aunque no meramente de SQL, sino de instalación desatendida.
Como puedo especificar los parámetros para que Postgres se auto instale es decir, que el usuario no tenga que digitar ninguna información sino que yo las establezca.
 
Gracias.


Ing. Eris J. Gómez
Racol Computers, C x A.
Símbolo de calidad en software.
Av. 27 de febrero #37, Villa Progreso
Santiago de los Caballeros, República Dominicana
Tel.: (809) 971-3157, Fax: (809) 582-6636
Email: racolsoftware@hotmail.com

Tuesday, May 27, 2008

Re: [pgsql-advocacy] swik.net is copying planetpostgresql content

On Tue, 27 May 2008 09:20:21 -0700 Joshua D. Drake wrote:
> On Tue, 2008-05-27 at 09:13 -0700, Josh Berkus wrote:
> > JD,
> >
> > > They are in my neck of the woods, possibly a nice phone call would
> > > resolve the whole issue.
> >
> > Sure. I'm just not sure there *is* an issue.
> >
>
> Well there is an issue, it just may not be a problem :). It may just be
> one of clarification.

Yeah.


> > As far as I can tell, they are just re-broadcasting *publically available RSS
> > feeds* (which is what RSS feeds are for, no?). If there is any problem (and
> > I'm not convinced there is) it's just that their copyright statement is
> > unclear.
>
> Right.

I would not name it "re-broadcasting" because of all the work they have
done to integrate the content into the wiki but basically that's it.

So i'm also +1 for politely asking.

By the way: RSS feeds are for read, not for republish the content
without permission. I granted Devrim the right to publish parts of my
blog on planetpg, but i can't remember that i or most of the other
planet posters did include the permission for other usage.


Kind regards

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group

--
Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy

Re: [pgsql-fr-generale] Drupal, CMS avec PG

Francis Leboutte a écrit :
> Merci pour ces infos utiles et d'avance pour celles concernant le réflexion PGFR.
>
> Je suis dubitatif quant à l'utilisation d'un Wiki pour certains projets, par exemple pour ceux où une certaine ligne éditoriale doit être maintenue et l'information n'est pas aussi simple à structurer que dans un projet comme Wikipédia.
>
> Ce serait intéressant de faire une comparaison point par point en fonction des besoins. Dès que j'ai un peu de temps, je ferai une recherche sur le web (EN, FR) pour voir si quelque chose n'a pas été fait sur le sujet.
>
> Cordialement,
>
> Francis

Bonjour,

Pour comparer les Wiki ou les CMS entre eux, en terme de fonctionnalités, vous
pouvez vous rendre sur wikimatrix.org et cmsmatrix.com

Bon courage :-)

Librement,
--
Stéphane SCHILDKNECHT
Président de PostgreSQLFr
Tél. 09 53 69 97 12
http://www.postgresql.fr

--
Sent via pgsql-fr-generale mailing list (pgsql-fr-generale@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-fr-generale

[HACKERS] Hiding undocumented enum values?

There are several GUC enums that accept values that aren't documented
anywhere; the worst offender being backslash_quote, which has more
undocumented spellings than documented ones:

/*
* Although only "on", "off", and "safe_encoding" are documented, we
* accept all the likely variants of "on" and "off".
*/
static const struct config_enum_entry backslash_quote_options[] = {
{"safe_encoding", BACKSLASH_QUOTE_SAFE_ENCODING},
{"on", BACKSLASH_QUOTE_ON},
{"off", BACKSLASH_QUOTE_OFF},
{"true", BACKSLASH_QUOTE_ON},
{"false", BACKSLASH_QUOTE_OFF},
{"yes", BACKSLASH_QUOTE_ON},
{"no", BACKSLASH_QUOTE_OFF},
{"1", BACKSLASH_QUOTE_ON},
{"0", BACKSLASH_QUOTE_OFF},
{NULL, 0}
};

I am wondering if it's a good idea to hide the redundant entries
to reduce clutter in the pg_settings display. (We could do this
by adding a "hidden" boolean to struct config_enum_entry.)
Thoughts?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [pgsql-advocacy] swik.net is copying planetpostgresql content

On Tue, 2008-05-27 at 09:13 -0700, Josh Berkus wrote:
> JD,
>
> > They are in my neck of the woods, possibly a nice phone call would
> > resolve the whole issue.
>
> Sure. I'm just not sure there *is* an issue.
>

Well there is an issue, it just may not be a problem :). It may just be
one of clarification.

> As far as I can tell, they are just re-broadcasting *publically available RSS
> feeds* (which is what RSS feeds are for, no?). If there is any problem (and
> I'm not convinced there is) it's just that their copyright statement is
> unclear.

Right.

Sincerely,

Joshua D. Drake

--
Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy

Re: [pgsql-advocacy] swik.net is copying planetpostgresql content

JD,

> They are in my neck of the woods, possibly a nice phone call would
> resolve the whole issue.

Sure. I'm just not sure there *is* an issue.

As far as I can tell, they are just re-broadcasting *publically available RSS
feeds* (which is what RSS feeds are for, no?). If there is any problem (and
I'm not convinced there is) it's just that their copyright statement is
unclear.

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

--
Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy

[COMMITTERS] pgsnap - pgsnap: Bugfix : on "Installed Products" report, pgsnap didn't

Log Message:
-----------
Bugfix : on "Installed Products" report, pgsnap didn't understand "unset" value, and logging_collector
was used instead of stats_start_collector for releases < 8.3.

Tags:
----
REL0_3_STABLE

Modified Files:
--------------
pgsnap/pgsnap:
ChangeLog (r1.33.2.1 -> r1.33.2.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgsnap/pgsnap/pgsnap/ChangeLog.diff?r1=1.33.2.1&r2=1.33.2.2)
pgsnap/pgsnap/lib:
ver.php (r1.8 -> r1.8.2.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgsnap/pgsnap/pgsnap/lib/ver.php.diff?r1=1.8&r2=1.8.2.1)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [PATCHES] Doc patch: type modifiers

Jeff Davis <pgsql@j-davis.com> writes:
> From
> http://developer.postgresql.org/pgdocs/postgres/sql-createtype.html :
> type_modifier_input_function
> The name of a function that converts numeric modifier(s) for the
> type into internal form.

Yeah, this text is a holdover from the original user-definable-modifiers
patch, in which the modifiers indeed had to be numbers. I don't quite
like your suggestion of using "textual", though, because that makes it
sound like the input and output functions are exact inverses, which they
are not. How about "... converts an array of modifier(s) for ..."?

regards, tom lane

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [SQL] Enumerated (enum) types

In article <5ac667b80805270729x4f93cc14n4a868d3d3f624d7b@mail.gmail.com>,
"Michael Lourant" <lourant@gmail.com> writes:

> Type Safety

> Enumerated types are completely separate data types and may not be compared
> with each other.

...

> An Alternative Way To Do The Same

> Instead of using an enum type we can set up a CHECK CONSTRAINT - this tells
> postgresql to make sure that the value we are entering is valid.

> CREATE TABLE person (
> personid int not null primary key,
> favourite_colour varchar(255) NOT NULL,
> CHECK (favourite_colour IN ('red', 'blue', 'yellow', 'purple'))

> );

> INSERT INTO person(personid, favourite_colour) VALUES (1, 'red');
> INSERT 0 1

> Now for something not in the list:

> INSERT INTO person(personid, favourite_colour) VALUES (2, 'green');
> ERROR: new row for relation "person" violates check constraint "person_favourite_colour_check"

Type safety is the thing you lose by replacing an ENUM by a CHECK
constraint - you can still do something nonsensical like

SELECT * FROM person WHERE favourite_colour = 'green'


--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

Re: [pgsql-advocacy] swik.net is copying planetpostgresql content

> The alternative is to have SWiK not include PostgreSQL at all, which is not a
> good outcome for us. I think that we *might* send them a politely worded
> request to clarify their copyright statement (I'll be happy to do this).
> Beyond that, this seems like a real non-issue.

They are in my neck of the woods, possibly a nice phone call would
resolve the whole issue.

Sincerely,

Joshua D. Drake

--
Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy

Re: [pgsql-advocacy] swik.net is copying planetpostgresql content

+1

I've said something pretty similar though, or that was my intention at least :)

gb.-

On Tue, May 27, 2008 at 1:00 PM, Josh Berkus <josh@agliodbs.com> wrote:
> Folks,
>
> "Never attribute to malice what can be explained by stupidity or inattention."
>
> As far as I can tell, SWiK is guilty of nothing worse that sloppiness. I see
> absolutely no reason to assume that they are trying to do something sinister.
> What would be their motivation?
>
> Further, SWiK *does* link back to the original blogs. So some of the argument
> posted here has been based on false premises.
>
> The alternative is to have SWiK not include PostgreSQL at all, which is not a
> good outcome for us. I think that we *might* send them a politely worded
> request to clarify their copyright statement (I'll be happy to do this).
> Beyond that, this seems like a real non-issue.
>
> --
> Josh Berkus
> PostgreSQL @ Sun
> San Francisco
>
> --
> Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-advocacy
>

--
Guido Barosio
-----------------------
http://www.globant.com
guido.barosio@globant.com

--
Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy

Re: [ADMIN] v8.2.6->8.2.7 upgrade renamed /var/lib/pgsql

Yes, AFAIK, this machine is using the standard Fedora update repository.

I'll just chalk this up to "anomalous behaviour of unknown origin" and
add this to my test-after-updates checklist.

Thanks,

Gord


> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Sunday, May 25, 2008 7:38 PM
> To: Hyatt, Gordon
> Cc: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] v8.2.6->8.2.7 upgrade renamed /var/lib/pgsql
>
> "Hyatt, Gordon" <Gordon.Hyatt@joslin.harvard.edu> writes:
> > I just applied the v8.2.7 upgrade (from v8.2.6) on and FC8 server
via
> > yum. The upgrade went OK, but the /var/lib/pgsql directory (with
the
> > existing data) was renamed to /var/lib/pgsql.old and a new (and
empty)
> > /var/lib/pgsql directory was created.
>
> That's just weird. I tried the same here (also on an x86_64 F-8 box)
> and didn't see it happen. Are you using the standard Fedora update
> repository?
>
> regards, tom lane

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: [pgsql-advocacy] swik.net is copying planetpostgresql content

Folks,

"Never attribute to malice what can be explained by stupidity or inattention."

As far as I can tell, SWiK is guilty of nothing worse that sloppiness. I see
absolutely no reason to assume that they are trying to do something sinister.
What would be their motivation?

Further, SWiK *does* link back to the original blogs. So some of the argument
posted here has been based on false premises.

The alternative is to have SWiK not include PostgreSQL at all, which is not a
good outcome for us. I think that we *might* send them a politely worded
request to clarify their copyright statement (I'll be happy to do this).
Beyond that, this seems like a real non-issue.

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

--
Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy

[COMMITTERS] pgsnap - pgsnap: Bugfix : default report for statistics tab should be

Log Message:
-----------
Bugfix : default report for statistics tab should be the cache hit ratio
(old one, bgwriter, is not available in releases prior to 8.3)

Tags:
----
REL0_3_STABLE

Modified Files:
--------------
pgsnap/pgsnap:
ChangeLog (r1.33 -> r1.33.2.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgsnap/pgsnap/pgsnap/ChangeLog.diff?r1=1.33&r2=1.33.2.1)
pgsnap/pgsnap/template:
header.template.html (r1.5 -> r1.5.2.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgsnap/pgsnap/pgsnap/template/header.template.html.diff?r1=1.5&r2=1.5.2.1)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [BUGS] BUG #4203: perform dblink() in begin/exception returns wrong SQLSTATE code

"Henry Combrinck" <henry@zen.co.za> writes:
> Description: perform dblink() in begin/exception returns wrong
> SQLSTATE code

> The code returned is always 42601 (syntax_error) irrespective of the actual
> error (eg, unique_violation).

Yeah, the dblink code should probably try a bit harder to propagate the
original error fields. I'm inclined to think that it should propagate
sqlstate/message/detail/hint verbatim, and indicate the fact that this
happened on a dblink connection as CONTEXT, rather than structuring the
ereport the way it does now. Joe, what do you think?

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [pgsql-fr-generale] Drupal, CMS avec PG

Merci pour ces infos utiles et d'avance pour celles concernant le réflexion PGFR.

Je suis dubitatif quant à l'utilisation d'un Wiki pour certains projets, par exemple pour ceux où une certaine ligne éditoriale doit être maintenue et l'information n'est pas aussi simple à structurer que dans un projet comme Wikipédia.

Ce serait intéressant de faire une comparaison point par point en fonction des besoins. Dès que j'ai un peu de temps, je ferai une recherche sur le web (EN, FR) pour voir si quelque chose n'a pas été fait sur le sujet.

Cordialement,

Francis

Le 25/05/2008 20:19, damien clochard écrivait :
>Le Sunday 25 May 2008 16:29:28 Francis Leboutte, vous avez écrit :
>> Bonjour,
>>
>> En fouillant dans les archives de la liste j'ai trouvé quelques
>> commentaires sur Drupal qui est utilisé pour le site postgresqlfr.org. En
>> voici deux (datant de 2005) :
>>
>> « Alors pour faire pgfr.org j'ai opté pour Drupal, qui lui est un gros veau
>> bien lent, mais qui est relativement propre question code. »
>>
>> « Aujourd'hui, Drupal assure vraiment bien, mais est toujours un peu trop
>> lourd pour le processeur Géode que possède l'Open Brick sur lequel tourne
>> le site!! »
>>
>
>C'est un commentaire très vieux car cela fait au moins 3 ans que le site
>www.postgresqlfr.org ne tourne plus sur un processeur Geode. :-)
>
>Aujourd'hui le portail principal de postgresqlfr.org fonctionne sur un bi-pro
>3Ghz. La version de drupal que nous utilisons est une 4.7.x, c'est à dire une
>antiquité ( la version 6 vient de sortir )
>
>Une très grosse réflexion est en cours au sein de l'asso PGFR pour décider de
>l'avenir de la plate-forme. Le constat de départ est que notre version de
>drupal est obsolète. Par ailleurs après 5 ans d'existence, la masse d'
>information est tout simplement trop grande pour être gérée dans un CMS
>unique : les listes de diffusion, le wiki, la planete, la doc, ( probablement
>bientôt les forums) tout cela a fini par être hébergé en dehors de drupal.
>
>Je rédigerai un message plus détails sur ce sujet dans quelques jours.
>
>> Quant est-il de Drupal aujourd'hui ?
>
>D'après moi Drupal est un très bon CMS, très modulaire..
>
>Ce qu'on lui reproche c'est d'être extrèmement compliqué. Drupal introduit
>tout un tas de concepts ( "taxonomie", "noeud", "livre", etc. ) qu'il faut
>bien comprendre pour arriver a exploiter la puissance du logiciel.
>
>Le temps passe. Les administrateurs changent. Les connaissances se perdent.
>et si les concepts de base ont été mal transmis, on se retrouve avec une
>machine à gaz ingérable en l'espace de 3 ans.
>
>Tout ceci va l'encontre la tendance actuelle qui est de simplifier les
>interfaces (KISS !) et faciliter l'écriture pour un maximum de visiteurs des
>sites ( l'inénarrable web deux point zéro... ).
>
>Les wikis sont l'illustration parfaite de cette nouvelle tendance.
>
>Drupal , Joomla et consorts sont probablement des softs très puissants mais
>il s'avère que la simplicité est souvent plus importante que la puissance.
>
>En tout cas a titre personnel je suis convaincu que l'époque des
>gros "CMS-qui-savent-tout-faire" est révolue :-)
>
>
>> Notamment sur le point de vue performance ?
>
>Il y a deux ans environ on a vécu une augmentation de trafic . On est passsé
>de 110 000 à 170 000 pages vues par mois. Ceci a ralenti le site de manière
>significative. Après investigation on s'est rendu compte que le serveur
>PostgreSQL était bombardé de requêtes et avait du mal à suivre. La solution a
>consisté à intercaler un pooler de connexion (pgpool) entre drupal et
>postgresql...
>
>> Drupal s'est-il amélioré ?
>
>Aucune idée.
>Cédric Villemain a fait quelques recherches sur drupal 6. Peut-être qu'il
>pourra en dire plus. :-)
>
>> S'agit-il uniquement d'un problème de performance au moment de la création
>du contenu ?
>
>Non. Les données du site sont utilisées à 99,99% en lecture. La création de
>contenu n'est pas le soucis premier ;-)
>
>>
>> Quels sont les avantages et inconvénients de Drupal par rapport à SPIP,
>> très populaire en francophonie ?
>
>Je connais assez bien SPIP et à mon avis c'est une erreur de le considérer
>comme un CMS.
>SPIP est parfait pour gérer un journal en ligne, c'est à dire
>une équipe de rédacteurs , un comité de rélecture, et des droits de réponse en
>bas de chaque article.
>En dehors de cette organisation bien particulière, SPIP n'a pas beaucoup
>d'intérêt.
>
>Toute tentative de transformer SPIP en un CMS généraliste est une perte de
>temps. L'échec complet de SPIP-Agora en est la meilleure preuve.
>
>
>
>En résumé, Drupal est un bon logiciel mais son coté "couteau-suisse" est passé
>de mode. Les wikis sont des outils plus simples, plus conviviaux et plus
>ouverts. Dans la pluspart des cas, ils remplacent avantageusement les gros
>CMS comme Drupal
>
>
>bonne journée :)
>
>--
>damien clochard
>http://dalibo.org | http://dalibo.com
>
>--
>Sent via pgsql-fr-generale mailing list (pgsql-fr-generale@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-fr-generale


--
Sent via pgsql-fr-generale mailing list (pgsql-fr-generale@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-fr-generale

Re: [GENERAL] PL/R download

On 27 May 2008, at 13:47, Cindy Makarowsky wrote:

> Is the PL/R download still available? The link is dead from the
> Postgres site and also at www.joeconway.com.

Is there another
> location available to download the installer?
>

have you tried here:

http://www.joeconway.com/plr/

all the download links there still work for me ...

adam

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] XML Support related questions

Thanks Peter for your responses. I will try constraint for # 1 but I
think it
probably will still make sense to include that as part of XML column
definition.
I assume the default xml data type is of CONTENT type.

For #4 I was looking to be able to index some or all of the tags in the
xml document. Most of our applications query very few tags in a Xml
document
and a smaller index on few tags will help with query performance.

Any guess on timeframe for #2, #3 and #4?

Thanks,
Brijesh


-----Original Message-----
From: Peter Eisentraut [mailto:peter_e@gmx.net]
Sent: Saturday, May 24, 2008 4:32 AM
To: pgsql-general@postgresql.org
Cc: Brijesh Shrivastav
Subject: Re: [GENERAL] XML Support related questions

Am Donnerstag, 22. Mai 2008 schrieb Brijesh Shrivastav:
> 1) Can xml column be constrained to be DOCUMENT or CONTENT type?

Using a check constraint that does IS [NOT] DOCUMENT on the value.

> 2) Is there plan in near future to support XML schema validation
> i.e to ensure inserted xml document conforms to a preregistered set of
> XML schemas.

Plans yes, but I don't think anyone is working on it at the moment.

> 3) Support for XQuery - I know it is asking for too much but when
> do you see it happening in the future.

See #2.

> 4) Support for xml indexes - Is it something that is being worked
> upon for next release?

See #3. ;-) Of course this question is a bit underspecified, because
indexes
depend on some operators, and XML does not have any operators at the
moment,
so what do you want to index?


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] New MS patent: sounds like PG db rules

Here is the US patent offices website to
i copy and pasted the wrong link. opps
http://www.uspto.gov/web/offices/dcom/bpai/index.html

Justin wrote:


Andrew Sullivan wrote:
On Tue, May 27, 2008 at 02:18:31PM +0100, Dave Page wrote:    
I don't think it's a major issue. Even if MS do think we infringe on the patent it would be laughable for them to try to do anything about it given that our rules implementation has provably existed in a leading FOSS project for a decade or more.     
 Unfortuately, it would only be laughable until they sued someone (or, more likely, threatened to do) who was selling PosrgreSQL.  The problem in such cases is that proving your obvious prior art is an expensive undertaking.  The likely path for a targeted "infringer" is just to give up and either pay something to MS or else use some other engine that doesn't "infringe".  This is exactly the sort of nonsense that causes people to think the US PTO is just completely broken.   A   
Yes completely agree.   The prospect of fighting is daunting, desire to run for the hills more desirable

We could start the objecting process instead waiting for MS to come after us.  Anybody want to relive the Blackberry nightmare?
http://www.ipo.gov.uk/patent/p-other/p-object.htm

What Tome Lane brought up could be a very big concern, but if the developers of said code new nothing about the patent and never used MS products then its an independent invention.  But proving that is very costly

Re: [GENERAL] PL/R download

Cindy Makarowsky wrote:
> Is the PL/R download still available? The link is dead from the
> Postgres site and also at www.joeconway.com <http://www.joeconway.com>.
> Is there another location available to download the installer?

Sorry, my bad. Fixed

Joe

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[PATCHES] Doc patch: type modifiers

diff --git a/doc/src/sgml/ref/create_type.sgml b/doc/src/sgml/ref/create_type.sgml
index 641c13e..d7d1a0b 100644
--- a/doc/src/sgml/ref/create_type.sgml
+++ b/doc/src/sgml/ref/create_type.sgml
@@ -433,7 +433,7 @@ CREATE TYPE <replaceable class="parameter">name</replaceable>
<term><replaceable class="parameter">type_modifier_input_function</replaceable></term>
<listitem>
<para>
- The name of a function that converts numeric modifier(s) for the type
+ The name of a function that converts textual modifier(s) for the type
into internal form.
</para>
</listitem>
From
http://developer.postgresql.org/pgdocs/postgres/sql-createtype.html :

type_modifier_input_function

The name of a function that converts numeric modifier(s) for the
type into internal form.

type_modifier_output_function

The name of a function that converts the internal form of the
type's modifier(s) to external textual form.

But the paragraph above says:

"...take one or more simple constants or identifiers as modifiers..."

So in the description of the input function, "numeric" is wrong, and
should be something like "textual" (for the sake of symmetry).

Patch attached.

Regards,
Jeff Davis

[pgsql-es-ayuda] Error fatal en base de datos

Hola a todos,

Tengo instalada una base de datos postgres 8.1 en un servidor con debian.
Desde hace una semana más o menos al intentar arrancar las aplicaciones que
conectan con la base de datos me aparece este error en el log del sistema:

2008-05-26 12:19:40 CEST PANIC: no se pudo escribir archivo de registro 3,
segmento 87 en la posición 12623872, largo 16384: No queda espacio en el
dispositivo
2008-05-26 12:19:40 CEST SENTENCIA: update configuracio set
user_home='/root';
2008-05-26 12:19:40 CEST LOG: proceso de servidor (PID 10896) fue terminado
por una señal 6
2008-05-26 12:19:40 CEST LOG: terminando todos los otros procesos de
servidor activos
2008-05-26 12:19:40 CEST LOG: todos los procesos fueron terminados;
reinicializando
2008-05-26 12:19:40 CEST LOG: el sistema de bases de datos fue interrumpido
en 2008-05-26 12:18:52 CEST
2008-05-26 12:19:40 CEST LOG: el registro de checkpoint está en 3/57C0BAB4
2008-05-26 12:19:40 CEST LOG: registro de redo en 3/57C0BAB4; registro de
undo en 0/0; apagado TRUE
2008-05-26 12:19:40 CEST LOG: siguiente ID de transacción: 51807360;
siguiente OID: 17712
2008-05-26 12:19:40 CEST LOG: siguiente MultiXactId: 29; siguiente
MultiXactOffset: 57
2008-05-26 12:19:40 CEST LOG: el sistema de bases de datos no fue apagado
apropiadamente; se está efectuando la recuperación automática
2008-05-26 12:19:47 CEST LOG: no se pudo leer el archivo de registro 3,
segmento 87, posición 12632064: Error de entrada/salida
2008-05-26 12:19:47 CEST LOG: no se requiere redo
2008-05-26 12:19:47 CEST LOG: el sistema de bases de datos está listo
2008-05-26 12:19:47 CEST LOG: el límite para el reciclaje de ID de
transacciones es 2147484146, limitado por base de datos «postgres»


El disco físico no está lleno porque hay más de un 75% de espacio libre y
entiendo que no es un problema de llenado de los tablespaces de la base de
datos no? Además todo intento de conectar a la base de datos a través de
algún cliente de administración termina con error de I/O.

Espero que me podáis echar una mano para aclararme un poco.

Muchas gracias.

--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

Re: [GENERAL] New MS patent: sounds like PG db rules



Andrew Sullivan wrote:
On Tue, May 27, 2008 at 02:18:31PM +0100, Dave Page wrote:    
I don't think it's a major issue. Even if MS do think we infringe on the patent it would be laughable for them to try to do anything about it given that our rules implementation has provably existed in a leading FOSS project for a decade or more.     
 Unfortuately, it would only be laughable until they sued someone (or, more likely, threatened to do) who was selling PosrgreSQL.  The problem in such cases is that proving your obvious prior art is an expensive undertaking.  The likely path for a targeted "infringer" is just to give up and either pay something to MS or else use some other engine that doesn't "infringe".  This is exactly the sort of nonsense that causes people to think the US PTO is just completely broken.   A   
Yes completely agree.   The prospect of fighting is daunting, desire to run for the hills more desirable

We could start the objecting process instead waiting for MS to come after us.  Anybody want to relive the Blackberry nightmare?
http://www.ipo.gov.uk/patent/p-other/p-object.htm

What Tome Lane brought up could be a very big concern, but if the developers of said code new nothing about the patent and never used MS products then its an independent invention.  But proving that is very costly

[BUGS] BUG #4203: perform dblink() in begin/exception returns wrong SQLSTATE code

The following bug has been logged online:

Bug reference: 4203
Logged by: Henry Combrinck
Email address: henry@zen.co.za
PostgreSQL version: 8.2.6 and 8.3.1
Operating system: Linux
Description: perform dblink() in begin/exception returns wrong
SQLSTATE code
Details:

Apologies if this is the wrong forum to report this (perhaps it needs to go
to the dblink() maintainer?)

In a function on a machine using 8.2.6, the following returns a strange
SQLSTATE code:

begin
perform dblink ('host=other_machine ...',
'insert into table...');
exception when others then
raise notice 'SQLSTATE: %', SQLSTATE;
end;

The code returned is always 42601 (syntax_error) irrespective of the actual
error (eg, unique_violation).

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [GENERAL] New MS patent: sounds like PG db rules

On Tue, May 27, 2008 at 10:38:42AM -0400, Justin wrote:
> Postgresql is
> luck in the fact US patent laws are still based on the idea first to
> invent not first to patent which several countries have gone to.

Which has nothing to do with the matter at hand. It just means that MS
can claim to have invented it up to a year prior to filing which would
be problematic if the SE-Postgres patch is affected.

The rules system is way older and so not at risk either way.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org>

http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

Re: [PERFORM] [GENERAL] select query takes 13 seconds to run with index

On Tue, May 27, 2008 at 07:46:05AM -0700, mark wrote:
> and then it became super fast!! thanks a lot!!!
> my question:
> -> is 500 too high? what all does this affect?

i usually dont go over 100. it affects number of elements in statistics
for fields. you can see the stats in:
select * from pg_stats;

> -> now increasing this number does it affect only when i am running
> analyze commands, or will it slow down inserts and other operations?
> EXPLAIN ANALYZE select * from pokes where uid = 578439028 order by id
> desc limit 6;

it (theoretically) can slow down selects to to the fact that it now has
to load more data to be able to plan (i.e. it loads the statistics, and
since there are more values - the statistics are larger).

generally - in most cases this shouldn't be an issue.

additionally - i think that the 2-column index would work in this
particular case even better.

regards,

depesz

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [pgsql-es-ayuda] almacenar en bd o no?

2008/5/27 Mario Wojcik <mariowojcik@yahoo.com.ar>:
> Crispin T. escribió:
>>
>> hola tengo un problema resulta que tengo un sistema en java con bd
>> postgres 8.2 y todo me va de maravilla pero empieza a preocuparme un asunto,
>> resulta que por performance y por no cargar demasiado la bd no almacene las
>> fotos de unos inmuebles en al bd pero me resulta complicado al momento de
>> hacer backups ya que las imagenes las agarro como archivos y pues copiar
>> varios archivos y restaurar varios archivos ademas de los datos de la bd se
>> me hace mucho trabajo y mucho tiempo pero no me anime a almacenarlos en un
>> tipo oid porque por cada inmueble se manejan alrededor de 30 fotos png de
>> 600x500 aproximadamente, ademas que antes el sistema hera monolitoco (corria
>> en una unica pc) pero ahora el negocio crecio y se necesita que corra en una
>> lan y bueno nose como hacer que una aplicación java cargue archivos que
>> estan en otra pc (no veo seguro compartir la carpeta de los archivos) y me
>> estoy animando a guardar las imagenes en la bd
>>
>> dados los casos ¿que harian ustedes en este caso?
>> en el caso de sugerirme que guarde las imagenes en la bd ¿hay forma de
>> sacar backup's de solo algunas tablas?
>> en caso de no guardar en la bd las imagenes ¿que solucion me sugieren para
>> cargar imagenes desde otra pc(sin compartir la carpeta)?
>>
>> gracias.
>>
>> Crispin.
>
> Hola!
> Para asegurarme de mantener la integridad, yo la metería en una tabla
> que tenga solo un campo ID del tipo serial, un campo ID_Inmueble para
> relacionarla y el campo imagen.
> Entonces, la consulta inicial se haría sobre los datos principales
> (dirección, precio, zona, etc) y, si queremos, hacemos la consulta (mas
> lenta) de las imágenes.
> Opcionalmente, en la tabla principal pondría una imagen muy pequeña como
> referencia visual pero las demás 30 fotos sobre la otra tabla...
> Creo que es un esquema bastante eficiente (en teoría) y evitas las
> referencias que van a ser un dolor de cabeza no solo para las copias,
> sino para cualquier mantenimiento que quieras dar a tu sistema...
>
> --
> ========================
> WOJCIK, MARIO A.
> ========================
> Leandro N Alem -Misiones
> ------------------------
> A R G E N T I N A
> ------------------------
> mariowojcik@yahoo.com.ar
>
>
> --
> TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
>

http://archives.postgresql.org/pgsql-es-ayuda
>

Concuerdo con esto que se propone de echo lo que haciamos en mi
antigüo trabajo era guardar la ruta de la imagen y el nombre la imagen
(que era escaneada ) se trataba para indexar el nombre del archivo
como <fecha dd-mm-aaaa-mm:ss:ns) lo que hacia que cada imagen se
guardara asociada a una transaccion de manera unica despues , como
estas trabajando en Java supongo que tu sistema sera web tu cargas
desde la BD solo los nombres de las imagenes y las despliegas no se si
me hago entender??? ...
El tema era que teniamos una base relativamente "relajada" que
controlaba muchas transacciones criticas, porque si paraba el proceso
armabamos unas filas de camiones que ni te digo... sin mayores
sobresaltos...
El tema que tienes que tener en cuenta es que despues el Backup de la
carpeta con imagenes se vuelve todo un problema pero puedes buscar
maneras de indexar las imagenes y acotar las busquedas por ejemplo por
años...
Slds.
J.


--
----------------------
Slds.
jchavez
linux User #397972 on http://counter.li.org/
--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán

Re: [GENERAL] New MS patent: sounds like PG db rules

On Tue, May 27, 2008 at 02:18:31PM +0100, Dave Page wrote:

> I don't think it's a major issue. Even if MS do think we infringe on
> the patent it would be laughable for them to try to do anything about
> it given that our rules implementation has provably existed in a
> leading FOSS project for a decade or more.

Unfortuately, it would only be laughable until they sued someone (or,
more likely, threatened to do) who was selling PosrgreSQL.

The problem in such cases is that proving your obvious prior art is an
expensive undertaking. The likely path for a targeted "infringer" is
just to give up and either pay something to MS or else use some other
engine that doesn't "infringe".

This is exactly the sort of nonsense that causes people to think the
US PTO is just completely broken.

A

--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] WITH RECURSIVE patches V0.1 TODO items

* Tatsuo Ishii <ishii@postgresql.org> [080527 10:40]:

> In my understanding, yes.

If you want to push back to the same location, yes, you'll all need
accounts at the same location giving you permission to push there.

Technically, you could all "share" an account there too, but the
drawbacks to lack of accountability usually mean separate accounts is a
better solution.

> And I think even if we would have accounts on the community git
> server, we cannot push (commit) to the repository. Probably all we can
> do is, get the diff between someone's pushed data and the origin.

No, it's easy to set it up so you can directly push to a shared
repository, or each push to your individual repositories and
"pull/merge" others changes into your own. Or any combination of the
above.

a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/

work like a slave.

Re: [HACKERS] WITH RECURSIVE patches V0.1 TODO items

On Tue, May 27, 2008 at 12:11:54PM +0200, Michael Meskes wrote:
> On Mon, May 26, 2008 at 07:23:24PM -0700, David Fetter wrote:
> > Right for this case. Is there some way to estimate this short of
> > a full-on materialized views implementation? I'm guessing we'd
> > need to be able to cache the transitive closure of such searches.
>
> You'd like to cache the whole closure? Or just some stats about it?

This is getting way past my knowledge. What kind of stats could be
kept?

Since WITH RECURSIVE doesn't require that any DDL be issued in
advance, we'd need some kind of infrastructure--possibly we have it
today--which could collect those statistics on DML calls.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [PERFORM] [GENERAL] select query takes 13 seconds to run with index

On Tue, May 27, 2008 at 1:22 AM, hubert depesz lubaczewski
<depesz@depesz.com> wrote:
> On Mon, May 26, 2008 at 04:32:50PM -0700, mark wrote:
>> >> EXPLAIN ANALYZE select * from pokes where uid = 578439028 order by id
>> >> DESC limit 6;
>> > The estimate is way off, when was the last time Vaccum was on the table?
>> about a week ago i ran this VACUUM VERBOSE ANALYZE;
>> this table is never updated or deleted, rows are just inserted...
>
> 1. boost default_statistics_target
> 2. run analyze more often - daily job for example
> 3. create index q on pokes (uid, id); should help

OK I did this

ALTER TABLE pokes ALTER uid set statistics 500;
ALTER TABLE

ANALYZE pokes;
ANALYZE

and then it became super fast!! thanks a lot!!!
my question:
-> is 500 too high? what all does this affect?
-> now increasing this number does it affect only when i am running
analyze commands, or will it slow down inserts and other operations?
EXPLAIN ANALYZE select * from pokes where uid = 578439028 order by id
desc limit 6;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=467.80..467.81 rows=6 width=134) (actual
time=0.016..0.016 rows=0 loops=1)
-> Sort (cost=467.80..468.09 rows=117 width=134) (actual
time=0.016..0.016 rows=0 loops=1)
Sort Key: id
Sort Method: quicksort Memory: 25kB
-> Index Scan using idx_pokes_uid on pokes
(cost=0.00..465.70 rows=117 width=134) (actual time=0.011..0.011
rows=0 loops=1)
Index Cond: (uid = 578439028)
Total runtime: 0.037 ms

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [GENERAL] New MS patent: sounds like PG db rules

"Dave Page" <dpage@pgadmin.org> writes:
> On Tue, May 27, 2008 at 2:06 PM, Justin Clift <justin@salasaga.org> wrote:
>> I'm trying to point out that - PG is a database system - and MS may have
>> just been granted a patent for a fundamental part of it.

> I don't think it's a major issue. Even if MS do think we infringe on
> the patent it would be laughable for them to try to do anything about
> it given that our rules implementation has provably existed in a
> leading FOSS project for a decade or more.

Right --- if in fact PG's rules infringe, then the patent is invalid
because we are prior art.

After scanning the claims, though, most of this is about access-rights
enforcement; which is something that rules *could* be used for but it's
not their sole or main purpose. What it seems a whole lot closer to
is Veil or SEPostgres. I think those projects have reason to be very
afraid.

In fact, I suspect that the originally submitted version of SEPostgres
does infringe the patent, and that code is not old enough to be prior
art. The part of the patch that looks like this patent to me is the
part that enforces row-level access checks by adding constraints to a
querytree's WHERE clause.

I had already suggested to KaiGai-san that he get rid of that in favor
of low-level checks in the executor, but the need to avoid an M$ patent
makes it even more important ...

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] WITH RECURSIVE patches V0.1 TODO items

* Tatsuo Ishii <ishii@postgresql.org> [080527 10:12]:

> I don't stick to CVS at all. If contributors are comfortable, let's go
> with GIT.
>
> BTW, does this setting requrie a local GIT server be installed? If so,
> that might be a problem for me since I don't have resource for that.

GIT is a completely distributed VCS/SCM. This means that every single
local clone of a repository is a completely self-sufficent repository.
So you never need to have a "local server" to do anything in GIT.

When people think of "git servers", they are generally thinking of 2
things:
1) Gitweb - the "web interface" to a git repo
2) "public repositories" via git:// git protocol

Neither of these are necessary to use git "locally", but are means for
exchaning/sharing the current state of a repository.

The git protocol is a normal send/receive transfer mechanism, of the
same sort as CVS. Most people using git use it over SSH when pushing
their changes to public places. The git-daemon server serves the
"git://" protocol over any port (usually 9418) and is a way to give
anonymous access to a git repo (usually read-only, but can be
read-write) without needing to give SSH access, like cvs pserver.

But the short of it is, git.postgresql.org runs both gitweb and
git-daemon for you, so if you want to use git, all you need is a local
git package, and SSH access to git.postgresql.org, which can do all the
public serving/sharing for you.

I guess I should have had a GIT talk/intro/anything over lunch or
something last week at PGCon. I hadn't thought of it then... Bummer...

a.

--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/

work like a slave.