[GENERAL] ANN: PL/Java now supports both PostgreSQL 8.0 and 7.4

2004-08-22 Thread Thomas Hallgren
I tried this on the pgsql-announce list but for some reason it doesn't 
show up.

The 1.0.0.b4 release of PL/Java is out. It takes full advantage of the
new exception handling and custom variables introduced in PostgreSQL 8.0
and a native Windows port is included in the distribution (7.4 still
supported with Cygwin on Windows).
On Linux, PL/Java 1.0.0.b4 includes binary distributions compiled using
GCJ (the GNU Java) to take full advantage of Postgres capability of
using preloaded modules.
Please visit http://gborg.postgresql.org/project/pljava for more info.
Regards,
Thomas Hallgren

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
 subscribe-nomail command to [EMAIL PROTECTED] so that your
 message can get through to the mailing list cleanly


Re: [GENERAL] restoring a .dmp file to another table name

2004-08-22 Thread Tino Wildenhain
Hi,

Am Mo, den 23.08.2004 schrieb Mike Nolan um 6:15:
> I've probably asked this question before, but what do people do when they
> need to restore a table that has been dumped but as a different table
> name?  That doesn't appear to be an option in pg_restore.  (Is that just
> a front end to psql?)
> 
> I need both the old table and the live one in the same database so
> that I can compare a set of values to see what changed, and I don't have
> a spare system to do it on at the moment, nor can I rename the live file
> since it is in use most of the day.  
> 
> This is a fairly large table (2.8M rows, 500MB dump file) and I think 
> it may have some data in it that would get messed up if I were to try to 
> extract the DDL leading up to the COPY statement using head and tail
> statements to change the table name.

Just use pg_restore -t tablename (and the other options according to
your pg_dump) and write the results in a file. Use an editor to change
tablename to your new tablename in the result. If you are absolute
sure your tablename does not appear as data payload in the table,
you can use sed like this:

pg_restore -t tablename | sed -e "s/tablename/newtablename/" | psql

HTH
Tino Wildenhain


---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


[GENERAL] restoring a .dmp file to another table name

2004-08-22 Thread Mike Nolan
I've probably asked this question before, but what do people do when they
need to restore a table that has been dumped but as a different table
name?  That doesn't appear to be an option in pg_restore.  (Is that just
a front end to psql?)

I need both the old table and the live one in the same database so
that I can compare a set of values to see what changed, and I don't have
a spare system to do it on at the moment, nor can I rename the live file
since it is in use most of the day.  

This is a fairly large table (2.8M rows, 500MB dump file) and I think 
it may have some data in it that would get messed up if I were to try to 
extract the DDL leading up to the COPY statement using head and tail
statements to change the table name.
--
Mike Nolan

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [GENERAL] Unsupported 3rd-party solutions (Was: Few questions

2004-08-22 Thread Marc G. Fournier
On Sun, 22 Aug 2004, Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
Perhaps I'm a bit to visionary. But I really think you (the core
commitee) need to consider this.
[ looks at Bruce's and Marc's quite independent responses ... ]  I think
the core committee has made it perfectly clear that we don't want to
take this on.
Ya, I think Bruce and I said about the same thing, just from different 
angles ... and I'm sticking to that story :)


Marc G. Fournier   Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED]   Yahoo!: yscrappy  ICQ: 7615664
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [GENERAL] Unsupported 3rd-party solutions (Was: Few questions on postgresql (dblink, 2pc, clustering))

2004-08-22 Thread Jim Worke
On Sunday 22 August 2004 16:45, you wrote:
> Jim Worke wrote:
> > I don't mean to be rude or anything, but having 3rd-party solution is a
> > scary option for a business enterprise.  I know that they're stable and
> > all, but if it's not supported by PostgreSQL themselves (i.e. included in
> > PostgreSQL as a whole package), we're afraid that we have to change our
> > code/design in case the product has stopped progress.
> >
> > For example, pgcluster's patch is for PostgreSQL 7.3.6.  It's not in sync
> > with PostgreSQL's current version (I'm not blaming the guy... He's
> > created a very good solution and I'm thankful for that).  It's just that
> > for my company (and I guess many other companies too), it's more
> > appealing to have a database solution that comes in a package.
>
> Those are very interesting remarks. I'm the author of PL/Java, a module
> that also could be thought of as "not supported by PostgreSQL
> themselves", and I've made the same reflection as you have. It would be
> beneficial to have some organisational entity within Postgres where this
> issue could be addressed (i.e. packaging/synchronization and supported
> configurations). I think it could give a real boost to PostgreSQL as such.
>
> Sure, an open source community does not make support commitments. But
> the PostgreSQL community is large and that creates (a sense of) safety
> and continuity. This sense is not automatically transferred to the
> "3rd-party solutions".
>
>  From a users perspective and perhaps especially from the decision
> makers perspective, the fact that you have to download various modules
> from gborg etc. is indeed scary. Who will support your chosen solution a
> year from now? IMHO, if PosgreSQL is aiming for larger business
> acceptance, this has to be resolved. Contributors like myself must be
> given the opportunity to get things "verified" and checked in as
> "supported". It would do PostgreSQL an awful lot of good if there where
> supported configurations including replication, server side language
> support (Perl, Tcl, Java, etc.), JDBC and ODCB drivers, and other things
> that you'd normally find in commercial enterprise solutions.

I'm CC'ing this to the postgresql mailing list.

I fully agree to your statement (to get things "verified" and checked in as 
"supported").  Hopefully there's a way out for this...

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [GENERAL] Few questions on postgresql (dblink, 2pc, clustering)

2004-08-22 Thread Gaetano Mendola
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Worke wrote:
| On Sunday 22 August 2004 11:02, Bruce Momjian wrote:
|
|>2-phase isn't in 8.0 but I expect it in 8.1.
|
|
| Is it possible to know when is 8.1 going to be released for production (an
| estimate)?
Consider that 8.0 will be release *may be* during the end of this year.
Usually a development cycle between two release is 9 month and + 3 month
beta let me say: 8.1 will be release in 12 months. The core will try to
have a shortest cycle for 8.1 but I'll not bet on it.
|>>Basically, our concern is that dblink, 2PC implementation are there, but
|>>not in the PostgreSQL mainstream.
|>
|>You need to understand the limitations of dblink and see if it will work
|>for you.  I can't imagine MySQl is allowing you to do this cleanly so I
|>don't see why it would hold up a MySQL -> PostgreSQL migration.
| Hmm... forgive me for saying it wrongly.  We're actually "thinking" of
| migrating to PostgreSQL.  Here's our case:
|
| We're going to do a major upgrading on our PHP code (from PHP 3 style to PHP
| 5.0), and was thinking of changing the database to PostgreSQL too.
| Currently, the number of transaction is not high, but we'd like to have a
| more scalable solution.
|
| MySQL does not allow cross-server database connection such as dblink.  So,
| we're thinking of 3 alternatives:
|
| 1) Wait for MySQL clustering to be stable and put all our databases in the
| cluster
| 2) Migrate to PostgreSQL and use dblink to solve the referential integrity
| 3) Migrate to PostgreSQL clustering solution
May I know why are you sticky on the idea of spread your database among
various servers ? Free your mysql-minded. If you idea is an horizontal
scale solution then open your wallet and buy Oracle.
Postgresql scale very well vertically.

Another solution is hack the postmaster in order to have two parallel
postmaster running on the same server ( first phase ), when you did
this successfully then the second phase ( to hack too ) is buy the
hardware that permit more servers to share an unique shared memory
segment and then with the help of SAN you can have two postmaster that
are running on two different server that are belonging to a SAN and the
common shared memory segment.

Right now your only solution is buy a multiprocessor machine.
Regards
Gaetano Mendola






-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBKG6x7UpzwH2SGd4RAn06AKCQ50Nbp8qvNlMQt2TZqCEcrsMWdgCgphRC
aAn1xCqgGYIh0KtSy3s4zSI=
=iDku
-END PGP SIGNATURE-
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


[GENERAL] Unsupported 3rd-party solutions (Was: Few questions on postgresql (dblink, 2pc, clustering))

2004-08-22 Thread Thomas Hallgren
Jim Worke wrote:
I don't mean to be rude or anything, but having 3rd-party solution is a scary 
option for a business enterprise.  I know that they're stable and all, but if 
it's not supported by PostgreSQL themselves (i.e. included in PostgreSQL as a 
whole package), we're afraid that we have to change our code/design in case 
the product has stopped progress.

For example, pgcluster's patch is for PostgreSQL 7.3.6.  It's not in sync with 
PostgreSQL's current version (I'm not blaming the guy... He's created a very 
good solution and I'm thankful for that).  It's just that for my company (and 
I guess many other companies too), it's more appealing to have a database 
solution that comes in a package.

Those are very interesting remarks. I'm the author of PL/Java, a module 
that also could be thought of as "not supported by PostgreSQL 
themselves", and I've made the same reflection as you have. It would be 
beneficial to have some organisational entity within Postgres where this 
issue could be addressed (i.e. packaging/synchronization and supported 
configurations). I think it could give a real boost to PostgreSQL as such.

Sure, an open source community does not make support commitments. But 
the PostgreSQL community is large and that creates (a sense of) safety 
and continuity. This sense is not automatically transferred to the 
"3rd-party solutions".

From a users perspective and perhaps especially from the decision 
makers perspective, the fact that you have to download various modules 
from gborg etc. is indeed scary. Who will support your chosen solution a 
year from now? IMHO, if PosgreSQL is aiming for larger business 
acceptance, this has to be resolved. Contributors like myself must be 
given the opportunity to get things "verified" and checked in as 
"supported". It would do PostgreSQL an awful lot of good if there where 
supported configurations including replication, server side language 
support (Perl, Tcl, Java, etc.), JDBC and ODCB drivers, and other things 
that you'd normally find in commercial enterprise solutions.

Regards,
Thomas Hallgren
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])


Re: [GENERAL] Few questions on postgresql (dblink, 2pc, clustering)

2004-08-22 Thread Jim Worke
On Sunday 22 August 2004 11:02, Bruce Momjian wrote:
> 2-phase isn't in 8.0 but I expect it in 8.1.

Is it possible to know when is 8.1 going to be released for production (an 
estimate)?

>
> > Basically, our concern is that dblink, 2PC implementation are there, but
> > not in the PostgreSQL mainstream.
>
> You need to understand the limitations of dblink and see if it will work
> for you.  I can't imagine MySQl is allowing you to do this cleanly so I
> don't see why it would hold up a MySQL -> PostgreSQL migration.

Hmm... forgive me for saying it wrongly.  We're actually "thinking" of 
migrating to PostgreSQL.  Here's our case:

We're going to do a major upgrading on our PHP code (from PHP 3 style to PHP 
5.0), and was thinking of changing the database to PostgreSQL too.  
Currently, the number of transaction is not high, but we'd like to have a 
more scalable solution.

MySQL does not allow cross-server database connection such as dblink.  So, 
we're thinking of 3 alternatives:

1) Wait for MySQL clustering to be stable and put all our databases in the 
cluster
2) Migrate to PostgreSQL and use dblink to solve the referential integrity
3) Migrate to PostgreSQL clustering solution

If (2) and (3) is not viable, then we'd rather not migrate the database to 
PostgreSQL for now (if it ain't broke, don't fix it)...

So, it's not actually holding us up, but just that we're not able to make 
decision yet.

> > Another thing that bothers us is that we can't find any multi-master
> > clustering solution in PostgreSQL.  We're actually evaluating MySQL's own
> > clustering solution, but it's production quality release is still slated
> > for MySQL 5.0.
>
> The only multi-master I know of is pgcluster.  There is talking of
> moving Slony from master/slave to multi-master but work has not started
> yet.

I don't mean to be rude or anything, but having 3rd-party solution is a scary 
option for a business enterprise.  I know that they're stable and all, but if 
it's not supported by PostgreSQL themselves (i.e. included in PostgreSQL as a 
whole package), we're afraid that we have to change our code/design in case 
the product has stopped progress.

For example, pgcluster's patch is for PostgreSQL 7.3.6.  It's not in sync with 
PostgreSQL's current version (I'm not blaming the guy... He's created a very 
good solution and I'm thankful for that).  It's just that for my company (and 
I guess many other companies too), it's more appealing to have a database 
solution that comes in a package.

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster