[HACKERS] v3 protocol & string encoding
Couple of quick protocol questions: 1) What encoding is used for strings sent and received during the startup phase? I can set client_encoding to a known value as a parameter in the startup packet, but the protocol spec doesn't appear to say how the startup packet itself and the various strings sent/received during startup (e.g. authentication, error messages) are encoded. 2) At what point in the stream does a client_encoding change take effect -- immediately after the corresponding ParameterStatus message, or at some other point? -O ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Extended customizing, SQL functions,
> > [EMAIL PROTECTED] writes: > >> I agree completely with one caveat, when the best tool for the job lacks >> a >> feature what do you do? > > You're missing the point. The feature you want has nothing to do with > relational databases. It has everything to do with in-memory > non-transactional > non-relational databases. These things exist but they're not postgres. > > Postgres just isn't the best tool for what you want to do. > > Try memcached or any of the other very fast non-persistent > non-transactional > in-memory databases. If you try to use postgres to do this you'll find -- > as > you just did -- that you've bought a lot of overhead for things you don't > want. Because it's not the appropriate tool. That's the problem. It easy to say, in effect, this isn't the job of the database. Yet, the information is based on what's in the database. It is one of those ambiguous things that life is so anoyingly full of. It's really data related, so it should be in the database, it's really the application's place to do this, so it should be in the application. When all is said and done, I would say it is "too" data related to be so separated from the database. Remember, PostgreSQL was chosen for the vast number of advantages, this is just one small issues. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Changing view column types
Is there any possibility for changing view column types now in 7.5? Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Ingres to be released as open source
Em Tue, 25 May 2004 10:54:48 +0800, Christopher Kings-Lynne escreveu: > Can we grab features from their codebase? No, and that's what's nice about copyleft. It forbids code hoarding. OTOH, it would be interesting to see some competition. Ingres could encroach in some current or prospective PostgreSQL users, and perhaps force us to get back the *relational* QUEL. That could prepare us better for a relational future, now that there is a proprietary RDBMS (Alphora Dataphor, even if using SQL under covers) and at least one in development (by Alfredo Novoa). -- Leandro Guimarães Faria Corsetti Dutra +55 (11) 5685 2219 Av Sgto Geraldo Santana, 1100 6/71 +55 (11) 5686 9607 04.674-000 São Paulo, SPBRASIL http://br.geocities.com./lgcdutra/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Big problem
On Mon, 2004-05-24 at 16:03, Christopher Kings-Lynne wrote: > > Isn't it just enough to prevent the user with userid 1 from losing the > > superuser status. If one want to allow it one could prevent it just when > > doing the ALTER USER stuff and allow it when editing pg_shadow directly. > > Or maybe have some guc variable that write locks the user with id 1. > > That gets my vote - can't take superuser off id 1... Gets my vote too, postgres user can't take superuser off. > > > Given that it was so "simple" to restore I'm not sure if it's worth it or > > not, but restricting just user 1 does not give any of the problems you > > wrote about. > > Well, sergio sure wasn't very happy... yes I wasn't but "Stop postmaster and start a standalone backend. Now you are asuperuser, and you can create a new superuser, or just go in and UPDATE pg_shadow to make your original user super again. Exit standalone backend, restart postmaster, have a beer." worked ! thanks , > > And if I ever get around to my patch that separates out superuser and > catalog modification privileges, superusers will no longer necessarily > be able to 'delete from pg_proc'; > > Chris -- Sérgio M. B. ---(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] dynamic_library_path on Win32
I can do it but will be a few days until I get to it. --- Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > You've found a bug. Clearly we need to adjust the parsing of > > dynamic_library_path and probably preload_libraries for Win32. > > Yup. Using PATHSEP sounded reasonable to me. Any volunteer to fix > this? (Don't forget to patch the docs for these variables, too.) > > regards, tom lane > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Geometry regression failure on OS X 10.3.4
Hello all, Just made CVS head on Mac OS X 10.3.4. On make check, I got test geometry ... FAILED This was the only test that failed. Regression diff attached. Michael Glaesemann grzm myrealbox com regression.diffs Description: Binary data ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] dynamic_library_path on Win32
Andrew Dunstan <[EMAIL PROTECTED]> writes: > You've found a bug. Clearly we need to adjust the parsing of > dynamic_library_path and probably preload_libraries for Win32. Yup. Using PATHSEP sounded reasonable to me. Any volunteer to fix this? (Don't forget to patch the docs for these variables, too.) regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Extended customizing, SQL functions,
[EMAIL PROTECTED] writes: > I agree completely with one caveat, when the best tool for the job lacks a > feature what do you do? You're missing the point. The feature you want has nothing to do with relational databases. It has everything to do with in-memory non-transactional non-relational databases. These things exist but they're not postgres. Postgres just isn't the best tool for what you want to do. Try memcached or any of the other very fast non-persistent non-transactional in-memory databases. If you try to use postgres to do this you'll find -- as you just did -- that you've bought a lot of overhead for things you don't want. Because it's not the appropriate tool. -- greg ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] dynamic_library_path on Win32
Tom Lane wrote: "Thomas Hallgren" <[EMAIL PROTECTED]> writes: I'm using CVS HEAD in a windows environment. I'm trying to start the postmaster using "postmaster -c dynamic_library_path=C:/foo/bar". It starts just fine, then, when I ask it to load a module, an error is generating stating: ERROR: component in parameter "dynamic_library_path" is not an absolute path I added a trace to find out what it thinks the path is. It prints "C". Obviously it treats ':' as a path separator somewhere. Yeah. dynamic_library_path follows the universal Unix convention that search path components are separated by ':'. Is there any equivalent convention in Windows? src/port/exec.c has this: #ifdef WIN32 #define PATHSEP ';' #else #define PATHSEP ':' #endif It should probably move to c.h. cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] dynamic_library_path on Win32
Yes, on windows, you use a semicolon as path separator. regards, - thomas - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: "Thomas Hallgren" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, May 29, 2004 17:20 Subject: Re: [HACKERS] dynamic_library_path on Win32 > "Thomas Hallgren" <[EMAIL PROTECTED]> writes: > > I'm using CVS HEAD in a windows environment. I'm trying to start the > > postmaster using "postmaster -c dynamic_library_path=C:/foo/bar". It starts > > just fine, then, when I ask it to load a module, an error is generating > > stating: > > > ERROR: component in parameter "dynamic_library_path" is not an absolute path > > > I added a trace to find out what it thinks the path is. It prints "C". > > Obviously it treats ':' as a path separator somewhere. > > Yeah. dynamic_library_path follows the universal Unix convention that > search path components are separated by ':'. Is there any equivalent > convention in Windows? > > regards, tom lane > ---(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] dynamic_library_path on Win32
>> I'm using CVS HEAD in a windows environment. I'm trying to start the >> postmaster using "postmaster -c >dynamic_library_path=C:/foo/bar". It starts >> just fine, then, when I ask it to load a module, an error is >generating >> stating: > >> ERROR: component in parameter "dynamic_library_path" is not >an absolute path > >> I added a trace to find out what it thinks the path is. It >prints "C". >> Obviously it treats ':' as a path separator somewhere. > >Yeah. dynamic_library_path follows the universal Unix convention that >search path components are separated by ':'. Is there any equivalent >convention in Windows? ';' is what's used in PATH, and several other such places. //Magnus ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Extended customizing, SQL functions,
> > [EMAIL PROTECTED] writes: > >> Having internal PostgreSQL variables that are not present on disk, or >> maybe, variables that are mirrored on disk may be good. > > I don't think there's anything wrong with your idea, and there are > numerous > good solutions that implement it already. But what makes you think this > belongs in Postgres? > > There are plenty of memory and disk based shared databases that are > non-transactional and non-relational and meant for storing just this kind > of > non-relational data. Some are much faster than postgres for simple > non-concurrent one-record lookups and updates like this. > > Use the right tool for the job. Don't try to make one tool do everything, > especially something that's anathema to its basic design. I agree completely with one caveat, when the best tool for the job lacks a feature what do you do? > > -- > greg > > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Extended customizing, SQL functions,
On Saturday 29 May 2004 20:48, [EMAIL PROTECTED] wrote: > I was thinking that it could be done as a contrib/pgfoundary function. I > think, but am not sure, that a function can be pre-loaded into the main > postgresql backend (postmaster) prior to starting other connections. I'll > have to check that out, but I think it is true, if it isn't it should be > possible to modify postmaster to do so. > > The function module, when loaded, looks for its shared memory block, if > none is found, then it procededs to create the block, mutex, etc. > > Then, it is a fairly simple task of managing a name/value table protected > by mutex. > > Make sense? This is effectively a stored procedure isn't it? I have few points on this approach * Every backend has to load it or somebody has to call it as a coding standard. Even if postmaster preloads it I doubt it will invoke it but correct me if I am wrong. * This approach puts the code that you would have put in application otherwise. I mean it makes sense but just restating for my clarification * How do you expose pg datatypes to such a system? Or keep it limited to basic variables? * How do you access it from other stored procedures and SQL commands? If you do it in C, may be C routines can use it but what about other procedural language? I think you would need SPI co-operation. All in all looks good starting point to me. But it won't be postgresql enough but a custom C function. ( That is useful as well though) Shridhar ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] dynamic_library_path on Win32
"Thomas Hallgren" <[EMAIL PROTECTED]> writes: > I'm using CVS HEAD in a windows environment. I'm trying to start the > postmaster using "postmaster -c dynamic_library_path=C:/foo/bar". It starts > just fine, then, when I ask it to load a module, an error is generating > stating: > ERROR: component in parameter "dynamic_library_path" is not an absolute path > I added a trace to find out what it thinks the path is. It prints "C". > Obviously it treats ':' as a path separator somewhere. Yeah. dynamic_library_path follows the universal Unix convention that search path components are separated by ':'. Is there any equivalent convention in Windows? 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] Nested xacts: looking for testers and review
On Fri, 28 May 2004, Alvaro Herrera wrote: > On Fri, May 28, 2004 at 05:43:41PM -0700, Stephan Szabo wrote: > > > On Wed, 26 May 2004, Alvaro Herrera wrote: > > > > > I have tested it and it passes all regression tests (including ones I > > > added), plus some more tests I threw at it mainly for concurrency. > > > Everything behaves as expected. At this time I'd like to have it > > > reviewed by the critic eye of the committers, and tested by whoever > > > would be using it. > > > > I unfortunately didn't really follow the discussions in the past (sorry :( > > ), but are the transaction state modifying statements done in a > > subtransaction supposed to live beyond subtransaction rollback? > > Hmm, I suppose not. Actually, looking at it, for set transaction, the worse one is probably isolation level because it can't be set after a query has been run and I'm not entirely sure what the behavior should look like if you did something like: begin; set transaction isolation level serializable; begin; set transaction isolation level read committed; select * from a; rollback; At that point, is the transaction in serializable method and is the snapshot set even though the select "never happened" and what does the above really mean. Is it that the results of that first transactions are out of serializability with the rest of the transaction? Also related, although START TRANSACTION (specifying isolation level or read onlyness as part) is currently defined to act as if set transaction was used, it seems really odd that the settings would leak to the outer translation even on a commit and that you can't specify isolation level - even if it's the same level - if the outer transaction has done any queries. - BTW: For the deferred trigger stuff, I am guessing you haven't touched that at all in the current patch? I wonder if the following would work assuming that we want deferred triggers to run at outer transaction end? -- There's one trigger queue list and a stack of "last event before this (sub)transaction started" pointers in and a current one similar to _imm is the one for the current subtransaction. Scanning the list takes an extra argument to say whether to consolidate the list or not (generally true except for set state). On outer transaction start, NULL is set as the last event at start pointer On subtransaction start, The current last event at start pointer is added to the stack. The last event at start pointer is set to _imm. The _imm pointer should already be in the correct place On subtransaction abort, The queue is deallocated after the last event at start pointer and the event in question its next pointer reset. (if null, the list is entirely deallocated and the list is set as null) The _imm pointer is set to the last event at start pointer. The last event at start pointer is popped from the stack. On outer transaction abort, Clear the queue. On subtransaction commit, The last event at start pointer is popped from the stack. On outer transaction commit Scan the deferred events. On set state, We call DeferredTriggerInvokeEvents with (true, false) rather than relying on the statement end to do it (as true, true). This should set the _imm pointer so that the end of statement won't scan anything anyway. -- I think it might be possible to do the queue deallocation for subtransaction abort with appropriate context work (each one gets a context under its parent's and on abort it's removed and on commit it's not until you reach the outermost?) but I haven't though about it enough. And I think the non-removing events on set transaction could be fixed as well. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Extended customizing, SQL functions,
> On Saturday 29 May 2004 18:10, [EMAIL PROTECTED] wrote: >> Having internal PostgreSQL variables that are not present on disk, or >> maybe, variables that are mirrored on disk may be good. > > Yes. I agree. I can see why you proposed no transactions few posts ago. > Take > an example of a count variable. It may not have transactions but it is > expected not to be very accurate anyways. > > If I can declare variables which can be changed/read in locked fashion and > visible to all the backends would be a real great use. It shouldn't have > transactions because it is not data but a state. It is in database so that > other connections and stored procedures could see it. > > Coupled with the fact that postgresql has custom data types, there is no > end > how this could be put to use. Lot more things that sit in application > layer > will be inside postgresql, I can image. > >> The whole reason why I made this post was to see if other people have >> had >> similar issues and looked for a similar solution, and to think about if >> there is a solution that fits within PostgreSQL and how it would work. > > AFAIK, there is no way of doing it in postgresql. But I would love to see > it > happen. (I wish I could work on it...:-( ) > I was thinking that it could be done as a contrib/pgfoundary function. I think, but am not sure, that a function can be pre-loaded into the main postgresql backend (postmaster) prior to starting other connections. I'll have to check that out, but I think it is true, if it isn't it should be possible to modify postmaster to do so. The function module, when loaded, looks for its shared memory block, if none is found, then it procededs to create the block, mutex, etc. Then, it is a fairly simple task of managing a name/value table protected by mutex. Make sense? ---(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] Extended customizing, SQL functions,
[EMAIL PROTECTED] writes: > Having internal PostgreSQL variables that are not present on disk, or > maybe, variables that are mirrored on disk may be good. I don't think there's anything wrong with your idea, and there are numerous good solutions that implement it already. But what makes you think this belongs in Postgres? There are plenty of memory and disk based shared databases that are non-transactional and non-relational and meant for storing just this kind of non-relational data. Some are much faster than postgres for simple non-concurrent one-record lookups and updates like this. Use the right tool for the job. Don't try to make one tool do everything, especially something that's anathema to its basic design. -- greg ---(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] Win32, PITR, nested transactions, tablespaces
Tom Lane <[EMAIL PROTECTED]> writes: > Greg Stark <[EMAIL PROTECTED]> writes: > > This is the only place where I see hardly any movement on major items the > > whole development cycle, then a rush of radical changes just before the > > freeze. > > [blink] There's been plenty of stuff done all through this development > cycle (and previous ones too). Read the CVS logs if you've forgotten. Sure, but that's parallel to what I'm saying. This is the only place I see "Please delay the freeze so I can squeeze this major change in just before the release". In other projects I see "Please hurry up and release so I can start committing major changes again". Perhaps it's an artifact of people doing most of their work offline and submitting patches, rather than using the CVS tree as their development environment. Or perhaps it's an artifact of ~nobody using the CVS version of postgres except for testing patches. Or perhaps it's a consequence of the freeze period being so long. Or perhaps the serious postgres developers are just so good that they're justified in being confident applying major changes just before a freeze. Experience does seem to justify that somewhat; I've been repeatedly impressed at how such drastic changes seem to just work with hardly any changes. Fwiw, I do feel that 7.4 is pretty fresh. At least in my case I don't plan on upgrading to 7.5 immediately because 7.4 meets all our needs. When we upgrade it'll probably be for PITR, but we don't really need it yet. -- greg ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Nested xacts: looking for testers and review
On Sat, 29 May 2004, Alvaro Herrera wrote: > On Sat, May 29, 2004 at 08:25:27AM -0700, Stephan Szabo wrote: > > > Also related, although START TRANSACTION (specifying isolation level or > > read onlyness as part) is currently defined to act as if set transaction > > was used, it seems really odd that the settings would leak to the outer > > translation even on a commit and that you can't specify isolation level - > > even if it's the same level - if the outer transaction has done any > > queries. > > Hmm ... isolation level and read onlyness was discussed last year and I > think we had a working design. I'll look into my archives. > > > > BTW: For the deferred trigger stuff, I am guessing you haven't touched > > that at all in the current patch? > > > > I wonder if the following would work assuming that we want deferred > > triggers to run at outer transaction end? > > Ah, this seems to work. I'll implement it and I'll let you know how it > goes. Note, that I think you'd still need to do some kind of tiered thing for set constraint status, but I didn't think about that yet. > > I think it might be possible to do the queue deallocation for > > subtransaction abort with appropriate context work (each one gets a > > context under its parent's and on abort it's removed and on commit it's > > not until you reach the outermost?) but I haven't though about it enough. > > Actually there already is such a global context and I think it's appropiate > here. We probably want to be able to easily remove all the items for an aborted sub transaction, and I was hoping that there might be an easy way to use the contexts to do that rather than manually trolling through deallocating entries from the queue. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] dynamic_library_path on Win32
Thomas Hallgren wrote: I'm using CVS HEAD in a windows environment. I'm trying to start the postmaster using "postmaster -c dynamic_library_path=C:/foo/bar". It starts just fine, then, when I ask it to load a module, an error is generating stating: ERROR: component in parameter "dynamic_library_path" is not an absolute path I added a trace to find out what it thinks the path is. It prints "C". Obviously it treats ':' as a path separator somewhere. Is that the intended behavior on win32? You've found a bug. Clearly we need to adjust the parsing of dynamic_library_path and probably preload_libraries for Win32. cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Nested xacts: looking for testers and review
On Sat, May 29, 2004 at 08:25:27AM -0700, Stephan Szabo wrote: > Also related, although START TRANSACTION (specifying isolation level or > read onlyness as part) is currently defined to act as if set transaction > was used, it seems really odd that the settings would leak to the outer > translation even on a commit and that you can't specify isolation level - > even if it's the same level - if the outer transaction has done any > queries. Hmm ... isolation level and read onlyness was discussed last year and I think we had a working design. I'll look into my archives. > BTW: For the deferred trigger stuff, I am guessing you haven't touched > that at all in the current patch? > > I wonder if the following would work assuming that we want deferred > triggers to run at outer transaction end? Ah, this seems to work. I'll implement it and I'll let you know how it goes. > I think it might be possible to do the queue deallocation for > subtransaction abort with appropriate context work (each one gets a > context under its parent's and on abort it's removed and on commit it's > not until you reach the outermost?) but I haven't though about it enough. Actually there already is such a global context and I think it's appropiate here. -- Alvaro Herrera () "Ninguna manada de bestias tiene una voz tan horrible como la humana" (Orual) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] false infinite recursion detected
Tom Lane wrote: Gaetano Mendola <[EMAIL PROTECTED]> writes: kalman=# select * from v_v_test; ERROR: infinite recursion detected in rules for relation "v_test" I think also my other message: "passing a whole record" is a bug that shall to be fixed. Regards Gaetano Mendola ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Extended customizing, SQL functions,
> On Saturday 29 May 2004 04:38, [EMAIL PROTECTED] wrote: >> Now, I could roll my own system pretty easily, and probably will do so. >> It >> won't take too much, however, it would be neat if this was in >> PostgreSQL. >> >> I fully expect that people would worry about this, and I don't blame >> them. >> It is a *bad* idea. Like I said, I could roll my own, but I'm curious if >> anyone else sees any benefit to this feature. If it is a feature that >> people want, it would best be done from within PostgreSQL. If it is not >> something generally wanted, then I'll keep it here or try to get it on >> gborg or pgfoundary. > > I agree that it could be a nice feature. But it reminds me a quote from a > C++ > FAQ I read once. > > -- > *. Should I use exception for error handling? > > Ans. The real question is can I afford stack unwinding here... > -- > > The situation is similar here. When you want something in database, one > question is to ask is do I need MVCC here? I am a HUGE C/C++ guy. A lot of people dump on C++ because it lets you shoot yourself in the foot with both barrels without even knowing how ... if you are not careful. Oddly enough, this very flexability is what makes it a very powerful and useful language. Similarly, sometimes, it is very difficult to make PostgreSQL do some of the things that you need too. > > Of course depending upon the application context the answer well could be > yes. > But at a lot of places, this could be easily be managed in application and > probably better be done so. > > Personally I do not think managing such information in application is an > hack. > > Just a thought... I may have a unique view of PostgreSQL, but I don't think of it as just a database. I think of it as a great applications platform. Most applications today are data centric, and postgresql fits this bill perfectly. As a data layer it is hard to beat. The fact that it is a great SQL database in its own right, is a huge bonus. That being said, every now and then it lacks this small little feature that working around takes a bit of work. Like functions returning multiple results, that was huge. Functions returning rows, that was huge too. Having internal PostgreSQL variables that are not present on disk, or maybe, variables that are mirrored on disk may be good. The whole reason why I made this post was to see if other people have had similar issues and looked for a similar solution, and to think about if there is a solution that fits within PostgreSQL and how it would work. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] dynamic_library_path on Win32
I'm using CVS HEAD in a windows environment. I'm trying to start the postmaster using "postmaster -c dynamic_library_path=C:/foo/bar". It starts just fine, then, when I ask it to load a module, an error is generating stating: ERROR: component in parameter "dynamic_library_path" is not an absolute path I added a trace to find out what it thinks the path is. It prints "C". Obviously it treats ':' as a path separator somewhere. Is that the intended behavior on win32? Kind regards, Thomas Hallgren ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Extended customizing, SQL functions,
On Saturday 29 May 2004 04:38, [EMAIL PROTECTED] wrote: > Now, I could roll my own system pretty easily, and probably will do so. It > won't take too much, however, it would be neat if this was in PostgreSQL. > > I fully expect that people would worry about this, and I don't blame them. > It is a *bad* idea. Like I said, I could roll my own, but I'm curious if > anyone else sees any benefit to this feature. If it is a feature that > people want, it would best be done from within PostgreSQL. If it is not > something generally wanted, then I'll keep it here or try to get it on > gborg or pgfoundary. I agree that it could be a nice feature. But it reminds me a quote from a C++ FAQ I read once. -- *. Should I use exception for error handling? Ans. The real question is can I afford stack unwinding here... -- The situation is similar here. When you want something in database, one question is to ask is do I need MVCC here? Of course depending upon the application context the answer well could be yes. But at a lot of places, this could be easily be managed in application and probably better be done so. Personally I do not think managing such information in application is an hack. Just a thought... Shridhar ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
