Re: [HACKERS] Catalogs design question
I also quote the PotgreSQL user manual (http://www.ca.postgresql.org/users-lounge/docs/7.1/postgres/arrays.html): In the contrib/ directory are procedures to search arrays for values. This may help. Thanks for the tip, but in fact I've seen them (and they're listed on the same document I pointed on the original message). These are sequential (slow) searches, and can't be indexed. in resume: nothing but another crude hack :). I could even use it, but I can';t tell my users oh this feature works but you must compile this contrib code inyo your servers. Many users can't do it, and many don't even know how to do it :( Best Regards, Steve Howe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Catalogs design question
Hello Bruce! Yes, we inherited these arrays from Berkeley and haven't had any need to remove them. Are you trying to do things that the other interfaces like ODBC and JDBC don't handle? About the groups: I just want to write a function that will return the users names belonged by a given group. I understand I can load the arrays in memory, then sequentially compare the members from pg_shadow, but doing it goes against the database priciple after all. About the procs: the Borland's dbExpress specification demands a input/output list of parameters for stored procedures, and I'm going to use functions as stored procedures. But I need to make a types list to be able list what are those params. The group array is a hack but the pg_proc array would be hard to replace becauseit acts as part of the unique key used for cache lookups. This design itself bothers me. We have no other option left ? Like arrays being referenced in relations ? That's far from perfect, but at least would solve those issues and others which might appear in other catalogs... Best Regards, Steve Howe ---(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: [HACKERS] Catalogs design question
Hi, I think Bruce meant contrib/intarray which provides incredibly fast indexed access to arrays of integers, which is your case. We use it a lot, particularly in our full text search engine (OpenFTS). regards, Oleg On Sat, 20 Oct 2001, Steve Howe wrote: I also quote the PotgreSQL user manual (http://www.ca.postgresql.org/users-lounge/docs/7.1/postgres/arrays.html): In the contrib/ directory are procedures to search arrays for values. This may help. Thanks for the tip, but in fact I've seen them (and they're listed on the same document I pointed on the original message). These are sequential (slow) searches, and can't be indexed. in resume: nothing but another crude hack :). I could even use it, but I can';t tell my users oh this feature works but you must compile this contrib code inyo your servers. Many users can't do it, and many don't even know how to do it :( Best Regards, Steve Howe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Compiling on Solaris with Sun compiler
Lee Kindness writes: Touche, but the man page for the front-end (plain old cc) doesn't list options and only refers to the acc man page ;) Well, I'm stumped. All the Solaris compilers I've ever seen did support and document the -Wl option. After a simple './configure' on a stock Solaris 2.6 box the compilation of interfaces/ecpg/lib/execute.c fails due to the macro definition of 'gettext' to ''. This macro is invoked on the prototype of gettext() in libintl.h (included via locale.h). Fail how and why? -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Package support for Postgres
Bill Studenmund writes: create function produce(text) returns text as ' GD[key] = args[0] ' language plpython; create function consume() returns text as ' return GD[key] ' language plpython; There is also a dictionary for private data. Private to what? Private to the procedure, but saved across calls (during one session). Oh, by shared memory, do you mean SYSV Shared Memory (like how the backends talk) or just memory shared between routines? I ask as part of the idea with these variables is that they are backend-specific. So C routines actually should NOT used SYSV Shared Mem. :-) Yes, you're right. Actually, sharing data across PostgreSQL C functions is trivial because you can just use global variables in your dlopen modules. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Package support for Postgres
I think Jean-Michael's comments were right. While I'm not sure if things will be as overwhelming as he predicted, packages (even as implimented in my patch) will help people develop code libraries for PostgreSQL. And that will make PostgreSQL applications easier. PostgreSQL is a fantastic tool which lacks a few features to become #1. IMHO, these features are : Beginners: ability to drop and reorganize columns. I know this sounds stupid for hackers, but this is #1 need when migrating from beginner tools such as MySQL or Access. Candidates? Advanced users: PACKAGE support to create and distribute software libraries. CREATE OR REPLACE VIEW, CREATE OR REPLACE TRIGGER, etc... PL/pgSQL installation by default with infinite loop protection. Professionnal user: PostgreSQL does not lack many things. Maybe server-side Java would be great in terms of object/inheritence approach. I run several databases, one being hosted on a double Pentium Linux box with U2W discs. When using triggers, views, rules and PL/pgSQL, applications can be optimized so much that you hardly reach the hardware limits. Power users: load balancing, replication, tablespace. I can't really say. I first discovered PostgreSQL when localizing Oracle8i to French. We asked Oracle if I could use their software to help us during the translation process. They answered OK, but you have to pay $xx.xxx because you have a double processor box. This was about twice the price we were getting paid. That day, I understood Oracle did not care about its users and was only interested in fast, short term profit. Cheers, Jean-Michel ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Unable to upgrade to 7.2
Chris Bitmead [EMAIL PROTECTED] writes: When I try and load the data into 7.2 it gives a bunch of errors like \N command not found You're going to have to be more specific if you want help fixing it... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Error while restoring database
Johann Zuschlag [EMAIL PROTECTED] writes: Here is an excerpt of the original dump-file. That's what you showed us already. What I'd like to see is the original database contents, particularly select * from pg_operator where oid = 280343; select * from pg_operator where oid = 280344; so we can see why pg_dump is producing the bogus output. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] namespaces
- Original Message - From: Bill Studenmund [EMAIL PROTECTED] Sent: Sunday, October 14, 2001 8:22 AM My description of namespaces seems to have caused a fair bit of confusion. Let me try again. The ability of the package changes to automatically check standard when you give an ambiguous function name while in a package context is a convenience for the procedure author. Nothing more. It means that when you want to use one of the built in functions (date_part, abs, floor, sqrt etc.) you don't have to prefix it with standard.. You can just say date_part(), abs(), floor(), sqrt(), etc. The only time you need to prefix a call with standard. is if you want to exclude any so-named routines in your own package. Quick question: would it be possible then create a 'system' package and 'system' (or 'master' if you will) schema (when it's implemented), move over all the system tables (pg_*) into the master schema and functions into the 'system' package, so that no name conflicts will arise when creating types, functions, tables, etc with the same names as system ones? -- S. ---(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: [HACKERS] Package support for Postgres
On Sat, 20 Oct 2001, Peter Eisentraut wrote: Yes, you're right. Actually, sharing data across PostgreSQL C functions is trivial because you can just use global variables in your dlopen modules. Exactly. That's why I never envisioned C or internal functions using package global variables. :-) Take care, Bill ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] namespaces
On Sat, 20 Oct 2001, Serguei Mokhov wrote: It means that when you want to use one of the built in functions (date_part, abs, floor, sqrt etc.) you don't have to prefix it with standard.. You can just say date_part(), abs(), floor(), sqrt(), etc. The only time you need to prefix a call with standard. is if you want to exclude any so-named routines in your own package. Quick question: would it be possible then create a 'system' package and 'system' (or 'master' if you will) schema (when it's implemented), move over all the system tables (pg_*) into the master schema and functions into the 'system' package, so that no name conflicts will arise when creating types, functions, tables, etc with the same names as system ones? Yes. That is part of my plan actually. :-) In the patch I sent in last week, all of the built-in functions and aggregates are in the standard package, and you can infact reference them as standard.foo. Moving types, operators, and relations (and whatever else should go there) into master was part of my plan for schemas. Take care, Bill ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Unable to upgrade to 7.2
I just checked out postgresql from CVS, built it and did a pg_dumpall of my 7.1.3 databases. When I try and load the data into 7.2 it gives a bunch of errors like \N command not found I guess they are nulls and it can't recognise them or something. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_sorttemp files
Thus spake Tom Lane [EMAIL PROTECTED] (D'Arcy J.M. Cain) writes: BTW, if you are seeing unreclaimed sorttemp files in a recent release (7.0 or later), I'd like to know about it. That shouldn't happen, short of a backend crash anyway... Well, I had over 6,000 of these files. This database is about a year old. I haven't seen all that many backend crashes in that time. I guess I better keep a close eye on them. Wow! Did you happen to note how many distinct PIDs were accounted for? That would give us some idea of how many lossage events there were. I think there were about 25 or so. Perhaps these files could be cleaned up on startup. The will be cleaned up on postmaster startup in 7.2. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_sorttemp files
Thus spake Tom Lane
[EMAIL PROTECTED] (D'Arcy J.M. Cain) writes:
BTW, if you are seeing unreclaimed sorttemp files in a recent release
(7.0 or later), I'd like to know about it. That shouldn't happen,
short of a backend crash anyway...
Well, I had over 6,000 of these files. This database is about a year old.
I haven't seen all that many backend crashes in that time. I guess I better
keep a close eye on them.
Wow! Did you happen to note how many distinct PIDs were accounted for?
That would give us some idea of how many lossage events there were.
I think there were about 25 or so.
Perhaps these files could be cleaned up on startup.
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Detecting glibc getopt?
Peter Eisentraut [EMAIL PROTECTED] writes: How about copying the entire argv[] array to a new location before the very first call to getopt(). Then you can use getopt() without hackery and can do anything you want to the real argv area. That should be a lot safer. (We don't know yet what other platforms might play optimization tricks in getopt().) Well, mumble --- strictly speaking, there is *NO* way to use getopt over multiple cycles without hackery. The standard for getopt (http://www.opengroup.org/onlinepubs/7908799/xsh/getopt.html) doesn't say you're allowed to scribble on optind in the first place. But you're probably right that having a read-only copy of the argv vector will make things safer. Will do it that way. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Catalogs design question
Steve Howe writes: The group array is a hack but the pg_proc array would be hard to replace becauseit acts as part of the unique key used for cache lookups. This design itself bothers me. We have no other option left ? Like arrays being referenced in relations ? That's far from perfect, but at least would solve those issues and others which might appear in other catalogs... In general, the system catalogs are far from a perfect example (or even an example at all) for pure, normalized relational database design. A more important concern in processing efficiency. For instance, currently the execution of a procedure takes one catalog lookup versus (1 + nargs) in a more normalized design. (This is an oversimplification, but you get the idea.) -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Detecting glibc getopt?
Tom Lane writes: The reason we see this now, and didn't see it before, is that I rearranged startup to set the ps process title as soon as possible after forking a subprocess --- and at least on Linux machines, that nextchar pointer is pointing into the argv array that's overwritten by init_ps_display. How about copying the entire argv[] array to a new location before the very first call to getopt(). Then you can use getopt() without hackery and can do anything you want to the real argv area. That should be a lot safer. (We don't know yet what other platforms might play optimization tricks in getopt().) -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Packages are needed
No argument here. But the proposed Oracle packages are something completely different and don't solve any of the problems you list. Hello, I agree packages are not designed primarily for library installation. I also agree packages might need dependency checking. But packages can be dumped easily and have initialization functions. Therefore, IMHO, why not use them as library installers? At the moment, there is only one PostgreSQL set of libraries available: OpenACS. On a marvelous development tool like PostgreSQL, there should be many more. Remember, MS Windows succeeded because of MS Office. What is PostgreSQL without a strong set of software libraries and applications? PostgreSQL is mostly designed by AND for hackers. This is cultural reality which I do not blame. I remember users posting features requests about ALTER TABLES DROP COLUMN. Some answers we like OK, this can be done, but what for?. Same as for packages as far as I can read the latest posts. Cheers, Jean-Michel ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Catalogs design question
Steve Howe [EMAIL PROTECTED] writes: The group array is a hack but the pg_proc array would be hard to replace becauseit acts as part of the unique key used for cache lookups. This design itself bothers me. We have no other option left ? Like arrays being referenced in relations ? Sure, it *could* be done another way. As far as pg_proc goes, I agree with Bruce: there are far too many places that know the existing representation for us to consider changing it. The pain involved would vastly outweigh any possible benefit. The representation of groups is not so widely known, however. We could probably get away with changing it, if someone wanted to propose a better catalog schema and do the legwork to make it happen. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Package support for Postgres
But what if you want a C function to set a variable which can be accessed using an SQL, perl, PLpgSQL or other function type? Shouldn't a global variable be global between all types of functions? -- Rod Taylor There are always four sides to every story: your side, their side, the truth, and what really happened. - Original Message - From: Bill Studenmund [EMAIL PROTECTED] To: Peter Eisentraut [EMAIL PROTECTED] Cc: PostgreSQL Development [EMAIL PROTECTED] Sent: Friday, October 19, 2001 1:59 PM Subject: Re: [HACKERS] Package support for Postgres On Sat, 20 Oct 2001, Peter Eisentraut wrote: Yes, you're right. Actually, sharing data across PostgreSQL C functions is trivial because you can just use global variables in your dlopen modules. Exactly. That's why I never envisioned C or internal functions using package global variables. :-) Take care, Bill ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
