Re: [GENERAL] SELECT Query returns empty

>> The scenario:
>> There are two separate processes ? one (P1) inserting
(not
>> updating) data to a table at a high rate (around one record in 10ms)
and
>> another (P2) selecting the data from the same table for further
>>processing. P1
>> and P2 use separate connection to the Database and P1 sends a trigger
to >>P2
>> after inserting the data to the PostgreSQL.

>What do you mean with 'P1 sends a TRIGGER to P2'? You can't send a
>TRIGGER to another process.

By 'send a trigger' what I meant was, P1 sends a TCP packet to P2 (It is
the preferred IPC in our application) asking it to start querying for
data.

>> The issue:
>>
>> P2 tries to query the data from the table, and the result set is
>> empty. I modified the logic to send the trigger only after making
sure >>that P1
>> can successfully query the last record it inserted.

>> I would like to know why P1 can retrieve the data from the table
while P2
>> can?t.

>Wild guess (maybe i misunderstand you): You insert the Data with P1
>within a TRANSACTION and you haven't commited this insert. In this
case,
>P2 can't see the uncommited data.

P1 did commit its insertion and verified it by successfully querying the
last inserted data, before sending the TCP packet - the trigger - to P2

--
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] SELECT Query returns empty

Thank you Craig,

>At a guess: transactional visibility. P1 will have not yet committed
its
>transaction, so the data isn't visible to P2 yet. Remember, PostgreSQL
>defaults to the READ COMMITTED isolation level and does not offer READ
>UNCOMMITTED for those rare situations where you might want it.

P1 did commit its insertion; even it commits its every transaction.

>By "send a trigger" I'm assuming you mean that you're using RAISE
NOTICE
>and LISTEN.

By 'send a trigger' what I meant was, P1 sends a TCP packet to P2 (It is
the preferred IPC in our application) asking it to start querying for
data.

>If P1 commits, then raises a notice to tell P2 about the changes, P2
>should be able to see the changes immediately. Even if P2's transaction
>began before it receives the notice it should still see the changes
>(because of READ COMMITTED isolation). However, if a function or
>statement is running in P2 when P1 commits, the changes made by P1 will
>only become visible after that function or statement finishes.

>If I'm mistaken in my interpretation and P1 does in fact commit before
>notifying P2 of the changes, then there must be something else going
on.
>Perhaps a bit more detail might help.

Processes P1 and P2 are executables developed in VC++. These are the
steps performed by P1 before sending the TCP packet (which acts as a
trigger) to P2.

1) Create an insertion query
2) Execute the query
3) Execute a 'Commit' command
4) Repeat 2 and 3 how many ever times needed
5) 'Select' part of the last 'insert'ed data to verify whether it is
accessible
6) Repeat 6 till the data is available
7) Send a TCP packet to P2 to start its 'Select' query

--
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] Hora del Servidor

No es huso de usar, sino huso de hilar fibras :)

http://es.wikipedia.org/wiki/Huso

gb.-

On Wed, Jul 9, 2008 at 10:13 PM, Hugo César <hugocesar49@gmail.com> wrote:

El día 9 de julio de 2008 17:18, Alvaro Herrera
<alvherre@commandprompt.com> escribió:

> ¿Cual computadora, la del usuario?  No creo que puedas hacer eso.  Lo
> que sí puedes hacer es preguntarle al usuario su huso horario (es con H
> a todo esto) y guardarlo como parte de sus datos.  Luego, cuando quieras
> hacer cosas que dependan de la hora, usas SET TIMEZONE para ponerlo en
> rigor.

Efectivamente me referia a la computadora del usuario, pero me has
dado una excelente
pista con eso de pedirle los datos al usuario......

Creo que "uso" se escribe sin "H"...

Una cosa mas SET TIMEZONE es una variable de entorno cierto ??

Gracias Alvaro por tu orientacion, me ha servido bastante.. como siempre!!!
--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
              http://archives.postgresql.org/pgsql-es-ayuda

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

Re: [PATCHES] Sorting writes during checkpoint

On Fri, 4 Jul 2008, Simon Riggs wrote:

> No action on this seen since last commitfest, but I think we should do
> something with it, rather than just ignore it.

Just no action worth reporting yet. Over the weekend I finally reached
the point where I've got a system that should be capable of independently
replicating the results improvement setup here, and I've started
performance testing of the patch. Getting useful checkpoint test results
from pgbench is really a pain.

> Sorting by file might have inadvertently shown benefit at the tablespace
> level on a larger server with spread out data whereas on Tom's test
> system I would guess just a single tablespace was used.

I doubt this has anything to do with it, only because the pgbench schema
doesn't split into tablespaces usefully. Almost all of the real action is
on a single table, accounts.

My suspicion is that sorting only benefits in situations where you have a
disk controller with a significant amount of RAM on it, but the server RAM
is much larger. In that case the sorting horizon of the controller itself
is smaller than what the server can do, and the sorting makes it less
likely you'll end up with the controller filled with unsorted stuff that
takes a long time to clear.

In Tom's test, there's probably only 8 or 16MB worth of cache on the disk
itself, so you can't get a large backlog of unsorted writes clogging the
write pipeline. But most server systems have 256MB or more of RAM there,
and if you get that filled with seek-heavy writes (which might only clear
at a couple of MB a second) the delay for that cache to empty can be
considerable.

That said, I've got a 256MB controller here and have a very similar disk
setup to the one postiive results were reported on, but so far I don't see
any significant difference after applying the sorted writes patch.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

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

Re: [GENERAL] Making a RPM installer

Jamie Deppeler <jamie@doitonce.net.au> writes:
> I am building a rpm for RHEL 5
> The rpm contains a compiled version for postgresql-8.3.3 and tomcat
> 6 and java 1.6.

> When i try to install the rpm on blank test system i get the
> following dependence issues
> libodbc.so is needed
> libodbcinst.so is needed

You must be including more than you said, because AFAIK none of those
components should depend on libodbc. Try going through all the .so
files included in the RPM with "ldd" to see which one(s) depend on these
libraries.

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

[pgsql-es-ayuda] packages al estilo oracle

hola a todos.

alguien sabe la manera de hacer packages al estilo de oracle en Postgresql.

si alguien sabe, le agradeceria mucho me den una orientacion.

Saludos


--
Ing. Aguilar Pereda Luis
Claro: 044-9383387
Telefonica: 044-8937129
Fijo: 044-421957
http://monossystemsnet.6te.net

[COMMITTERS] pgsql: Fix mis-calculation of extParam/allParam sets for plan nodes, as

Log Message:
-----------
Fix mis-calculation of extParam/allParam sets for plan nodes, as seen in
bug #4290. The fundamental bug is that masking extParam by outer_params,
as finalize_plan had been doing, caused us to lose the information that
an initPlan depended on the output of a sibling initPlan. On reflection
the best thing to do seemed to be not to try to adjust outer_params for
this case but get rid of it entirely. The only thing it was really doing
for us was to filter out param IDs associated with SubPlan nodes, and that
can be done (with greater accuracy) while processing individual SubPlan
nodes in finalize_primnode. This approach was vindicated by the discovery
that the masking method was hiding a second bug: SS_finalize_plan failed to
remove extParam bits for initPlan output params that were referenced in the
main plan tree (it only got rid of those referenced by other initPlans).
It's not clear that this caused any real problems, given the limited use
of extParam by the executor, but it's certainly not what was intended.

I originally thought that there was also a problem with needing to include
indirect dependencies on external params in initPlans' param sets, but it
turns out that the executor handles this correctly so long as the depended-on
initPlan is earlier in the initPlans list than the one using its output.
That seems a bit of a fragile assumption, but it is true at the moment,
so I just documented it in some code comments rather than making what would
be rather invasive changes to remove the assumption.

Back-patch to 8.1. Previous versions don't have the case of initPlans
referring to other initPlans' outputs, so while the existing logic is still
questionable for them, there are not any known bugs to be fixed. So I'll
refrain from changing them for now.

Tags:
----
REL8_1_STABLE

