Re: Oracle and Postgresql - Mailing list pgsql-general
| From | Martin Gainty |
|---|---|
| Subject | Re: Oracle and Postgresql |
| Date | |
| Msg-id | BLU142-W10525953C429920AAADCC4AE440@phx.gbl Whole thread Raw |
| In response to | Re: Oracle and Postgresql (Casey Allen Shobe <cshobe@bepress.com>) |
| List | pgsql-general |
depends on Postgres support for Oracle java packages which is now available thru PL/Java
http://my.safaribooksonline.com/0672327562/ch19lev1sec1
Martin
______________________________________________
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission.
> From: cshobe@bepress.com
> To: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Oracle and Postgresql
> Date: Thu, 25 Sep 2008 11:15:24 -0700
>
> On Sep 4, 2008, at 7:40 PM, Robert Treat wrote:
> > It is not as simple as Oracles database link syntax. Setting up a
> > connection
> > involves a couple of sql looking commands, and once you setup a
> > connection to
> > a remote database, you can reference a table with something like
> > select *
> > from mytable@myotherdb. There's no way a function oriented solution
> > can
> > match that imho.
>
> I have long thought that what would be really useful is a standard way
> for third-party modules to extend or override the SQL language support
> within PostgreSQL itself without needing to be integrated in core.
>
> E.g. it should be possible for all of EnterpriseDB's Oracle-compatible
> SQL changes to exist as a separate module, somebody could change the
> behavior of a select to default ordering to imitate Oracle etc. It
> should be possible for a replication engine to add syntax for options
> specific to it. Contrib modules like dblink could install SQL-like
> command support.
>
> This would be both invaluable for compatibility efforts and probably
> raise the amount of 3rd party stuff that actually gets used
> (currently, many places I've seen avoid Slony because they fear having
> to use the commandline scripts it comes with, and if you want to
> manipulate Slony from the database itself, oftentimes this means you
> have to use pl/perlu or another untrusted language.
>
> Don't get me wrong, functions are great too. :) But currently the
> above means that a lot of risk is introduced and you have to put a lot
> of faith in the perl code - an exploit poses a lot of risk. If Slony
> exposed it's own data to PG via custom SQL extensions, this would be
> more secure by design.
>
> Cheers,
> --
> Casey Allen Shobe
> Database Architect, The Berkeley Electronic Press
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
Stay up to date on your PC, the Web, and your mobile phone with Windows Live. See Now
http://my.safaribooksonline.com/0672327562/ch19lev1sec1
Martin
______________________________________________
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission.
> From: cshobe@bepress.com
> To: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Oracle and Postgresql
> Date: Thu, 25 Sep 2008 11:15:24 -0700
>
> On Sep 4, 2008, at 7:40 PM, Robert Treat wrote:
> > It is not as simple as Oracles database link syntax. Setting up a
> > connection
> > involves a couple of sql looking commands, and once you setup a
> > connection to
> > a remote database, you can reference a table with something like
> > select *
> > from mytable@myotherdb. There's no way a function oriented solution
> > can
> > match that imho.
>
> I have long thought that what would be really useful is a standard way
> for third-party modules to extend or override the SQL language support
> within PostgreSQL itself without needing to be integrated in core.
>
> E.g. it should be possible for all of EnterpriseDB's Oracle-compatible
> SQL changes to exist as a separate module, somebody could change the
> behavior of a select to default ordering to imitate Oracle etc. It
> should be possible for a replication engine to add syntax for options
> specific to it. Contrib modules like dblink could install SQL-like
> command support.
>
> This would be both invaluable for compatibility efforts and probably
> raise the amount of 3rd party stuff that actually gets used
> (currently, many places I've seen avoid Slony because they fear having
> to use the commandline scripts it comes with, and if you want to
> manipulate Slony from the database itself, oftentimes this means you
> have to use pl/perlu or another untrusted language.
>
> Don't get me wrong, functions are great too. :) But currently the
> above means that a lot of risk is introduced and you have to put a lot
> of faith in the perl code - an exploit poses a lot of risk. If Slony
> exposed it's own data to PG via custom SQL extensions, this would be
> more secure by design.
>
> Cheers,
> --
> Casey Allen Shobe
> Database Architect, The Berkeley Electronic Press
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
Stay up to date on your PC, the Web, and your mobile phone with Windows Live. See Now
pgsql-general by date: