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: [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] 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. http://clk.atdmt.com/MRT/go/msnnkwxp1020093185mrt/direct/01/