Modified Files:
--------------
pgsql/src/backend/executor:
execAmi.c (r1.85.2.1 -> r1.85.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execAmi.c?r1=1.85.2.1&r2=1.85.2.2)
pgsql/src/backend/optimizer/plan:
subselect.c (r1.100.2.4 -> r1.100.2.5)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/subselect.c?r1=1.100.2.4&r2=1.100.2.5)
pgsql/src/test/regress/expected:
subselect.out (r1.13.2.2 -> r1.13.2.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/subselect.out?r1=1.13.2.2&r2=1.13.2.3)
pgsql/src/test/regress/sql:
subselect.sql (r1.8.2.2 -> r1.8.2.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/subselect.sql?r1=1.8.2.2&r2=1.8.2.3)

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

[COMMITTERS] pgsql: Fix mis-calculation of extParam/allParam sets for plan nodes, as

Log Message:
-----------
Fix mis-calculation of extParam/allParam sets for plan nodes, as seen in
bug #4290. The fundamental bug is that masking extParam by outer_params,
as finalize_plan had been doing, caused us to lose the information that
an initPlan depended on the output of a sibling initPlan. On reflection
the best thing to do seemed to be not to try to adjust outer_params for
this case but get rid of it entirely. The only thing it was really doing
for us was to filter out param IDs associated with SubPlan nodes, and that
can be done (with greater accuracy) while processing individual SubPlan
nodes in finalize_primnode. This approach was vindicated by the discovery
that the masking method was hiding a second bug: SS_finalize_plan failed to
remove extParam bits for initPlan output params that were referenced in the
main plan tree (it only got rid of those referenced by other initPlans).
It's not clear that this caused any real problems, given the limited use
of extParam by the executor, but it's certainly not what was intended.

I originally thought that there was also a problem with needing to include
indirect dependencies on external params in initPlans' param sets, but it
turns out that the executor handles this correctly so long as the depended-on
initPlan is earlier in the initPlans list than the one using its output.
That seems a bit of a fragile assumption, but it is true at the moment,
so I just documented it in some code comments rather than making what would
be rather invasive changes to remove the assumption.

Back-patch to 8.1. Previous versions don't have the case of initPlans
referring to other initPlans' outputs, so while the existing logic is still
questionable for them, there are not any known bugs to be fixed. So I'll
refrain from changing them for now.

Tags:
----
REL8_2_STABLE

Modified Files:
--------------
pgsql/src/backend/executor:
execAmi.c (r1.89.2.1 -> r1.89.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execAmi.c?r1=1.89.2.1&r2=1.89.2.2)
pgsql/src/backend/optimizer/plan:
subselect.c (r1.112.2.3 -> r1.112.2.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/subselect.c?r1=1.112.2.3&r2=1.112.2.4)
pgsql/src/test/regress/expected:
subselect.out (r1.14.2.1 -> r1.14.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/subselect.out?r1=1.14.2.1&r2=1.14.2.2)
pgsql/src/test/regress/sql:
subselect.sql (r1.9.2.1 -> r1.9.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/subselect.sql?r1=1.9.2.1&r2=1.9.2.2)

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

[COMMITTERS] pgsql: Fix mis-calculation of extParam/allParam sets for plan nodes, as

Log Message:
-----------
Fix mis-calculation of extParam/allParam sets for plan nodes, as seen in
bug #4290. The fundamental bug is that masking extParam by outer_params,
as finalize_plan had been doing, caused us to lose the information that
an initPlan depended on the output of a sibling initPlan. On reflection
the best thing to do seemed to be not to try to adjust outer_params for
this case but get rid of it entirely. The only thing it was really doing
for us was to filter out param IDs associated with SubPlan nodes, and that
can be done (with greater accuracy) while processing individual SubPlan
nodes in finalize_primnode. This approach was vindicated by the discovery
that the masking method was hiding a second bug: SS_finalize_plan failed to
remove extParam bits for initPlan output params that were referenced in the
main plan tree (it only got rid of those referenced by other initPlans).
It's not clear that this caused any real problems, given the limited use
of extParam by the executor, but it's certainly not what was intended.

I originally thought that there was also a problem with needing to include
indirect dependencies on external params in initPlans' param sets, but it
turns out that the executor handles this correctly so long as the depended-on
initPlan is earlier in the initPlans list than the one using its output.
That seems a bit of a fragile assumption, but it is true at the moment,
so I just documented it in some code comments rather than making what would
be rather invasive changes to remove the assumption.

Back-patch to 8.1. Previous versions don't have the case of initPlans
referring to other initPlans' outputs, so while the existing logic is still
questionable for them, there are not any known bugs to be fixed. So I'll
refrain from changing them for now.

Tags:
----
REL8_3_STABLE

Modified Files:
--------------
pgsql/src/backend/executor:
execAmi.c (r1.94 -> r1.94.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execAmi.c?r1=1.94&r2=1.94.2.1)
pgsql/src/backend/optimizer/plan:
planagg.c (r1.36.2.1 -> r1.36.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/planagg.c?r1=1.36.2.1&r2=1.36.2.2)
subselect.c (r1.129.2.1 -> r1.129.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/subselect.c?r1=1.129.2.1&r2=1.129.2.2)
pgsql/src/test/regress/expected:
subselect.out (r1.16.2.1 -> r1.16.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/subselect.out?r1=1.16.2.1&r2=1.16.2.2)
pgsql/src/test/regress/sql:
subselect.sql (r1.11.2.1 -> r1.11.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/subselect.sql?r1=1.11.2.1&r2=1.11.2.2)

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

[COMMITTERS] pgsql: Fix mis-calculation of extParam/allParam sets for plan nodes, as

Log Message:
-----------
Fix mis-calculation of extParam/allParam sets for plan nodes, as seen in
bug #4290. The fundamental bug is that masking extParam by outer_params,
as finalize_plan had been doing, caused us to lose the information that
an initPlan depended on the output of a sibling initPlan. On reflection
the best thing to do seemed to be not to try to adjust outer_params for
this case but get rid of it entirely. The only thing it was really doing
for us was to filter out param IDs associated with SubPlan nodes, and that
can be done (with greater accuracy) while processing individual SubPlan
nodes in finalize_primnode. This approach was vindicated by the discovery
that the masking method was hiding a second bug: SS_finalize_plan failed to
remove extParam bits for initPlan output params that were referenced in the
main plan tree (it only got rid of those referenced by other initPlans).
It's not clear that this caused any real problems, given the limited use
of extParam by the executor, but it's certainly not what was intended.

I originally thought that there was also a problem with needing to include
indirect dependencies on external params in initPlans' param sets, but it
turns out that the executor handles this correctly so long as the depended-on
initPlan is earlier in the initPlans list than the one using its output.
That seems a bit of a fragile assumption, but it is true at the moment,
so I just documented it in some code comments rather than making what would
be rather invasive changes to remove the assumption.

Back-patch to 8.1. Previous versions don't have the case of initPlans
referring to other initPlans' outputs, so while the existing logic is still
questionable for them, there are not any known bugs to be fixed. So I'll
refrain from changing them for now.

Modified Files:
--------------
pgsql/src/backend/executor:
execAmi.c (r1.94 -> r1.95)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execAmi.c?r1=1.94&r2=1.95)
pgsql/src/backend/optimizer/plan:
planagg.c (r1.39 -> r1.40)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/planagg.c?r1=1.39&r2=1.40)
subselect.c (r1.130 -> r1.131)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/subselect.c?r1=1.130&r2=1.131)
pgsql/src/test/regress/expected:
subselect.out (r1.18 -> r1.19)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/subselect.out?r1=1.18&r2=1.19)
pgsql/src/test/regress/sql:
subselect.sql (r1.12 -> r1.13)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/subselect.sql?r1=1.12&r2=1.13)

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

Re: [GENERAL] rollback

Adrian Moisey wrote:
> Hi
>
> >>>> I would like to be able to "mark" a point in my postgres database.
> >>>> After that I want to change a few things and "rollback" to that point.
> >>>> Does postgres support such a thing? Is it possible for me to do this?
> >>> Well, transactions do that. If you want to do this inside a
> >>> transaction, the term you're looking for is "savepoints".
> >> I would like to do this globally over the entire DB, is that possible?
> >
> > Sure. You can start a transaction, create tables, drop tables, do
> > inserts and deletes, update some tables, create and delete functions,
> > triggers, views and schemas. After that, rollback. No problem.
>
> Can I do this outside of a transaction?
>
>
How about
create database a_copy template = original_database

To recover at later date
drop database original_database;
alter database a_copy rename to original_database;

There will be all sorts of issues so it might be impractical depending
on your situation.
- permission (have to be able to create/drop/rename databases)
- concurrency (noone connected for the drop, everything done by anyone
else will be forgotten as well)
- time / capacity (creating a copy of a large database might take a
while and need extra storage)

klint.

--
Klint Gore
Database Manager
Sheep CRC
A.G.B.U.
University of New England
Armidale NSW 2350

Ph: 02 6773 3789
Fax: 02 6773 3266
EMail: kgore4@une.edu.au

--
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] Making a RPM installer

On Thu, 2008-07-10 at 11:02 +1000, Jamie Deppeler wrote:
> There is a few reason why I am making this installer
>
> 1. Need to make a installer that just uses one rpm file
> 2. It needs to come with a prebuild database
> 3. Custom changes have been made to tomcat configuration

Fair enough :) but it seems to me the way to do that is to make an rpm
that has the dependencies of the other rpms and then has a setup script
that builds the database, configures tomcat etc...

That way you don't break packaging, you meet your requirements and you
don't have anything funky going on :).

Just a suggestion.

Sincerely,

Joshua D. Drake

>
> Joshua D. Drake wrote:
> > On Thu, 2008-07-10 at 10:28 +1000, Jamie Deppeler wrote:
> >
> >> Hi,
> >>
> >> Not sure if this the correct place to post this issue but hopefully
> >> someone can help.
> >>
> >
> > Any reason why you just wouldn't use:
> >
> > http://www.pgsqlrpms.org
> >
> > and
> >
> > http://www.jpackage.org/
> >
> > Sincerely,
> >
> > Joshua D. Drake
> >
> >
> >> I am building a rpm for RHEL 5
> >> The rpm contains a compiled version for postgresql-8.3.3 and tomcat
> >> 6 and java 1.6.
> >>
> >> When i try to install the rpm on blank test system i get the
> >> following dependence issues
> >>
> >> libodbc.so is needed
> >> libodbcinst.so is needed
> >>
> >>
> >> Postgresql has been compiled with the following line
> >>
> >> ./configure --without-readline --without-zlib
> >>
> >> Any help would be greatly received.
> >>
> >>
> >
> >
> >
> >
>
>

--
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] Hora del Servidor

El día 9 de julio de 2008 17:18, Alvaro Herrera
<alvherre@commandprompt.com> escribió:
> ¿Cual computadora, la del usuario? No creo que puedas hacer eso. Lo
> que sí puedes hacer es preguntarle al usuario su huso horario (es con H
> a todo esto) y guardarlo como parte de sus datos. Luego, cuando quieras
> hacer cosas que dependan de la hora, usas SET TIMEZONE para ponerlo en
> rigor.

Efectivamente me referia a la computadora del usuario, pero me has
dado una excelente
pista con eso de pedirle los datos al usuario......

Creo que "uso" se escribe sin "H"...

Una cosa mas SET TIMEZONE es una variable de entorno cierto ??

Gracias Alvaro por tu orientacion, me ha servido bastante.. como siempre!!!
--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?

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

Re: [GENERAL] Making a RPM installer

There is a few reason why I am making this installer

1. Need to make a installer that just uses one rpm file
2. It needs to come with a prebuild database
3. Custom changes have been made to tomcat configuration

Joshua D. Drake wrote:
> On Thu, 2008-07-10 at 10:28 +1000, Jamie Deppeler wrote:
>
>> Hi,
>>
>> Not sure if this the correct place to post this issue but hopefully
>> someone can help.
>>
>
> Any reason why you just wouldn't use:
>
> http://www.pgsqlrpms.org
>
> and
>
> http://www.jpackage.org/
>
> Sincerely,
>
> Joshua D. Drake
>
>
>> I am building a rpm for RHEL 5
>> The rpm contains a compiled version for postgresql-8.3.3 and tomcat
>> 6 and java 1.6.
>>
>> When i try to install the rpm on blank test system i get the
>> following dependence issues
>>
>> libodbc.so is needed
>> libodbcinst.so is needed
>>
>>
>> Postgresql has been compiled with the following line
>>
>> ./configure --without-readline --without-zlib
>>
>> Any help would be greatly received.
>>
>>
>
>
>
>

--
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] Making a RPM installer

On Thu, 2008-07-10 at 10:28 +1000, Jamie Deppeler wrote:
> Hi,
>
> Not sure if this the correct place to post this issue but hopefully
> someone can help.

Any reason why you just wouldn't use:

http://www.pgsqlrpms.org

and

http://www.jpackage.org/

Sincerely,

Joshua D. Drake

>
> I am building a rpm for RHEL 5
> The rpm contains a compiled version for postgresql-8.3.3 and tomcat
> 6 and java 1.6.
>
> When i try to install the rpm on blank test system i get the
> following dependence issues
>
> libodbc.so is needed
> libodbcinst.so is needed
>
>
> Postgresql has been compiled with the following line
>
> ./configure --without-readline --without-zlib
>
> Any help would be greatly received.
>

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

[HACKERS] Follow-up on replication hooks for PostgreSQL

Hi everyone,

This is a quick update on a promise I made early in June to suggest requirements as well as ways to add replication hooks that would support logical replication, as opposed to the physical replication work currently underway based on NTT’s code.  

Well, June was a pretty busy month, so it has taken a while to get back to this.  However, we are now beginning to examine options for PostgreSQL logical replication.  To make a long story short we are willing to commit resources to this problem or fund other people to do it for us.  If you are interested please contact me directly.  Meanwhile, we are quite serious about this problem and intend to work on helpful additions to PostgreSQL in this area.  I will post more as we make progress.  

Thanks, Robert

--
Robert Hodges, CTO, Continuent, Inc.
Email:  robert.hodges@continuent.com

P.s., Happy 12th birthday everyone!

[GENERAL] Making a RPM installer

Hi,

Not sure if this the correct place to post this issue but hopefully
someone can help.

I am building a rpm for RHEL 5
The rpm contains a compiled version for postgresql-8.3.3 and tomcat
6 and java 1.6.

When i try to install the rpm on blank test system i get the
following dependence issues

libodbc.so is needed
libodbcinst.so is needed

Postgresql has been compiled with the following line

./configure --without-readline --without-zlib

Any help would be greatly received.

--
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] manual Installation for thread safety

"unixprgrmr01@gmail.com" <unixprgrmr01@gmail.com> writes:
> In order to use the --enable-thread-safety build switch I need to do a
> manual build... UNLESS there is a way of doing this from the RPM command
> line, which I have not been able to find.

Uh ... whose RPM are you using? All the PG RPMs I know of have been
built with --enable-thread-safety for quite a long time. Certainly
the one that comes with Fedora 8 is.

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: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP

On Wed, Jul 09, 2008 at 04:43:27PM -0400, Aidan Van Dyk wrote:
> * David Fetter <david@fetter.org> [080709 14:45]:
> > On Tue, Jul 08, 2008 at 09:28:34PM -0400, Alvaro Herrera wrote:
>
> > > In fact, I fail to see the point of you providing the repo if
> > > the upstream guys are apparently not using it ...
> >
> > It's *very* early days to be dismissing git entirely. We don't
> > have auths fixed up yet, and I contend that that's because the
> > people who have sudo on the git machine are unwilling to create
> > git-shell accounts for people who need them.
>
> I don't think that was intended to dismiss git entirely, but only
> question what the point of this particular git repo/branch is for:
> http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=shortlog;h=with_recursive
>
> Is it just to provide an alternative way to fetch the patch? I
> would have thought that anybody who can compile PostgreSQL from
> source can apply a patch (if the patch available and applies
> cleanly).
>
> The with_recursive branch doesn't seem to provide any of the nice
> goodies that git could provide (i.e. patch history, merge
> corresponding to various versions so you can easily see what
> changed, etc)

I'm really new to this git thing, but I now have access to create
git-shell accounts, etc. on git.postgresql.org. Any ideas you can
offer on how better to handle this would really help me. :)

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-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [GENERAL] Default UUID in Postgres

On Jul 9, 2008, at 4:32 PM, Swaminathan Saikumar wrote:

> Hello,
>
> I created a Postgres table with a UUID. I want the UUID to be
> populated by default.

PostgreSQL doesn't have built-in functions for generating UUIDs, but
there is a module in contrib that will do so:

http://www.postgresql.org/docs/current/static/datatype-uuid.html

--
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] Consulta cruzada

Miguel Rodríguez Penabad escribió:
> Busca en los históricos de la lista. Hace tiempo se planteó el mismo
> problema, y
> la mejor solución ofrecida en mi opinión era crear un agregado (create
> aggregate).

http://archives.postgresql.org/message-id/20080327234052.GZ8764%40alvh.no-ip.org

--
Alvaro Herrera

http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

Re: [GENERAL] MSSQL to PostgreSQL

Gwyneth Morrison wrote:
> Ray,
>
> I think we tried that and I think it works but not for us. It may work
> for you.
>
> MS wants to copy all the tables over with exactly the same names
> including [dbo]. and so on.
> When it doesn't find an exact match, it wants to create the table. This
> may be ok for you but
> I am not sure what it does about mapping datatypes. This is controlled
> in my program by precreating the
> tables with the desired mappings. (we have mostly found what works but
> it can be changed easily)
>
> We have over 400 tables and as they are related, they need to be loaded
> in a particular order.
> I control this with a file of table names (dropped out of the conversion
> program)
>
> The data copy is only a few scripts largely based on FreeTDS. (do a
> google, I won't post a link here)
>
> So give the Enterprise Manager a try. It may work for you. I think we
> only had to install a Postgres odbc driver.
>
> My program(s) should be available soon (few days I figure) when I get a
> place to post it.
>
> Gwyneth

Sounds reasonable what you say. We will give Enterprise Manager a try
tomorrow, and if it does not work for us, I will hope your tool will be
published soon.

Funny, that there isn't such a tool yet.

Iv

--
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] Admin interfaces *must* paginate

Folks,

Currently, the Events & News approval interfaces do *not* paginate. So if
I want to edit an item, and need to do "see all events", it often locks up
my browser. We need to add either searchability, or at least pagination,
here.

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

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

[GENERAL] Default UUID in Postgres

Hello,

I created a Postgres table with a UUID. I want the UUID to be populated by default.

Sample table:
CREATE TABLE "t"
(
  token uuid NOT NULL,
  CONSTRAINT unique_token UNIQUE (token)
);

I tried out this post:
http://archives.postgresql.org/pgsql-general/2006-08/msg01452.php
CREATE TABLE t (id UUID DEFAULT 'uuid(4)' PRIMARY KEY);

and got an error that uuid(4) is undefined.

I then tried out:
http://www.postgresql.org/docs/8.3/static/uuid-ossp.html
using uuid_generate_v4() for the default.

That didn't work as well.

Can anyone help please?

Thanks!

[pgsql-fr-generale] Appel à conférences / Pgday 4 octobre 2008 à Toulouse

====== Appel à conférences ======

Dans la lignée des évènements PGDay ( "journée PostgreSQL" ) organisée en
Italie, en Grande Bretagne, aux États-Unis , l'association des utilisateurs
francophones de PostgreSQL
( PostgreSQLFr ), en partenariat avec Toulibre, lance une journée dédiée à
PostgreSQL.

Cette journée se tiendra le 4 octobre 2008.

Les conférences se tiendront de 9h à 18h au centre culturel Soupetard à
Toulouse.

PGDay.fr est l'évènement le plus important de l'année à propos de PostgreSQL
et de ses logiciels associés. Si vous êtes un responsable informatique, un
développeur ou un
utilisateur avancé de PostgreSQL,
cette rencontre est une superbe occasion de présenter votre travail et vos
réflexions.

Nous sommes intéressés par des conférences et des ateliers dans tous les
domaines relatifs à PostgreSQL, notamment :

* La réplication avec Slony (ou autres...)
* Une étude du coût total de possession de PostgreSQL (TCO)
* Cas d'étude : Migration vers PostgreSQL
* La sécurisation de données
* Témoignages d'utilisation
* Les avancées de la future version 8.4
* Log Shipping
* Recherche plein texte
* Outils d'analyse et d'optimisation
* ...

Chaque conférence doit se faire en français et durer 45 minutes.

Envoyer vos propositions de conférences à l'adresse : bureau@postgresqlfr.org
avant le **1er septembre 2008**

Retrouvez cet appel à l'adresse :

http://wiki.postgresql.fr/doku.php/pgday2008:appel_a_conferences

Quelques liens complémentaires :

* Site officiel de l'évènement : http://www.pgday.fr

* L'association PostgreSQLFr : http://www.postgresql.fr

* L'association Toulibre : http://www.toulibre.org

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

[ANNOUNCE] Schedule posted, registration open for pgDay San Francisco

PostgreSQL users:

We now have a very full and interesting schedule for the pgDay at
LinuxWorldExpo San Francisco, on Tuesday, August 5:

http://pugs.postgresql.org/node/447

If you are going to be in the San Francisco Bay Area in the first week of
August, you absolutely must come and join us. We're also planning a lot
of beginner-friendly talks, so bring your boss!

You must register through the LinuxWorld registration:

http://www.linuxworldexpo.com/live/12/ehall//SN460564

The LinuxWorld pgDay is sponsored by LinuxWorldExpo, CommandPrompt and
EnterpriseDB. The PostgreSQL Social that evening is sponsored by Truviso
and others.

--
--Josh Berkus

Josh Berkus
PostgreSQL Project Core Team
www.postgresql.org

(all opinions expressed are my own; I do not speak
for the Project unless specifically noted.)

---------------------------(end of broadcast)---------------------------
-To unsubscribe from this list, send an email to:

pgsql-announce-unsubscribe@postgresql.org

Re: [pgus-board] [Fwd: US PostreSQL]

On Tue, 2008-07-08 at 22:55 -0400, Michael Alan Brewer wrote:
> On Tue, Jul 8, 2008 at 6:05 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
> > And a resend.
> >
> > Like I said there is an error in the 8832620_1.DOC, but it is just a
> > date change.
>
> In addition to the date change, isn't the dues structure in section 5 incorrect?

Yes, per http://www.postgresql.us/node/12

It is 75.00 and 20.00 for a student. So that means two things:

1. We need to fix the doc (Michael you can actually do that)
2. We need to define student. Michael would you like to take a stab at a
motion that does that?

As a note we should push this back to -board, I just pushed off because
of the attachment size.

Joshua D. Drake

>
> ---Michael Brewer
> mbrewer@gmail.com
>

--
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] MSSQL to PostgreSQL

Iv Ray wrote:
>> Hi Ray,
>>
>> I have something that does this. I am currently awaiting project
>> approval on pgfoundry.
>> It does tables, views, and stored procedures. I have tested it on
>> 450,000 lines of mssql code
>> including 400 tables and 3700 stored procedures, although it is a
>> work in progress.
>>
>> I applied last week and they said it takes 72 hours. As soon as it is
>> approved I can post it.
>> (give it a couple days I guess)
>>
>> Gwyneth
>
> Hi Gwyneth,
>
> sounds very interesting.
>
> We found this -
>
> http://wiki.postgresql.org/wiki/Converting_your_data_from_MS_SQL_Server_7_to_PostgreSQL_7.1.x

>
>
> (for very old version)
>
> - it is surprising that the SQL Enterprise Manager does this... We
> gave it a little try today and saw that indeed, there is "PostgreSQL"
> in there. But we left to try it tomorrow. Do you know it?
>
> We do not have stored procedures, only tables and views. Would be, in
> any case, interested in seeing what you have.
>
> Iv
Ray,

I think we tried that and I think it works but not for us. It may work
for you.

MS wants to copy all the tables over with exactly the same names
including [dbo]. and so on.
When it doesn't find an exact match, it wants to create the table. This
may be ok for you but
I am not sure what it does about mapping datatypes. This is controlled
in my program by precreating the
tables with the desired mappings. (we have mostly found what works but
it can be changed easily)

We have over 400 tables and as they are related, they need to be loaded
in a particular order.
I control this with a file of table names (dropped out of the conversion
program)

The data copy is only a few scripts largely based on FreeTDS. (do a
google, I won't post a link here)

So give the Enterprise Manager a try. It may work for you. I think we
only had to install a Postgres odbc driver.

My program(s) should be available soon (few days I figure) when I get a
place to post it.

Gwyneth

--
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] Consulta cruzada

Busca en los históricos de la lista. Hace tiempo se planteó el mismo
problema, y
la mejor solución ofrecida en mi opinión era crear un agregado (create
aggregate).

--
Miguel Rodríguez Penabad
--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

Re: [pgsql-es-ayuda] recomendacion tipo columnas de fecha/hora

Linos escribió:

> Tiene sentido usar "timestamp with time zone" cuando la aplicación es un
> tpv que van a usar unos cuantos usuarios todos dentro de la misma zona
> horaria? la verdad es q en la documentación de postgresql no he
> conseguido aclararme este punto. Yo he probado los dos tipos y me
> funcionan (bueno no he probado desde qt si puedo insertar una hora sin
> indicar la zona horaria pero por lo demás bien) pero si no voy a usar lo
> de las zonas, supongo que sera mas eficiente no manejar esa información,
> no? Un saludo.

No es cosa de eficiencia, porque el almacenamiento es el mismo. La
diferencia es qué se hace cuando el que lee el dato está en un huso
diferente del que escribe.

Lo que hace timestamptz (timestamp with time zone) es tomar el valor,
"rotarlo" a GMT, y almacenarlo en GMT. Luego al leer, se toma el valor
y se "rota" al huso horario actual y se muestra.

¿Qué significa eso? Que si yo estando en Valdivia (-0400) ingreso un
dato en este momento, y luego alguien en UK (+0000) lo lee un minuto más
tarde, el valor que le aparece va a tener sentido en su reloj local (es
decir, va a aparecer en su hora local menos un minuto). Si usas
timestamp, no ocurre ninguna de las marigüanzas de rotación horaria y el
compadre fácilmente podrá creer que el valor se ingresó cuatro horas más
tarde.

Es fácil pensar que "basta con usar timestamp, total no necesito los
husos horarios", pero en la práctica en algún momento necesitas hacer
las correcciones y cambiar en ese momento es un parto.

--
Alvaro Herrera

http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?

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

Re: [pgsql-es-ayuda] Hora del Servidor

Hugo César escribió:

> Cheque la vista pg_timezone_names para verificar lo que me comentas...
> coloque America/Mexico_City... reinicie el servidor y funciono!!! Ya
> no hay problemas de retraso con la hora... solo que.... estoy haciendo
> un programita y necesito cambiar los usos horarios para Costa Rica,
> Colombia y Argentina (dependiendo de donde utilicen el programa),
> quizas me vas a contestar que coloque el uso horario para cada uno..
> pero yo quisiera saber si existe alguna forma que el servidor de
> Postgres tome la hora en base a la configuración regional que tenga
> previamente configurada la computadora. Se puede hacer esto... ?? O no
> ??

¿Cual computadora, la del usuario? No creo que puedas hacer eso. Lo
que sí puedes hacer es preguntarle al usuario su huso horario (es con H
a todo esto) y guardarlo como parte de sus datos. Luego, cuando quieras
hacer cosas que dependan de la hora, usas SET TIMEZONE para ponerlo en
rigor.

> Otra cosa cual es el uso horario de colombia ?? No lo encontre en la
> vista que te mencione...

Supongo que America/Bogota el de Bogotá; quizás haya otros (por ej. en
Argentina hay como 4 husos distintos, y en México también hay varios).

--
Alvaro Herrera

http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a majordomo@postgresql.org)

Re: [pgadmin-hackers] Dialogs review

Index: pgadmin/ui/dlgAggregate.xrc
===================================================================
--- pgadmin/ui/dlgAggregate.xrc (revision 7390)
+++ pgadmin/ui/dlgAggregate.xrc (working copy)
@@ -2,153 +2,297 @@
<resource>
<object class="wxDialog" name="dlgAggregate">
<title></title>
- <object class="wxNotebook" name="nbNotebook">
- <object class="notebookpage">
- <label>Properties</label>
- <object class="wxPanel" name="pnlProperties">
- <object class="wxStaticText" name="stName">
- <label>Name</label>
- <pos>5,7d</pos>
+ <size>218,238d</size>
+ <style>wxDEFAULT_DIALOG_STYLE|wxCAPTION|wxSYSTEM_MENU|wxRESIZE_BORDER|wxRESIZE_BOX|wxTHICK_FRAME</style>
+ <object class="wxFlexGridSizer">
+ <cols>1</cols>
+ <object class="sizeritem">
+ <object class="wxNotebook" name="nbNotebook">
+ <object class="notebookpage">
+ <label>Properties</label>
+ <object class="wxPanel" name="pnlProperties">
+ <object class="wxFlexGridSizer">
+ <cols>2</cols>
+ <rows>5</rows>
+ <vgap>5</vgap>
+ <hgap>5</hgap>
+ <growablerows>3</growablerows>
+ <growablecols>1</growablecols>
+ <object class="sizeritem">
+ <object class="wxStaticText" name="stName">
+ <label>Name</label>
+ <pos>5,7d</pos>
+ </object>
+ <flag>wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="wxTextCtrl" name="txtName">
+ <pos>70,5d</pos>
+ <size>135,-1d</size>
+ </object>
+ <flag>wxEXPAND|wxALIGN_TOP</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="wxStaticText" name="stOID">
+ <label>OID</label>
+ <pos>5,22d</pos>
+ </object>
+ <flag>wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="wxTextCtrl" name="txtOID">
+ <pos>70,20d</pos>
+ <size>135,-1d</size>
+ </object>
+ <flag>wxEXPAND|wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="wxStaticText" name="stOwner">
+ <label>Owner</label>
+ <pos>5,37d</pos>
+ </object>
+ <flag>wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="ctlComboBox" name="cbOwner">
+ <pos>70,35d</pos>
+ <size>135,12d</size>
+ <content/>
+ <style>wxCB_DROPDOWN</style>
+ </object>
+ <flag>wxEXPAND|wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="wxStaticText" name="stComment">
+ <label>Comment</label>
+ <pos>5,52d</pos>
+ </object>
+ <flag>wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="wxTextCtrl" name="txtComment">
+ <pos>70,50d</pos>
+ <size>135,132d</size>
+ <style>wxTE_MULTILINE</style>
+ </object>
+ <flag>wxALL|wxEXPAND</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="wxStaticText" name="stClusterSet">
+ <label>Use replication</label>
+ <pos>5,187d</pos>
+ </object>
+ <flag>wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="wxComboBox" name="cbClusterSet">
+ <content/>
+ <pos>70,185d</pos>
+ <size>135,12d</size>
+ <style>wxCB_READONLY|wxCB_DROPDOWN</style>
+ </object>
+ <flag>wxEXPAND|wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ </object>
+ </object>
</object>
- <object class="wxTextCtrl" name="txtName">
- <pos>70,5d</pos>
- <size>135,-1d</size>
+ <object class="notebookpage">
+ <label>Definition</label>
+ <object class="wxPanel" name="pnlDefinition">
+ <object class="wxFlexGridSizer">
+ <cols>2</cols>
+ <rows>7</rows>
+ <vgap>5</vgap>
+ <hgap>5</hgap>
+ <growablecols>1</growablecols>
+ <growablerows>0</growablerows>
+ <object class="sizeritem">
+ <object class="wxFlexGridSizer">
+ <cols>1</cols>
+ <rows>2</rows>
+ <vgap>5</vgap>
+ <hgap>5</hgap>
+ <growablerows>1</growablerows>
+ <object class="sizeritem">
+ <object class="wxStaticText" name="stInputTypes">
+ <label>Input types</label>
+ <pos>5,7d</pos>
+ </object>
+ <flag>wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="wxButton" name="btnRemoveType">
+ <label>&amp;Remove</label>
+ <pos>5,87d</pos>
+ <size>60,-1d</size>
+ </object>
+ <flag>wxALIGN_BOTTOM|wxBOTTOM</flag>
+ </object>
+ </object>
+ </object>
+ <object class="sizeritem">
+ <object class="wxListCtrl" name="lstInputTypes">
+ <pos>70,5d</pos>
+ <size>135,97d</size>
+ <style>wxLC_REPORT</style>
+ </object>
+ <flag>wxALL|wxEXPAND</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="wxButton" name="btnAddType">
+ <label>&amp;Add</label>
+ <pos>5,105d</pos>
+ <size>60,-1d</size>
+ </object>
+ <flag>wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="ctlComboBox" name="cbInputType">
+ <content/>
+ <pos>70,105d</pos>
+ <size>135,12d</size>
+ <style>wxCB_DROPDOWN</style>
+ </object>
+ <flag>wxEXPAND|wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="wxStaticText" name="stStateType">
+ <label>State type</label>
+ <pos>5,127d</pos>
+ </object>
+ <flag>wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="ctlComboBox" name="cbStateType">
+ <content/>
+ <pos>70,125d</pos>
+ <size>135,12d</size>
+ <style>wxCB_DROPDOWN</style>
+ </object>
+ <flag>wxEXPAND|wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="wxStaticText" name="stStateFunc">
+ <label>State function</label>
+ <pos>5,142d</pos>
+ </object>
+ <flag>wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="wxComboBox" name="cbStateFunc">
+ <content/>
+ <pos>70,140d</pos>
+ <size>135,12d</size>
+ <style>wxCB_READONLY|wxCB_DROPDOWN</style>
+ </object>
+ <flag>wxEXPAND|wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="wxStaticText" name="stFinalFunc">
+ <label>Final function</label>
+ <pos>5,157d</pos>
+ </object>
+ <flag>wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="wxComboBox" name="cbFinalFunc">
+ <content/>
+ <pos>70,155d</pos>
+ <size>135,12d</size>
+ <style>wxCB_READONLY|wxCB_DROPDOWN</style>
+ </object>
+ <flag>wxEXPAND|wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="wxStaticText" name="stSortOp">
+ <label>Sort Operator</label>
+ <pos>5,172d</pos>
+ </object>
+ <flag>wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="wxComboBox" name="cbSortOp">
+ <content/>
+ <pos>70,170d</pos>
+ <size>135,12d</size>
+ <style>wxCB_READONLY|wxCB_DROPDOWN</style>
+ </object>
+ <flag>wxEXPAND|wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="wxStaticText" name="stInitial">
+ <label>Initial condition</label>
+ <pos>5,187d</pos>
+ </object>
+ <flag>wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="wxTextCtrl" name="txtInitial">
+ <pos>70,185d</pos>
+ <size>135,-1d</size>
+ </object>
+ <flag>wxEXPAND|wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ </object>
+ </object>
</object>
- <object class="wxStaticText" name="stOID">
- <label>OID</label>
- <pos>5,22d</pos>
- </object>
- <object class="wxTextCtrl" name="txtOID">
- <pos>70,20d</pos>
- <size>135,-1d</size>
- </object>
- <object class="wxStaticText" name="stOwner">
- <label>Owner</label>
- <pos>5,37d</pos>
- </object>
- <object class="ctlComboBox" name="cbOwner">
- <pos>70,35d</pos>
- <size>135,12d</size>
- <content/>
- <style>wxCB_DROPDOWN</style>
- </object>
- <object class="wxStaticText" name="stComment">
- <label>Comment</label>
- <pos>5,52d</pos>
- </object>
- <object class="wxTextCtrl" name="txtComment">
- <pos>70,50d</pos>
- <size>135,132d</size>
- <style>wxTE_MULTILINE</style>
- </object>
- <object class="wxStaticText" name="stClusterSet">
- <label>Use replication</label>
- <pos>5,187d</pos>
- </object>
- <object class="wxComboBox" name="cbClusterSet">
- <content/>
- <pos>70,185d</pos>
- <size>135,12d</size>
- <style>wxCB_READONLY|wxCB_DROPDOWN</style>
- </object>
</object>
- <selected>1</selected>
+ <flag>wxALL|wxGROW|wxALIGN_CENTRE</flag>
+ <border>3</border>
</object>
- <pos>2,2d</pos>
- <size>214,215d</size>
- <object class="notebookpage">
- <label>Definition</label>
- <object class="wxPanel" name="pnlDefinition">
- <object class="wxStaticText" name="stInputTypes">
- <label>Input types</label>
- <pos>5,7d</pos>
+ <growablecols>0</growablecols>
+ <growablerows>0</growablerows>
+ <object class="spacer">
+ <size>2,2d</size>
+ </object>
+ <object class="sizeritem">
+ <object class="wxFlexGridSizer">
+ <cols>7</cols>
+ <object class="spacer">
+ <size>3,3d</size>
</object>
- <object class="wxListCtrl" name="lstInputTypes">
- <pos>70,5d</pos>
- <size>135,97d</size>
- <style>wxLC_REPORT</style>
+ <object class="sizeritem">
+ <object class="wxButton" name="wxID_HELP">
+ <label>Help</label>
+ <pos>135,220d</pos>
+ </object>
</object>
- <object class="wxButton" name="btnRemoveType">
- <label>&amp;Remove</label>
- <pos>5,87d</pos>
- <size>60,-1d</size>
+ <object class="spacer">
+ <size>3,3d</size>
</object>
- <object class="wxButton" name="btnAddType">
- <label>&amp;Add</label>
- <pos>5,105d</pos>
- <size>60,-1d</size>
+ <object class="sizeritem">
+ <object class="wxButton" name="wxID_OK">
+ <label>&amp;OK</label>
+ <default>1</default>
+ <pos>135,220d</pos>
+ </object>
</object>
- <object class="ctlComboBox" name="cbInputType">
- <content/>
- <pos>70,105d</pos>
- <size>135,12d</size>
- <style>wxCB_DROPDOWN</style>
+ <object class="spacer">
+ <size>3,3d</size>
</object>
- <object class="wxStaticText" name="stStateType">
- <label>State type</label>
- <pos>5,127d</pos>
+ <object class="sizeritem">
+ <object class="wxButton" name="wxID_CANCEL">
+ <label>&amp;Cancel</label>
+ <pos>176,220d</pos>
+ </object>
</object>
- <object class="ctlComboBox" name="cbStateType">
- <content/>
- <pos>70,125d</pos>
- <size>135,12d</size>
- <style>wxCB_DROPDOWN</style>
+ <object class="spacer">
+ <size>3,3d</size>
</object>
- <object class="wxStaticText" name="stStateFunc">
- <label>State function</label>
- <pos>5,142d</pos>
- </object>
- <object class="wxComboBox" name="cbStateFunc">
- <content/>
- <pos>70,140d</pos>
- <size>135,12d</size>
- <style>wxCB_READONLY|wxCB_DROPDOWN</style>
- </object>
- <object class="wxStaticText" name="stFinalFunc">
- <label>Final function</label>
- <pos>5,157d</pos>
- </object>
- <object class="wxComboBox" name="cbFinalFunc">
- <content/>
- <pos>70,155d</pos>
- <size>135,12d</size>
- <style>wxCB_READONLY|wxCB_DROPDOWN</style>
- </object>
- <object class="wxStaticText" name="stSortOp">
- <label>Sort Operator</label>
- <pos>5,172d</pos>
- </object>
- <object class="wxComboBox" name="cbSortOp">
- <content/>
- <pos>70,170d</pos>
- <size>135,12d</size>
- <style>wxCB_READONLY|wxCB_DROPDOWN</style>
- </object>
- <object class="wxStaticText" name="stInitial">
- <label>Initial condition</label>
- <pos>5,187d</pos>
- </object>
- <object class="wxTextCtrl" name="txtInitial">
- <pos>70,185d</pos>
- <size>135,-1d</size>
- </object>
+ <growablecols>2</growablecols>
</object>
+ <flag>wxTOP|wxLEFT|wxRIGHT|wxGROW</flag>
</object>
+ <object class="spacer">
+ <size>3,3d</size>
+ </object>
+ <object class="sizeritem">
+ <object class="unknown" name="unkStatusBar">
+ <size>-1,15d</size>
+ </object>
+ <flag>wxGROW|wxALIGN_CENTRE</flag>
+ <border>3</border>
+ </object>
</object>
- <object class="wxButton" name="wxID_HELP">
- <label>Help</label>
- <pos>3,221d</pos>
- </object>
- <object class="wxButton" name="wxID_OK">
- <label>&amp;OK</label>
- <default>1</default>
- <pos>113,221d</pos>
- </object>
- <object class="wxButton" name="wxID_CANCEL">
- <label>&amp;Cancel</label>
- <pos>166,221d</pos>
- </object>
- <size>218,240d</size>
- <style></style>
</object>
</resource>
Guillaume Lelarge a écrit :
> [...]
> I tend to prefer the "one patch for each dialog" approach, but I would
> like to know your thoughts on this.
>

