Wednesday, May 28, 2008

[BUGS] BUG #4206: function xpath gives wrong results

The following bug has been logged online:

Bug reference: 4206
Logged by: Martin Drescher
Email address: martin.drescher@robotron.de
PostgreSQL version: 8.3.1
Operating system: Windows XP SP2
Description: function xpath gives wrong results
Details:

To demonstrate I use the following simple XML.

<?xml version="1.0"?>
<elem1>
<elem2>one</elem2>
<elem2>two</elem2>
<elem2>three</elem2>
<elem3 att="2"/>
</elem1>

I executed the following query in psql (with the corresponding XPath).

select xpath('//text()',xmlparse(document '<?xml version="1.0"
?><elem1><elem2>one</elem2><elem2>two</elem2><elem2>three</elem2><elem3
att="2"/></elem1>'));

The expected result is checked using Altova XMLSpy 2008.

XPath: (//text())[1]
Expected result: {one}
Actual Result:
ERROR: XX000: invalid XPath expression
DETAIL: Invalid expression
CONTEXT: SQL function "xpath" statement 1
LOCATION: xml_ereport, .\src\backend\utils\adt\xml.c:1351

XPath: boolean(/elem1)
Expected result: {true}
Actual Result:
ERROR: XX000: invalid XPath expression
DETAIL: Invalid expression
CONTEXT: SQL function "xpath" statement 1
LOCATION: xml_ereport, .\src\backend\utils\adt\xml.c:1351

XPath: /elem1/..
Expected result: document root
Actual Result:
{"<x>
<elem1>
<elem2>one</elem2>
<elem2>two</elem2>
<elem2>three</elem2>
<elem3 att=\"2\"/>
</elem1>
</x>"}

Note: This XPath returns the document root. I don’t know, how you choose
to represent it. However, it should not return the element <x>


The problem imo is in .\src\backend\utils\adt\xml.c:3294, where a
<x>-element is wrapped around the xml and the XPath-expression is prepended
by "/x".
This is not needed for XML documents and fragments consisting of a single
root. Instead it breaks many XPath-Expressions; like where you use multiple
absolute path expressions or function calls.
I think, queries on a fragment consisting of multiple roots are not possible
with XPath 1.0.

--
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-www] 404s

On Wed, 2008-05-28 at 18:42 +0200, Stefan Kaltenbrunner wrote:

> I think it would be more reasonable to look into what it would take to
> remove the (obvious) false positives and have the mirror script report
> new ones automatically during site build.
> Though I think what simon was actually refering to are urls pointing to
> external sites which we could maybe check on events/training whatever
> submission and refuse to accept them.
> The mirroring does not really care for external sites so we would only
> be able to spot mistakes that lead to urls that end up on wwwmaster
> (like it being interpreted as a relative link or such) not ones that are
> broken otherwise (domain misspelled, simply wrong,...).

Specifically, yes. But I am worried that we aren't monitoring such a
basic quality issue. There might be lots of URLs in the Wiki that go bad
over time and we want to check on this, don't we?

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support


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

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

On Wed, May 28, 2008 at 8:33 AM, Magnus Hagander <magnus@hagander.net> wrote:
> 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.
>

Oops I could have sworn i grepped the source for them... Sorry!

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

Re: [PERFORM] GEQO Benchmark

On Wed, 2008-05-28 at 13:13 -0300, Tarcizio Bini wrote:

> 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.

My understanding is the GEQO cannot arrive at a better plan than the
standard optimizer, so unless you wish to measure planning time there
isn't much to test. What is the quality of the plans it generates? Well
that varies according to the input; sometimes it gets the right plan,
other times it doesn't get close.

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support


--
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-www] 404s

Joshua D. Drake wrote:
>
> 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>".

I think it would be more reasonable to look into what it would take to
remove the (obvious) false positives and have the mirror script report
new ones automatically during site build.
Though I think what simon was actually refering to are urls pointing to
external sites which we could maybe check on events/training whatever
submission and refuse to accept them.
The mirroring does not really care for external sites so we would only
be able to spot mistakes that lead to urls that end up on wwwmaster
(like it being interpreted as a relative link or such) not ones that are
broken otherwise (domain misspelled, simply wrong,...).


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: FW: [pgsql-es-ayuda] Duda sql bases de datos

2008/5/28 Laura reiva <lauraleyton@hotmail.es>:
> Hola,
> La base de datos original no la puedo aumentar más pues ya contiene
> alrededor de cien tablas y debo realizar ésta "copia" con varias de ellas,
> por lo que crear una nueva tabla en la base de datos original para cada una
> de ellas sería muy complejo. Tendré que usar dblink, aunque no lo conozco.
> Tengo instalado postgreSQL 8.1. ¿Podría explicarme cómo funciona el producto
> dblink?

1ro. instalar dblink en la base de datos 1:

$psql -d db1 -U usuario -f /direccion/al/archivo/dblink.sql

2do. creas una función con un contenido parecido a este:

CREATE OR REPLACE FUNCTION dblink_db1_db2() RETURNS VOID AS $$
DECLARE
fila RECORD;
BEGIN

-- inicias la conexion
SELECT dblink_connect('dbname=db2 user=usuario password=contrasena');

-- obtienes los registros de la db1 (conexion actual) [puedes hacer
con cursores también]
FOR fila IN SELECT * FROM tablaAlumnos_db1 WHERE sexo = 'M' LOOP
-- insertas en la db2. fila: es la estructura que obtiene de cada
fila de la tabla
-- campo1,campo2,etc: son los atributos de la tabla de la 2da base.
SELECT dblink_exec('INSERT INTO tablaAlumnos_db2 VALUES(' ||
fila.campo1 || ',' || fila.campo2 || ');');
END LOOP;

-- cierras la conexion
SELECT dblink_disconnect();

END;
$$ LANGUAGE plpgsql;

3ro. ejecutas la función:

SELECT dblink_db1_db2();

Dale una leída a los archivos dentro de contrib/dblink/doc del código fuente.

--
Saludos y abrazos...

Marco Antonio Frias Butrón
Slackware Linux User
Linux Registered User #356229 - http://counter.li.org/
--
TIP 4: No hagas 'kill -9' a postmaster

Re: [GENERAL] Open Source CRM - Options?

On Wed, 2008-05-28 at 09:20 -0700, Steve Atkins wrote:
> On May 28, 2008, at 8:52 AM, David Wall wrote:
>
> > What about SugarCRM?
>

Drupal works fine with PostgreSQL :)

Joshua D. Drake

--
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 Tue, May 27, 2008 at 4:18 AM, Mark Neely <mark.neely@gmail.com> wrote:
> I've already shortlisted potential CMS systems (including several open-
> source options, such as Drupal and Joomla).

[snip...]

> I am looking for examples of open-source CRM (or similar platforms)
> used for this kind of profiling/personalisation, and would appreciate
> any pointers readers of this newsgroup might be able to offer.

I think the important question is whether the op means CMS or CRM
(quite different).

--
regards,
Robin

--
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-www] replace training blurb with upcoming pug meetings?

On Wed, 2008-05-28 at 12:18 -0400, Robert Treat wrote:
> 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?

I would be amenable to that. I would like to see .Org focusing a bit
more on its "community".

Sincerely,

Joshua D. Drake


--
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

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