Re: [GENERAL] Getting iPhone Simulator App to compile with libpq on Snow Leopard
Thanks Jan that was the issue. The SDK that my app was using for the simulator build was was 10.5 while the my compile of libpq was using 10.6. Once I forced libpq to compile with 10.5 all my problems went away. Thanks for your help I appreciate it. On Mon, Nov 9, 2009 at 8:40 AM, Jan Otto as...@me.com wrote: hi bob, Undefined symbols: _fopen$UNIX2003, referenced from: _parseServiceInfo in libpq.i386(fe-connect.o) _PasswordFromFile in libpq.i386(fe-connect.o) ld: symbol(s) not found collect2: ld returned 1 exit status Any help would be greatly appreciated. hm, fopen is a standard c (libSystem) function. make shure you have linked your library (libpq) against the same versions of standard libraries as you try with your iphone-app. check your linker options, specially -isysroot. you can check later to which libSystem your lib or app was built with: otool -L LibOrApp regards, jan otto -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Getting iPhone Simulator App to compile with libpq on Snow Leopard
In my quest to create a simple PostgreSQL program that runs on the
iPhone I have ran into some problems.
The first issue I had with my build was libpq being compiled for
architecture of type x86_64 by default on Snow Leopard and the
Simulator being i386 so my build would fail telling me libpq was the
wrong architecture type. I was able to get around this issue as found
here -
http://stackoverflow.com/questions/1678381/connect-iphone-app-to-postgresql-using-libpq.
Now I'm getting a new Undefined symbols issue.
Here is the code that is attempting to connect to PostgreSQL
//
// iPhonePgAppDelegate.m
// iPhonePg
//
// Created by bob on 11/4/09.
// Copyright __MyCompanyName__ 2009. All rights reserved.
//
#import iPhonePgAppDelegate.h
#import iPhonePgViewController.h
#include libpq-fe.h
@implementation iPhonePgAppDelegate
@synthesize window;
@synthesize viewController;
- (void)applicationDidFinishLaunching:(UIApplication *)application {
const char *conninfo;
PGconn *conn;
PGresult *res;
conninfo = host = 192.168.1.5 dbname = dev user=postgres password=z;
/* Make a connection to the database */
conn = PQconnectdb(conninfo);
res = PQexec(conn, INSERT INTO public.junk(junk_data) VALUES('HELLO'););
if (PQstatus(conn) != CONNECTION_OK)
{
fprintf(stderr, Connection to database failed: %s,
PQerrorMessage(conn));
}
PQclear(res);
PQfinish(conn);
[window addSubview:viewController.view];
[window makeKeyAndVisible];
}
- (void)dealloc {
[viewController release];
[window release];
[super dealloc];
}
Here is the output from my build attempt that is showing an error.
Keep in mind I have the equivalent Mac version of this app connecting
to PostgreSQL just fine. The only real difference is the project type
of the apps, Mac app vs iPhone app. So I feel pretty good about me not
doing something that is obviously wrong. I'm on Snow Leopard with
Xcode 3.2 using libpq compiled for i386 from PostgreSQL 8.4.1 source.
Ld build/Debug-iphonesimulator/iPhonePg.app/iPhonePg normal i386
cd /Users/bob/Documents/Programming/PragProgrammerIphoneSDK/iPhonePg
setenv MACOSX_DEPLOYMENT_TARGET 10.5
setenv PATH
/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin
/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc-4.2
-arch i386 -isysroot
/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.0.sdk
-L/Users/bob/Documents/Programming/PragProgrammerIphoneSDK/iPhonePg/build/Debug-iphonesimulator
-L../../../../mylibs
-L/Users/bob/Documents/Programming/PragProgrammerIphoneSDK/iPhonePg
-L/Users/bob/Documents/Programming/PragProgrammerIphoneSDK/iPhonePg/../../../../mylibs
-F/Users/bob/Documents/Programming/PragProgrammerIphoneSDK/iPhonePg/build/Debug-iphonesimulator
-filelist
/Users/bob/Documents/Programming/PragProgrammerIphoneSDK/iPhonePg/build/iPhonePg.build/Debug-iphonesimulator/iPhonePg.build/Objects-normal/i386/iPhonePg.LinkFileList
-mmacosx-version-min=10.5 -framework Foundation -framework UIKit
-framework CoreGraphics
/Users/bob/Documents/Programming/PragProgrammerIphoneSDK/iPhonePg/../../../../mylibs/libpq.i386
-o
/Users/bob/Documents/Programming/PragProgrammerIphoneSDK/iPhonePg/build/Debug-iphonesimulator/iPhonePg.app/iPhonePg
Undefined symbols:
_fopen$UNIX2003, referenced from:
_parseServiceInfo in libpq.i386(fe-connect.o)
_PasswordFromFile in libpq.i386(fe-connect.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
Any help would be greatly appreciated.
Thanks
Bob
--
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] Transactions within a function body
Have you looked at creating a function in perl and creating a new connection? Or using a dblink query which can create a new connection? These two methods work. I have used them to insert to a log table regardless of the parent transaction being commited or rolled back. A old example I posted of using pl/perl can be found here - http://www.postgresqlforums.com/forums/viewtopic.php?f=4t=647 The key is opening a new session which using dblink or pl/perl dbi connection will do. This is not ideal as it would be nice if you could just do autonomous transactions, but I find this method works for the cases where you need it. Bob Hi all. Is there a way to have (sub)transactions within a function body? I'd like to execute some code (a transaction!) inside a function and later decide whether that transaction is to be committed or not. Thanks.
Re: [GENERAL] Transactions within a function body
Have you looked at creating a function in perl and creating a new connection? Or using a dblink query which can create a new connection? These two methods work. I have used them to insert to a log table regardless of the parent transaction being commited or rolled back. A old example I posted of using pl/perl can be found here - http://www.postgresqlforums.com/forums/viewtopic.php?f=4t=647 The key is opening a new session which using dblink or pl/perl dbi connection will do. This is not ideal or efficient. It would be nice if you could just do autonomous transactions natively in pl/pgsql, but I find this method works for the cases where you need it(logging, huge batch processing tasks where it's not ideal to process everything in one transaction). Bob Hi all. Is there a way to have (sub)transactions within a function body? I'd like to execute some code (a transaction!) inside a function and later decide whether that transaction is to be committed or not. Thanks. On Thu, Oct 2, 2008 at 10:40 AM, Alvaro Herrera [EMAIL PROTECTED]wrote: Gurjeet Singh escribió: I have seen this feature being asked for, and this work-around suggested so many times. If plpgql does it internally, why not provide a clean interface for this? Is there some road-block, or that nobody has ever tried it? Initially we aimed at just exposing SAVEPOINT and ROLLBACK TO in functions, but ran into the problem that the SPI stack needs to be dealt with appropriately and you can't do it if the user is able to modify it arbitrarily by calling transaction-modifying commands. That's when the EXCEPTION idea came up. We never went back and studied whether we could have fixed the SPI limitation, but it's not trivial. -- Alvaro Herrera http://www.CommandPrompt.com/ http://www.commandprompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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] Transactions within a function body
Coming from an Oracle background my understanding is they're one in the same. On Thu, Oct 2, 2008 at 10:37 AM, Alvaro Herrera [EMAIL PROTECTED]wrote: Bob Henkel escribió: Have you looked at creating a function in perl and creating a new connection? Or using a dblink query which can create a new connection? These two methods work. I have used them to insert to a log table regardless of the parent transaction being commited or rolled back. That's a different thing, autonomous transactions. -- Alvaro Herrera http://www.CommandPrompt.com/ http://www.commandprompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Re: [GENERAL] Please help to speed up UPDATE statement
On Apr 12, 2005 9:40 AM, Andrus [EMAIL PROTECTED] wrote: The following statement runs VERY slowly on large tables.Any idea how to speed it up ?UPDATE rid SET dokumnr=NULL WHEREdokumnr NOT IN (SELECT dokumnr FROM dok);Tables:CREATE TABLE dok ( dokumnr INTEGER, CONSTRAINT dok_pkey PRIMARY KEY (dokumnr) );CREATE TABLE rid ( dokumnr INTEGER);CREATE INDEX rid_dokumnr_idx ON rid (dokumnr);Andrus---(end of broadcast)---TIP 5: Have you checked our extensive FAQ?http://www.postgresql.org/docs/faqPlease send your explain plan everyone will want to see it to tell what is going on.
Re: [GENERAL] Table inheritance or LIKE table?
On Apr 9, 2005 10:55 PM, Steve - DND [EMAIL PROTECTED] wrote:What is the general consensus on using table inheritance? I know it's there,but is it good, bad, or just dependent on how it's used? I need to trackcreation/update information for a large number of tables in my current DB. Iwas just going to create a table with the template of fields I was lookingfor, and use LIKE in the table definition. It turns out that LIKE does notmaintain FK constraints, or indexes.Would this be a good situation to use inheritance? Since the data inquestion is identical for all of the tables it will be used on, it seemslike it might be the right path. Are there any performance issues with tableinheritance?Below is the DDL for the table in question.CREATE TABLE create_update_info ( created_by_user_id integer NOT NULL, created_on timestamp DEFAULT timezone('UTC', now()) NOT NULL, updated_by_user_id integer NOT NULL, updated_on timestamp DEFAULT timezone('UTC', now()) NOT NULL, FOREIGN KEY (created_by_user_id) REFERENCES users(user_id), FOREIGN KEY (updated_by_user_id) REFERENCES users(user_id))Thanks,Steve---(end of broadcast)---TIP 6: Have you searched our list archives? http://archives.postgresql.org
This doesn't answer your question, but why use inheritance?
What advantage will it give you? And what if in the future you do need
the FK constraints? By using inheritance as it's currently
implemented you will only be locking your self into a design. Just my 2
cents
Re: [GENERAL] Postgresql system requirements to support large
I just want a general idea of what Postgresql can handle. I know the guru's will say it depends on many different things, but in general what can this bad boy handle? 50gb to 100gb is by no means small. But how does Postgresql 7.4 handle database of 900G, or 1 Terabyte or greater? How does Postgresql handle a table with100 columns of integers and varchar2(400) data types with 1 million rows,10 million, 100 million 500 million,greater then 1 billion joined to a small lookup table of 5 rows with both tables indexed properely? Can this database handle enterprise quanities of data or is it geared towards the small to medium data? |-+-- | | [EMAIL PROTECTED] | | | (wilbur douma) | | | Sent by: | | | [EMAIL PROTECTED]| | | tgresql.org| | | | | | | | | 04/15/2004 03:14 PM| | | | |-+-- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: [GENERAL] Postgresql system requirements to support large databases. | | We are looking at implementing a large Postgresql database (50GB - 100GB) and are wondering if there are any limitations or problems for a database of this size running on 32-bit architecture. I have seen some older posts where it appears that Postgresql seemed to have performance problems when the database reached 5GB, and it was recommended that 64-bit architecture be used. Is this still true with Postgresql version 7.4? This will be out first experience with Postgresql and we are needing to get some ideas of what system requirements a database of this size will require. Since the machines that we have are all 32-bit, we would like to know if we will need to go to 64-bit. Any comments or suggestions?? Thanks in advance for any help. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org * PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Can we have time based triggers in Postgresql??
My thoughts in a perfect world for having oracle style jobs in postgresql would be a very loud yes. In the world called reality I say why waste precious time on something that can already be accomplished by other means. This feature at this time would just be icing on an already tasty cake. This is not putting down anyone's ideas on getting these this is just my personal thought at this point in time. If it would be easy for the c guru's to do ,great put it in there. But if it will pull away from more critical areas why do it. |-+-- | | Guy Rouillier| | | [EMAIL PROTECTED] | | | Sent by: | | | [EMAIL PROTECTED]| | | tgresql.org| | | | | | | | | 04/07/2004 05:00 PM| | | | |-+-- --| | | | To: PostgreSQL General [EMAIL PROTECTED] | | cc: | | Subject: Re: [GENERAL] Can we have time based triggers in Postgresql?? | --| Andrew Sullivan wrote: On Tue, Mar 30, 2004 at 12:16:50PM -0500, Steve Manes wrote: I think he probably means like an Oracle job. Although cron works, that would be handy so you wouldn't need to write wrapper scripts just to run a proc. I hate to sound like an oldbie crank (although I'll admit to being a crank), but what exactly is the advantage supposed to be here? One invents a new special bit of database code which exists just so people don't have to write shell scripts? I guess the idea gets under my skin just because I have enough time-based problems without inventing a new interface to make it more complicated. Hmm. Looks like the sigmonster has gacked up a piece of wisdom. A As one who was about to ask the same question, I can provide one reason: ease of use/administration. I can create everything I need to manage/process my database *in* my database, rather than in numerous shell scripts scattered about. I had a weird issue with cron recently. I needed to do some db maintenance and wanted to make sure no one was going to change it, so I removed all cron jobs (crontab -r). Halfway through, suddenly the database started getting updated!! I finally figured out that my predecessors, for some reason, had stuck a couple cron jobs in the root crontab, which I corrected. And of course, if I copy a database someplace, the jobs would go with it; not so cron jobs. Now having said this, I realize that even if a scheduler was added to PostgreSQL, there is nothing to stop someone from additionally using cron jobs anyway. But there would be less temptation to do so. -- Guy Rouillier ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html * PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ---(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] Can we have time based triggers in Postgresql??
Just my experience, but we when I have used Oracle as my database. My processes that run in batch use shell scripts to kick of stored procedures even though Oracle does provide jobs. Shell scripts can be much more flexible in many cases. You can have dependancies on all kinds of things (time, a file arriving, after system backups are done, etc). Granted you could in spend time doing this from yoru favorite stored procedure langauge but why make things more complex then they need be. Not that jobs built into the database are of no value, but shell scripts seem to do everything you need and when there are other things to put into posgtresql I wouldn't vote to waste time on jobs. |-+-- | | Andrew Sullivan| | | [EMAIL PROTECTED] | | | Sent by: | | | [EMAIL PROTECTED]| | | tgresql.org| | | | | | | | | 04/06/2004 10:59 PM| | | | |-+-- --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: [GENERAL] Can we have time based triggers in Postgresql?? | --| On Tue, Mar 30, 2004 at 12:16:50PM -0500, Steve Manes wrote: I think he probably means like an Oracle job. Although cron works, that would be handy so you wouldn't need to write wrapper scripts just to run a proc. I hate to sound like an oldbie crank (although I'll admit to being a crank), but what exactly is the advantage supposed to be here? One invents a new special bit of database code which exists just so people don't have to write shell scripts? I guess the idea gets under my skin just because I have enough time-based problems without inventing a new interface to make it more complicated. Hmm. Looks like the sigmonster has gacked up a piece of wisdom. A -- Andrew Sullivan | [EMAIL PROTECTED] This work was visionary and imaginative, and goes to show that visionary and imaginative work need not end up well. --Dennis Ritchie ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html * PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] Storing jpgs
I won't say what is right or wrong to do. But some will say to store the file location in a field such as /mydocs/mypictures/myimage.jpg and then have your php or what ever open that file. by using a select statement. Not sure how you would store them in the database and pull it righ out. I would prefer your method for many reasons. For one backing up the database also backups up all your image files. Good luck. |-+-- | | C G | | | [EMAIL PROTECTED] | | | Sent by: | | | [EMAIL PROTECTED]| | | tgresql.org| | | | | | | | | 04/05/2004 11:20 AM| | | | |-+-- --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: [GENERAL] Storing jpgs | --| Dear All, What's the best way to store jpgs in postgresql to use in a web page? I tried to use large objects, but how would you extract them from a table to be viewed in a web-page without having to write them to a scratch file somewhere first? Thanks Colin _ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) * PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] select distinct w/order by
Not that this is the issue, but what kind of tool where you using to get your results back with this other database? Sometimes these fancy GUI tools like to be smart on you and order things based on something it feels is correct giving you the impression that the database choose the order when infact the GUI tool choose the order. Just a thought Bob Henkel 651-738-5085 Mutual Funds I/T Woodbury Hartford Life 500 Bielenberg Drive Woodbury, MN 55125 |-+-- | | Richard Huxton | | | [EMAIL PROTECTED] | | | Sent by: | | | [EMAIL PROTECTED]| | | tgresql.org| | | | | | | | | 03/31/2004 02:37 PM| | | | |-+-- --| | | | To: John Liu [EMAIL PROTECTED], [EMAIL PROTECTED] | | cc: | | Subject: Re: [GENERAL] select distinct w/order by | --| On Wednesday 31 March 2004 18:50, John Liu wrote: I know this is an old topic, but it's not easy to find a way around it, so when we migrate SQL from other database to PostgreSQL, it causes a huge headache. Here's an extremely simple example - The original simple SQL - select distinct atcode from TMP order by torder; Can you explain what this means? If I have atcode | torder AAA| 20 BBB| 5 CCC| 10 BBB| 45 CCC| 27 What order should we get? You could argue for: 1. BBB,CCC,AAA since that is the order of the min(torder) 2. AAA,CCC,BBB since that is the order of the max(torder) 3. AAA,BBB,CCC if you take the first(torder) you find reading down the page 4. AAA,CCC,BBB if you take the first(torder) but read up the page Which one should PG pick, and how should it know? Which one did the other database pick, and why was it right to do so? -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) * PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] what we need to use postgresql in the enterprise
First I would be happy to help get these things in postgresql. I'm not a c/c++ programming guru and would have to learn a bit before I could do the coding. I would be happy to test or talk about what's needed or anything like that. Or just keep the fire burning on these issues that I think are keeping postgresql from being the database to use for almost everything. I mean it's great when other things get optimized and fixed, but to me the issues I talk about are show stoppers(atleast in my eyes). I releize that Oracle software costs easily 500K for a large shop. And Postgresql is 0$. But if we don't look at what is missing how will things ever improve. I have the view point of using Oracle for over 7 years and Postgresql for about a year off and on for learning puproses. I love Postgresql and hope my viewpoint coming from Oracle can help improve things. My point of this thread is to say why we can't use Postgresql in place of Oracle at this time because of xy and z. Maybe in years to come we can. I would rather use Postgresql if I can. If some of these things are coming that's great. From my point of view they aren't there, therefore I can't use them. I also think pl/pgsql is a better choice for stored procedures in general depending on the goal of the procedure. If the procedure is working with the database pl/pgsql seems to be the choice. I would rather use pl/pgsql and not have some perl and some python or some other language in my stored procedures. This may be more my opinion then the best way of doing things. But I like to keep things simple for any future person going to maintain the system. I can see where you are coming from if you haven't used Oracle's exception handling. Here is a snippet of an exception handling block in one of my stored procedures. As you can see I don't need to check for errors after each piece of code. The exception block handles all exception handling. I would say it's very clean and handles errors very well. this is a simple example but you can get the point. BEGIN code logic here code logic here code logic here code logic here code logic here EXCEPTION /* Not all of the non nullable fields passed had values */ WHEN e_mandatory_fields_null THEN r_return_cd := pkg_0100.g_return_missing_fields; pkg_0100.sp_get_error(r_return_cd,r_return_type,r_return_msg); /* Default error code called for all other errors */ WHEN others THEN pkg_0099.g_sql_code := SQLCODE; pkg_0099.g_sql_error_msg := SQLERRM; r_return_cd := pkg_0001.g_return_failure; pkg_0001.sp_log_error(r_return_cd,r_return_type,r_return_msg); END; I can see how you might get use to something like my example below, but to be honest once you have used Oracle style exception handling it's very hard to look at anything with a grain of salt. Just look how ugly this is compared to my Oracle exception block. Now imagine a stored procedure with 2500+ lines of code. For short very simple 50 lines or less I could live with postgresql exception handling on some levels. But once the lines start adding up it's not a good way of doing things. postgresql error checking if I understand correctly. code logic here check for error code logic here check for error code logic here check for error code logic here check for error Bob Henkel 651-738-5085 Mutual Funds I/T Woodbury Hartford Life 500 Bielenberg Drive Woodbury, MN 55125 Chris Travers [EMAIL PROTECTED]To: Robert Treat [EMAIL PROTECTED], [EMAIL PROTECTED] icas.comcc: [EMAIL PROTECTED] Subject: Re: [GENERAL] what we need to use postgresql in the enterprise 01/13/2004 02:30 AM I am a little confused here. I agree that there are points mentioned here that need work, but correct me if I am wrong On Friday 09 January 2004 14:48, [EMAIL PROTECTED] wrote: snip 1. Need commit roll back in pl/pgsql much like Oracle does 2. Need
Re: [GENERAL] what we need to use postgresql in the enterprise
I couldn't agree with you more. I'm just a developer in a very large company and getting anyone to listen and then understand that logic would be a nightmare to say the least. If it was my company I would put money toward those issues. Robert Treat [EMAIL PROTECTED]To: [EMAIL PROTECTED], [EMAIL PROTECTED] eforge.netcc: Subject: Re: [GENERAL] what we need to use postgresql in the enterprise 01/12/2004 12:45 AM I think your pretty much on target with the below. It is possible to work around these issues on some level, but I can see how that might get unwieldly in a hurry. While I won't tell you to go code it if you need it, I might ask that you consider what your paying in Oracle licenses and think about spending that money to hire someone to develop those features in PostgreSQL, I'm thinking you'd save money in the long run. Robert Treat On Friday 09 January 2004 14:48, [EMAIL PROTECTED] wrote: I write this to tell you why we won't use postgresql even though we wish we could at a large company. Don't get me wrong I love postgresql in many ways and for many reasons , but fact is fact. If you need more detail I can be glad to prove all my points. Our goal is to make logical systems. We don't want php,perl, or c++ making all the procedure calls and having the host language to be checking for errors and handleing all the transactions commits and rollbacks. That is not very logical in a large batch system. Also please don't tell me to code the changes myself. I'm not at that part of the food chain. That is to low level for me and I don't have the time to put that hat on. I build the applications that use the database systems. Also please feel free to correct me in any area I don't know everything I'm just stating my opinion here 1. Need commit roll back in pl/pgsql much like Oracle does 2. Need exception handling in pl/pgsql must like Oracle does 3. ANeed sub transactions . BAnd if an inner transactions fails it should not cause all others to fail. If #2 was robust enough than #3 B might not be an issue. With those two things I could accomplish pretty much everything with postgresql that we're currently doing in Oracle. 1. It's a must if you have long running complicated and time consuming batch processing. There is no reason why one should say do all of commit and rollbacks from the client. Our current batch system gets fired off by running some sql scripts that start an entry point into the batch system. Once the first stored procedure is called it will call all the rest. This encapsulates all logic and processing in the database where it belongs. There is no client traffic because once that first script kicks off there is no outside process running , just our pl/sql. Now I'm not a postgresql expert at all but when I read up on it looks like this is something you can't accomplish and I see no word of this being worked on. 2. Without this you can't trust complicated code as far as I'm concerned. I need to log some errors and continue processing and for others log and exit which I think you can do now in pl/pgsql. Point being pl/pgsql exception handling is almost nonexistent at best. 3. We use this all the time in pl/sql and we need to. To write this off as not need is wrong and will not get postgresql to where it can be(AT THE TOP). * PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. *