Here is the first one, dlgAggregate.xrc.

--
Guillaume.

http://www.postgresqlfr.org

http://dalibo.com

Re: [pgsql-es-ayuda] recomendacion tipo columnas de fecha/hora

Alvaro Herrera escribió:
> Linos escribió:
>> Hola,
>> estoy diseñando una base de datos nueva y para algunas de las tablas
>> (la mayoría en realidad), al guardar/actualizar los registros quiero que
>> se quede guardada la fecha y la hora para futuras consultas, es algo que
>> luego ha de verse en todas las consultas, la duda que tengo es utilizo
>> dos columnas fecha date, hora time? o debería usar un timestamp?
>
> Deberías usar "timestamp with time zone". Es muy raro que el tipo
> "timestamp" sea apropiado en una aplicacion.
>
>> si la columna no la voy a ordenar normalmente por timestamp dos
>> columnas me permitirían no tener que usar un cast de la columna de
>> timestamp a date y time en cada consulta a las tablas (ya que al
>> usuario no le puedo mostrar el timestamp directamente)
>
> Ese es un problema bastante menor. Si realmente quieres ahorrarte ese
> codigo en la aplicacion, puedes crear una vista que tenga las columnas
> que te parezcan. Personalmente no creo que valga la pena.
>

Tiene sentido usar "timestamp with time zone" cuando la aplicación es un tpv que van a usar unos cuantos
usuarios todos dentro de la misma zona horaria? la verdad es q en la documentación de postgresql no he
conseguido aclararme este punto. Yo he probado los dos tipos y me funcionan (bueno no he probado desde qt si
puedo insertar una hora sin indicar la zona horaria pero por lo demás bien) pero si no voy a usar lo de las
zonas, supongo que sera mas eficiente no manejar esa información, no? Un saludo.
--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

Re: [pgsql-es-ayuda] Hora del Servidor

2008/7/7 Alvaro Herrera <alvherre@commandprompt.com>:
> Seguramente esta identificando mal el huso horario de tu sistema
> operativo, y por lo tanto hace un "fallback" a GMT. Prueba que pasa si
> pones el nombre de tu huso horario en TimeZone en postgresql.conf
> (supongo que podria ser America/Mexico_City u otra).
>

Alvaro..

Cheque la vista pg_timezone_names para verificar lo que me comentas...
coloque America/Mexico_City... reinicie el servidor y funciono!!! Ya
no hay problemas de retraso con la hora... solo que.... estoy haciendo
un programita y necesito cambiar los usos horarios para Costa Rica,
Colombia y Argentina (dependiendo de donde utilicen el programa),
quizas me vas a contestar que coloque el uso horario para cada uno..
pero yo quisiera saber si existe alguna forma que el servidor de
Postgres tome la hora en base a la configuración regional que tenga
previamente configurada la computadora. Se puede hacer esto... ?? O no
??

Otra cosa cual es el uso horario de colombia ?? No lo encontre en la
vista que te mencione...

Saludos cordiales y muchas gracias por tu ayuda.-
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

Re: [GENERAL] pgmemcache status

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

> Is pgmemcache still being actively supported/developed? I have
> experienced a database crash with postgres 8.3.3 and pgmemcache 1.2beta1

Yes and no. I just joined up, and hope to be submitting some patches
to it soon, as well as push to get a new version out the door, but
there has not been much movement on it lately.

> Doing select * from pg_settings (with shared_preload_libraries defined
> and no custom variable definitions) causes a server reset.

Thanks, I'll see if I can duplicate.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200807091718
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkh1K1sACgkQvJuQZxSWSsilUwCgqeEm79wVqE2eKoEz/eBWeXU/
E68AoOGMK2CJ+oyJ04+OCgJvmuhvnxDy
=HC2I
-----END PGP SIGNATURE-----

--
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] PATCH: CITEXT 2.0 v3

David E. Wheeler wrote:
> On Jul 9, 2008, at 13:40, Alvaro Herrera wrote:

>> One thing that jumps at me is pgTAP usage, as Zdenek said. I
>> understand that it's neat and all that, but we can't include the
>> tests because they won't run unless one installs pgTAP which seems a
>> nonstarter. So if you want the tests in the repository along the
>> rest of the stuff, they really should use pg_regress.
>
> It does use pg_regress. The test just load the included pgtap.sql file
> to get the tap functions, and then away they go. If you run `make
> installcheck` it works.

Uh-huh, OK, that's fine then I guess.

--
Alvaro Herrera

http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
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] PATCH: CITEXT 2.0 v3

On Jul 9, 2008, at 13:40, Alvaro Herrera wrote:

> The problem is that we're in the middle of a commitfest, so
> everybody is
> busy reviewing other patches (in theory at least).

Of course.

> One thing that jumps at me is pgTAP usage, as Zdenek said. I
> understand
> that it's neat and all that, but we can't include the tests because
> they
> won't run unless one installs pgTAP which seems a nonstarter. So if
> you
> want the tests in the repository along the rest of the stuff, they
> really should use pg_regress.

It does use pg_regress. The test just load the included pgtap.sql file
to get the tap functions, and then away they go. If you run `make
installcheck` it works.

> It's not even difficult to use. Have a look at contrib/ltree/sql and
> contrib/ltree/expected for examples.
>
> If you want to push for pgTAP in core, that's fine, but it's a
> separate
> discussion.

Agreed. I've sent a couple of messages in a thread about that, the
latest this morning.

> The other possibility being, of course, that you are proposing
> citext to
> live on pgFoundry.

I'm not, actually. I mean, I have an updated version for 8.3, but it'd
be quite a pita to maintain them both, since the api for lowercasing
text is so much simpler in 8.4.

Best,

David

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

Re: [GENERAL] MSSQL to PostgreSQL

> Hi Ray,
>
> I have something that does this. I am currently awaiting project
> approval on pgfoundry.
> It does tables, views, and stored procedures. I have tested it on
> 450,000 lines of mssql code
> including 400 tables and 3700 stored procedures, although it is a work
> in progress.
>
> I applied last week and they said it takes 72 hours. As soon as it is
> approved I can post it.
> (give it a couple days I guess)
>
> Gwyneth

Hi Gwyneth,

sounds very interesting.

We found this -

http://wiki.postgresql.org/wiki/Converting_your_data_from_MS_SQL_Server_7_to_PostgreSQL_7.1.x

(for very old version)

- it is surprising that the SQL Enterprise Manager does this... We gave
it a little try today and saw that indeed, there is "PostgreSQL" in
there. But we left to try it tomorrow. Do you know it?

We do not have stored procedures, only tables and views. Would be, in
any case, interested in seeing what you have.

Iv

--
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] Summary of some postgres portability issues

On Wed, Jul 09, 2008 at 03:03:48PM -0400, Ken Camann wrote:
> On Wed, Jul 9, 2008 at 3:35 AM, Martijn van Oosterhout
> <kleptog@svana.org> wrote:
>
> > Just clarifying for myself: you are mostly listing theoretical problems
> > here, not actual "I ran it and got regression failures" problems, right?
>
> Correct. This is why most of them point out that they are not
> actually real problems, just written in a less than ideal way.

> I'd fix them, but would anyone be willing to commit that?

Probably, as long as the proposed fix don't break any other already
supported platform.

> I know that a Datum cannot be bigger than 1 GB either way, but the
> documentation around the Datum typedef notes that Datum must large
> enough to hold a pointer. It does not say why, or where this
> assumption gets used, or why it was made.

Firstly, I'd suggest checking out the docs on CREATE TYPE, to see the
possibilities:
http://www.postgresql.org/docs/8.2/static/sql-createtype.html

Basically, a Datum can represent any type you can see from SQL. It must
be big enough to hold a pointer because in most cases, it *is* a
pointer. There's essentially three possibilities:

- Small integral type: eg: float/int4/int2/bool, these are simply
stored as the Datum itself.
- Fixed width type: eg: point/complex, here the Datum is a pointer to
the data
- Variable length type: text/varchar, here the Datum is a pointer to a
header which describes the actual length.

The actual assumptions are listed somewhere in the header defining
Datum.

> As for what would replace it, I think intptr_t. This type has the
> same size as long on LP32, ILP32, LP64, and ILP64 so there would be no
> changes to anything that already works, plus this type can hold a
> pointer on LLP64 compilers.

Does this type exist on all the other systems? Not everywhere is C99
unfortunatly.

> > I don't understand what you mean here: the Datum type has very clear
> > rules about how it is stored. It is essentially opaque, but given the
> > typlen you have enough information to know how to copy it for example.
>
> Well, that is some good news. Where can I find these rules?

I think I explained it enough above, if you have any more questions,
just ask.

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: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP

* David Fetter <david@fetter.org> [080709 14:45]:
> On Tue, Jul 08, 2008 at 09:28:34PM -0400, Alvaro Herrera wrote:

> > In fact, I fail to see the point of you providing the repo if the
> > upstream guys are apparently not using it ...
>
> It's *very* early days to be dismissing git entirely. We don't have
> auths fixed up yet, and I contend that that's because the people who
> have sudo on the git machine are unwilling to create git-shell
> accounts for people who need them.

I don't think that was intended to dismiss git entirely, but only
question what the point of this particular git repo/branch is for:
http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=shortlog;h=with_recursive

Is it just to provide an alternative way to fetch the patch? I would
have thought that anybody who can compile PostgreSQL from source can
apply a patch (if the patch available and applies cleanly).

The with_recursive branch doesn't seem to provide any of the nice
goodies that git could provide (i.e. patch history, merge corresponding
to various versions so you can easily see what changed, etc)

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] PATCH: CITEXT 2.0 v3

David E. Wheeler wrote:
> I guess you're all just blown away by the perfection of this patch? ;-)

The problem is that we're in the middle of a commitfest, so everybody is
busy reviewing other patches (in theory at least).

One thing that jumps at me is pgTAP usage, as Zdenek said. I understand
that it's neat and all that, but we can't include the tests because they
won't run unless one installs pgTAP which seems a nonstarter. So if you
want the tests in the repository along the rest of the stuff, they
really should use pg_regress.

It's not even difficult to use. Have a look at contrib/ltree/sql and
contrib/ltree/expected for examples.

If you want to push for pgTAP in core, that's fine, but it's a separate
discussion.

The other possibility being, of course, that you are proposing citext to
live on pgFoundry.

--
Alvaro Herrera

http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
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] No answers on CommitFest procedures?

"Neil Conway" <neilc@samurai.com> writes:

> On Wed, 2008-07-09 at 14:38 -0400, Alvaro Herrera wrote:
>> But patches in progress still need comments from reviewers.
>
> Certainly, but should this be done as part of the commit fest process?
> Commenting on the future direction that an in-development patch ought to
> take sounds more like a task for -hackers at large, rather than for an
> individual reviewer.

This is, from my point of view as a patch submitter, the *whole* *point* of
the commitfests. For 8.3 We had lots of people submit patches, then sit around
for months waiting for feedback. By the time they got feedback the patches had
bitrotten and it was feature-freeze time and there was a lot of pressure to
finish patches quickly.

If the author isn't looking for feedback the patch wouldn't be in the commit
fest queue.

"WIP" just means the submitter knows the patch isn't ready to commit yet.
They're probably stuck on a major design decision or just want confirmation
that they're on the right track before they invest months more of work.

I used "proof of concept" for one of my patches just to indicate it was just a
quick hack to demonstrate an idea. In this case the implementation details are
not so relevant as just whether we like the idea at all.

--
Gregory Stark
EnterpriseDB

http://www.enterprisedb.com

Ask me about EnterpriseDB's Slony Replication support!

--
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] PATCH: CITEXT 2.0 v3

I guess you're all just blown away by the perfection of this patch? ;-)

Best,

David

On Jul 7, 2008, at 18:03, David E. Wheeler wrote:

> Attached is a new version of a patch to add a CITEXT contrib module.
> Changes since v2:
>
> * Optimized citext_eq() and citext_ne() (the = and <> operators,
> respectively) by having them use strncmp() instead of varstr_cmp().
> Per discussion.
>
> * Added `RESTRICT` and `JOIN` clauses to the comparison operators
> (=, <>, <, >, <=, >=). These improve statistics estimations,
> increasing the liklihood that indices will be used.
>
> Thanks!
>
> David

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

[pgsql-advocacy] Need volunteers for LinuxWorldExpo & pgDay San Francisco!

Folks,

We're going to have the biggest pgDay ever at LinuxWorld SF -- we already
have *480 people* registered. But this means that we need some help to
run it. If you will be at LinuxWorldExpo this August in San Francisco,
please sign up to help us with the booth or the pgDay:

http://wiki.postgresql.org/wiki/LinuxWorldExpo_2008

If you don't want to sign up for a wiki account, please e-mail me the slots
you're volunteering for, as well as your cell phone number.

(for those of you who were at the SFPUG meeting last night, I had a
beer-related accident with the sign-up sheet, and may have lost some of
your information. So please check it, and re-send to me if I lost
something)

--
--Josh

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

Re: [JDBC] Patch to allow setting schema/search_path in the connectionURL

On Wed, 9 Jul 2008, Heikki Linnakangas wrote:

> I think it would be more useful to provide a way to set any GUC variable in
> the connection string, not just search_path.
>

In previous discussions:

http://archives.postgresql.org/pgsql-jdbc/2004-02/thrd2.php#00022

One significant roadblock was how to handle the Datasource implementation
which needs to know all the available GUC parameters at compile time:

http://archives.postgresql.org/pgsql-jdbc/2004-02/msg00037.php

I'm not particularly excited about enumerating them all and the suggested
alternative methods of passing these values in Properties, String[][]
don't seem terribly appealing

Kris Jurka

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

Re: [GENERAL] rollback

On Wed, 2008-07-09 at 15:38 +0200, Adrian Moisey wrote:

> I would like to be able to "mark" a point in my postgres database.
> After that I want to change a few things and "rollback" to that
> point.
> Does postgres support such a thing? Is it possible for me to do this?

* Transactions ;-)

* PITR

* Build an application-level undo infrastructure using reverse action
triggers.

* Various internal ways not usually attempted.

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support

--
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-it-generale] Costruttore degli array con record "completi"

Ciao Giorgio,
un problema simile l'ho avuto nell'utilizzo dei dati array mixati con
i dati normali per produrre set ordinati.

La cosa l'ho risolta con una funzione plpgsql ritornante un recordset.
Appena rientro ti posto un esempio.

Bisogna giocare un po' anche con i tipi personalizzati ma il gioco
vale la candela in quanto le prestazioni sono decisamente interessanti
in quanto questo approccio determina l'elaborazione dei recordset
nello shared buffer e limita al minimo indispensabile il transito dei
dati tra l'applicazione e il database.

Ciao
Federico

2008/7/9 Giorgio Valoti <giorgio_v@mac.com>:
> Ciao a tutti, avrei una curiosità da soddisfare. So che è possibile scrivere
> una query del tipo:
>
> select a, b, c, ..., array (select x from table_x...) as t_x from table_a
>
> ma non riesco a creare una query di questo tipo:
>
> select a, b, c, ..., array (select * from table_x...) as t_x from table_a
>
> L'errore che dà è: "ERROR: subquery must return only one column". La cosa è
> documentata, in effetti
> (http://www.postgresql.org/docs/8.3/interactive/sql-expressions.html), ma
> volevo sapere se c'è un qualche modo di aggirare questa limitazione. L'idea,
> come forse avrete già capito, è quella di nidificare dei valori in modo da
> poter creare query che restituiscano un singolo record al punto della più
> classica join, facilitando il campo all'applicazione.
> Qualcuno ha qualche suggerimento?
>
> Grazie in anticipo
> --
> Giorgio Valoti
> --
> Sent via pgsql-it-generale mailing list (pgsql-it-generale@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-it-generale
>

--
(all opinions expressed are my own)
Federico Campoli
PostgreSQL Consulting -> PGHost http://www.pghost.eu

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