Re: [HACKERS] [pgsql-hackers] Daily digest v1.11023 (17 messages)
From: Tom Lane t...@sss.pgh.pa.usmailto:t...@sss.pgh.pa.us Date: August 19, 2010 10:25:36 AM PDT To: David Fetter da...@fetter.orgmailto:da...@fetter.org Cc: Kevin Grittner kevin.gritt...@wicourts.govmailto:kevin.gritt...@wicourts.gov, Robert Haas robertmh...@gmail.commailto:robertmh...@gmail.com, Pavel Stehule pavel.steh...@gmail.commailto:pavel.steh...@gmail.com, Greg Stark gsst...@mit.edumailto:gsst...@mit.edu, PostgreSQL Hackers pgsql-hackers@postgresql.orgmailto:pgsql-hackers@postgresql.org Subject: Re: wip: functions median and percentile David Fetter da...@fetter.orgmailto:da...@fetter.org writes: On Thu, Aug 19, 2010 at 12:12:12PM -0500, Kevin Grittner wrote: http://www.merriam-webster.com/dictionary/median If you do a google search for median and poke around, you'll find many places where this is the only definition mentioned; the others seem to be rather infrequently used. Why not make the commone usage convenient? The reason not to is the same reason that MEDIAN doesn't appear in the SQL standard, namely that what's common in one field is wrong in another. Hmm, do you have any *evidence* that that's why it's not in the standard? My own take on that is that it's reasonably probable that the SQL committee might standardize a function by that name someday. What we need to be worrying about is the prospect that if there are multiple definitions for the term, they might pick a different one than we did. A name like arithmetic_median seems much less likely to get blindsided by future standardization. regards, tom lane Median is in the standard, you just have to look a little harder, under the section on inverse distribution functions: SELECT PERCENTILE_DIST(0.5) WITHIN GROUP (order by x) ... or SELECT PERCENTILE_CONT(0.5) WITHIN GROUP (order by x) ... Depending on whether you want a discrete or continuous median. Oracle added support for the inverse distribution functions in Oracle 9, which is perhaps why you can find it in the standard. Oracle added the median(x) aggregate as a synonym for percentile_cont(0.5) within group (order by x) in Oracle 10. My money would be on this become standardized at some point, especially since it is a much friendlier syntax. Regards, Caleb
Re: [HACKERS] [pgsql-hackers] Daily digest v1.10705 (13 messages)
On Thu, 2010-06-03 at 05:53 -0300, pgsql-hackers-ow...@postgresql.org wrote: [ . . . ] In my current idea, when a qual-node that contains FuncExpr tries to reference a part of relations within a security view, its referencing relations will be expanded to whole of the security view at distribute_qual_to_rels(). [ . . . ] I may be missing something here but this seems a bit too simplistic and, I think, fails to deal with an important use case. Security views, that do anything useful at all, tend to introduce performance issues. I am concerned that placing a conceptual barrier between the secured and unsecured parts of queries is going to unnecessarily restrict what the optimiser can do. For example consider that we have three secured views, each of the form: create view s_x as select * from x where i_can_see(x.key); and consider the query: select stuff from s_x inner join s_y on s_y.key = s_x.key inner join s_z on s_z.key = s_x.key where fn(s_x.a) = 3; The optimiser ought to be able to spot the fact that i_can_see() need only be called once for each joined result. By placing a barrier (if I understand your proposal correctly) between the outermost joins and the inner views, doesn't this optimisation become impossible? I think a simpler solution may be possible here. If you can tag the function i_can_see() as a security function, at least in the context of its use in the security views, and then create the rule that security functions are always considered to be lower cost than user-defined non-security functions, don't we achieve the result of preventing the insecure function from seeing rows that it shouldn't? I guess my concern is that a query may be constructed a=out of secured and unsecured parts and the optimiser should be free to group all of the secured parts together before considering the unsecured parts. Sorry for the imprecise language and terminolgy, and also if I have completely misunderstood the implications. Best Wishes __ Marc (the veil guy) signature.asc Description: This is a digitally signed message part
Re: [HACKERS] [pgsql-hackers] Daily digest v1.10705 (13 messages)
On Thu, Jun 3, 2010 at 1:23 PM, Marc Munro m...@bloodnok.com wrote: On Thu, 2010-06-03 at 05:53 -0300, pgsql-hackers-ow...@postgresql.org wrote: [ . . . ] In my current idea, when a qual-node that contains FuncExpr tries to reference a part of relations within a security view, its referencing relations will be expanded to whole of the security view at distribute_qual_to_rels(). [ . . . ] I may be missing something here but this seems a bit too simplistic and, I think, fails to deal with an important use case. If anything, you're putting it mildly. This is quite a bit too simplistic and fails to deal with several important issues, at least some of which have already been mentioned on this thread. The optimiser ought to be able to spot the fact that i_can_see() need only be called once for each joined result. By placing a barrier (if I understand your proposal correctly) between the outermost joins and the inner views, doesn't this optimisation become impossible? I think a simpler solution may be possible here. If you can tag the function i_can_see() as a security function, at least in the context of its use in the security views, and then create the rule that security functions are always considered to be lower cost than user-defined non-security functions, don't we achieve the result of preventing the insecure function from seeing rows that it shouldn't? So, yes and no. You DO need a security barrier between the view and the rest of the query, but if a function can be trusted not to do evil things, then it should be allowed to be pushed down. What we need to prevent is the pushdown of untrusted functions (or operators). A (very) important part of this problem is determining which quals are safe to push down. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-hackers] Daily digest v1.9430 (16 messages)
-- Forwarded message -- From: Greg Stark gsst...@mit.edu To: Simon Riggs si...@2ndquadrant.com Date: Sun, 30 Aug 2009 00:28:14 +0100 Subject: Re: LWLock Queue Jumping On Fri, Aug 28, 2009 at 8:07 PM, Simon Riggssi...@2ndquadrant.com wrote: WALInsertLock is heavily contended and likely always will be even if we apply some of the planned fixes. I've lost any earlier messages, could you resend the raw data on which this is based? Some callers of WALInsertLock are more important than others * Writing new Clog or Multixact pages (serialized by ClogControlLock) * For Hot Standby, writing SnapshotData (serialized by ProcArrayLock) In these cases it seems like we can skip straight to the front of the WALInsertLock queue without problem. How does re-ordering reduce the contention? If you hold one contended lock while waiting in a FIFO for another contended lock, you just made the first lock that much more contended. Jumping queue on the WALInsertLock probably does not reduce contention on WALInsertLock, but does prevent that contention from introducing derivative contention on other locks which are already held while waiting (ProcArrayLock and ClogControlLock) We reorder shared lockers ahead of exclusive lockers because they can all hold the lock at We don't explicitly reorder shared lockers ahead of exclusive lockers. The reordering works for either case. A holder of a shared lock who drops the lock but then grabs it again before the awakened exclusive waiter has to chance to grab it is reordered, but so is the exclusive holder who drops a lock and then grabs it again before any of the awakened shared waiters have had a chance to grab it. The primary point is not to reorder the locks, but to avoid excessive context switches. the same time so we can reduce the amount of time the lock is held. Reordering some exclusive lockers ahead of other exclusive lockers won't reduce the amount of time the lock is held at all. Are you saying the reason to do it is to reduce time spent waiting on this lock while holding other critical locks? Do we have tools to measure how long is being spent waiting on one lock while holding another lock so we can see if there's a problem and whether this helps? I don't know of any formal tools for that. I just add elog statements at strategic places and then mine the logfile. You have to be careful that the time spent doing the logging doesn't distort the timings too much, but I usually haven't found that to be a problem. I've toyed with changes to LWLOCK_STATS to help, but you have to focus on a few specific locks or else the overhead is generally too high, and if you are interested in only a handful of locks adding elog statements seems easier. But I was looking in other areas of the code, not this specific area under discussion. Jeff
Re: [HACKERS] [pgsql-hackers] Daily digest v1.9418 (15 messages)
On Thu, Aug 27, 2009 at 01:12:20PM -0400, Robert Haas wrote: This is pretty cool, IMO. Admittedly, it does seem hard to bottle it, but you managed it, so it's not completely impossible. What you could for this kind of thing is a series of patches and driver scripts, so you build PostgreSQL with the patch, then run the driver script against it. Probably we'd want to standardize some kind of framework for the driver scripts, once we had a list of ideas for testing and some idea what it should look like. Another similar idea I've had in the back of my head for a while is to setup postgres so it is the only process in a VM. Subsequently after every single write() syscall, snapshot the filesystem and then run the recovery process over each one. It would likely take an unbeleivably long time to run, and maybe there's some trick to speed it up, but together with code coverage results it could give you good results as to the reliability of the recovery process. Probably more a research project than anything else though. Have a nice day, -- Martijn van Oosterhout klep...@svana.org http://svana.org/kleptog/ Please line up in a tree and maintain the heap invariant while boarding. Thank you for flying nlogn airlines. signature.asc Description: Digital signature
Re: [HACKERS] [pgsql-hackers] Daily digest v1.9418 (15 messages)
-- Forwarded message -- From: Kevin Grittner kevin.gritt...@wicourts.gov To: Robert Haas robertmh...@gmail.com, Bruce Momjian br...@momjian.us Date: Thu, 27 Aug 2009 09:07:05 -0500 Subject: Re: 8.5 release timetable, again Robert Haas robertmh...@gmail.com wrote: Maybe we should be looking at an expanded test suite that runs on a time scale of hours rather than seconds. if we could say that we had a regression test suite which covered X% of our code, and it passed on all Y platforms tested, that would certainly be a confidence booster, especially for large values of X. Part of the question, of course, is how to build up such a regression test suite. Aren't there code coverage monitoring tools that could be run during regression tests? Sure it would take some time to review the results and fashion tests to exercise chunks of code which were missed, but at least we could quantify X and try to make incremental progress on increasing it But the fact that a piece of code was executed doesn't mean it did the right thing. If it does something subtly wrong, will we notice? Jeff
Re: [HACKERS] [pgsql-hackers] Daily digest v1.9418 (15 messages)
Jeff Janes jeff.ja...@gmail.com wrote: But the fact that a piece of code was executed doesn't mean it did the right thing. If it does something subtly wrong, will we notice? That's why it takes some time to fashion a decent test. On the other hand, if code is not being exercised at at all during the beta testing phase, it could do something dramatically wrong and we wouldn't notice. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-hackers] Daily digest v1.9418 (15 messages)
-- Forwarded message -- From: Tom Lane t...@sss.pgh.pa.us To: Robert Haas robertmh...@gmail.com Date: Thu, 27 Aug 2009 10:11:24 -0400 Subject: Re: 8.5 release timetable, again What I'd like to see is some sort of test mechanism for WAL recovery. What I've done sometimes in the past (and recently had to fix the tests to re-enable) is to kill -9 a backend immediately after running the regression tests, let the system replay the WAL for the tests, and then take a pg_dump and compare that to the dump gotten after a conventional run. However this is quite haphazard since (a) the regression tests aren't especially designed to exercise all of the WAL logic, and (b) pg_dump might not show the effects of some problems, particularly not corruption in non-system indexes. It would be worth the trouble to create a more specific test methodology. I hacked mdwrite so that it had a static int counter. When the counter hit 400 and if the guc_of_death was set, it would write out a partial block (to simulate a partial page write) and then PANIC. I have some Perl code that runs against the database doing a bunch of updates until the database dies. Then when it can reconnect again it makes sure the data reflects what Perl thinks it should. This is how I (belatedly) found and traced down the bug in the visibility bit. (What I was trying to do is determine if my toying around with XLogInsert was breaking anything. Since the regression suit wouldn't show me a problem if one existed, I came up with this. Then I found things were broken even before I started toying with it...) I don't know how lucky I was to hit open a test that found an already existing bug. I have to assume I was somewhat lucky, simply because it took a run of many hours or overnight (with a simulated crash every 2 minutes or so) to reliably detect the problem. But how do you turn something like this into a regression test? Scattering the code with intentional crash inducing code that is there to exercise the error recover parts seems like it would be quite a mess. In short: merely making the tests bigger doesn't impress me in the least. Focused testing on areas we aren't covering at all could be worth the trouble. Do you have suggestions on what other areas need it? Jeff
Re: [HACKERS] [pgsql-hackers] Daily digest v1.9418 (15 messages)
On Thu, Aug 27, 2009 at 12:47 PM, Jeff Janesjeff.ja...@gmail.com wrote: -- Forwarded message -- From: Tom Lane t...@sss.pgh.pa.us To: Robert Haas robertmh...@gmail.com Date: Thu, 27 Aug 2009 10:11:24 -0400 Subject: Re: 8.5 release timetable, again What I'd like to see is some sort of test mechanism for WAL recovery. What I've done sometimes in the past (and recently had to fix the tests to re-enable) is to kill -9 a backend immediately after running the regression tests, let the system replay the WAL for the tests, and then take a pg_dump and compare that to the dump gotten after a conventional run. However this is quite haphazard since (a) the regression tests aren't especially designed to exercise all of the WAL logic, and (b) pg_dump might not show the effects of some problems, particularly not corruption in non-system indexes. It would be worth the trouble to create a more specific test methodology. I hacked mdwrite so that it had a static int counter. When the counter hit 400 and if the guc_of_death was set, it would write out a partial block (to simulate a partial page write) and then PANIC. I have some Perl code that runs against the database doing a bunch of updates until the database dies. Then when it can reconnect again it makes sure the data reflects what Perl thinks it should. This is how I (belatedly) found and traced down the bug in the visibility bit. (What I was trying to do is determine if my toying around with XLogInsert was breaking anything. Since the regression suit wouldn't show me a problem if one existed, I came up with this. Then I found things were broken even before I started toying with it...) I don't know how lucky I was to hit open a test that found an already existing bug. I have to assume I was somewhat lucky, simply because it took a run of many hours or overnight (with a simulated crash every 2 minutes or so) to reliably detect the problem. But how do you turn something like this into a regression test? Scattering the code with intentional crash inducing code that is there to exercise the error recover parts seems like it would be quite a mess. This is pretty cool, IMO. Admittedly, it does seem hard to bottle it, but you managed it, so it's not completely impossible. What you could for this kind of thing is a series of patches and driver scripts, so you build PostgreSQL with the patch, then run the driver script against it. Probably we'd want to standardize some kind of framework for the driver scripts, once we had a list of ideas for testing and some idea what it should look like. ...Robert P.S. The subject line of this thread is not ideal. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Pgsql-hackers
a fur cap on his head. The sledge drove round the square twice, and Kay tied on
Re: [HACKERS] [pgsql-hackers] Posting to hackers and patches lists [OT]
and thus spake [EMAIL PROTECTED] [2008.05.07 @ 16:23]: Date: Wed, 07 May 2008 11:18:48 -0400 From: Andrew Dunstan [EMAIL PROTECTED] If you want an email and web-based tracking system, RT is wonderful (http://bestpractical.com/rt/)... STOP! Sorry for biting... I just couldn't read RT and wonderful in the same sentance and keep quiet. -Steve signature.asc Description: Digital signature
Re: [HACKERS] [pgsql-hackers] Daily digest v1.6352 (22 messages)
On Mon, 2006-10-02 at 12:02 -0300, Shaunak Godbole wrote: Hi, We are trying to introduce access control. For this we have to rewrite the input query by replacing each relation by its corresponding authorized view. I assume from this that you are trying to implement something like Oracle's Virtual Private Database. If you need access controls at the row or column level, and do not want to implement this whole thing yourself, please take a look at Veil (http://veil.projects.postgresql.org/) which can already accomplish the same sort of thing, though in a different way. If Veil is insufficient for your needs in some way, I'd be interested to hear about it. __ Marc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] [pgsql-hackers] Daily digest v1.5943 (21 messages)
On Fri, 2006-05-19 at 13:41 -0300, [EMAIL PROTECTED] wrote: Marc Munro wrote: Veil http://pgfoundry.org/projects/veil is currently not a very good Postgres citizen. It steals what little shared memory it needs from postgres' shared memory using ShmemAlloc(). For Postgres 8.2 I would like Veil to be a better citizen and use only what shared memory has been reserved for postgres add-ins. Why should this be individually restricted? AFAICS Veil's functionality would be essential to access row level ACL controlled tables, so if it fails for low mem conditions it's much like a backend failure. The problem is that postgres currently has no way of knowing how much shared memory Veil is likely to require, and so will not allocate space for it. Consequently if Veil needs a lot of shared memory, it is unlikely to be able to get it. My intention is to allow add-ins to use only shared memory that has been allocated for their own use, to ensure that enough has been allocated, to isolate postgres shared memory from abuse by add-ins, and to avoid the need for add-ins to manage their own shared memory. __ Marc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] [pgsql-hackers-win32] Build with Visual Studio MSVC
On 5/5/06, Jonah H. Harris [EMAIL PROTECTED] wrote: On 5/5/06, Gurjeet Singh [EMAIL PROTECTED] wrote: If it is such a 'simple porting', may I ask why hasn't it been attempted successfuly in so many years of PG's history? Because most of use don't use Windows... I thought I said that. But a sizable number of pgsql's users (developers and others) do!!! This 'simple porting' will allow and pull-in a lot more talented devs than you and I. Sorry, but when it comes to Windows, the word talent is extremely relative. So is the case with Nixens too! For eg., nixen developers are known for great programming talent, but when it comes to being user-friendly and look-and-feel their creations suck! I dont know the case now, but till a year ago (before it went open), even after 20 years in production, SUN Solaris' GUI was a shame. I favour Windows over nixens, not because I like Billy, or because Unix is Evil, but because, Windows has snatched the monopoly of computers from geeks and brought it to the common man. It has enabled the not-so-rich to buy a computer and hop on to the tech bandwagon; which ultimately means more-to-do (jobs) for geeks! It might be buggy, it might be slow, they might have stolen the idea from Mac... I don't care; I am using one right now to communicate with the world. Let other's make fun of it... I respect it; and will continue to, for the rest of my life, even if I ever start using Linux in future. Wish me luck in this effort Good luck! Thank you Mr Jonah, I think your wish materialized and I have found a solution! -- Jonah H. Harris, Database Internals Architect EnterpriseDB Corporation 732.331.1324 Hi Everybody, Finally I have succeeded in being able to debug pgsql using a GUI IDE, and no, it is not MSVC; its Eclipse. As a Windows developer alI I was looking for was a simple-yet-effective GUI, that is capable of showing me multiple facets of the project very easily, and allow me to switch settings easly (radio buttons, check-boxes) instead of messing around with cryptic makefiles and config files. CDT (Eclipse plugin for C/C++) comes very close to what I (a WinDev) wanted to get started with PG/OSS. It has nice configurable GUI, breakpoints, watches, keyboard shortcuts, etc etc, almost everything that I wanted. Best of all, the shortcuts are configurable; although I think the defaults are for emacs users, but I can change them to work like in VC. I say 'almost' because it is a work-in-progress, and there are a few (major) performance bottlenecks (especially the symbol-indexer). It works seamlessly with the msys (mingw) toolkit. It parses the make-output and builds it's project; no need to scratch your head and which files are to be imported in the project. Then, it uses the gdb in the background, to let you attach to an already-running process, and lets you debug it, just lilke in VC. It surely is a dream come true. I spent few hours installing/uninstalling the msys toolkit, before I got it right with the help from mingw's wiki pages. There were other gotchas too after the toolkit started working; creating user postgres and running postmaster under it, --with-debug flag to ./configure for gdb work, hacking config file to disable gcc optimizations, having to run Eclipse as user 'postgres', and many more The best part about it is that there is no need for any new project to be created and maintained (like vcproject), nor are any changes/inclusions required to the existing source-tree. Simply checkout a CVS module, and start working with it On top of that, it uses the pg-recommended toolkit for Windows; so, you can even package and distribute your builds (not recommended though)! Finally I have got what I wanted. Now I think I (and any other WinDev) can work/learn/contribute to the PG and other OSS! I will put together a complete, step-by-step procedure of how to set it all up, so that one can get up and running in no time at all. I am not going to pursue the VC or VS integration anymore, and I highly recommend everyone to use this solution if you want to develop PG/OSS on windows. A big thank you to all, Gurjeet. PS: Here's a bit long PS where I took the liberty to pour my heart out: I know that I (re-)started this thread with a request for MSVC support. I like VC++6 very much; convenience of shortcuts for everything (I hardly use mouse when working on VC), and the nice configurable layout. I like it more than it's successors, VS.Net versions (mouse is almost indispensable), and thats why I was pushing for VC rather than VS. But I am giving up on the idea because the situation demands it. Last year I had tried my hands on building version 7.4 of PG using the cygwin, but was put-off by gdb's kludgy interface when it came to debugging; so I gave up on it and got busy with other things. Although I have worked on Solaris and Linux for 1 and 1/2 years, and used gcc-gdb for everything, but I couldn't
Re: [HACKERS] [pgsql-hackers-win32] Build with Visual Studio MSVC
Gurjeet Singh wrote: My main grudge is that if we are supporting almost all flovours of nixens and compilers (close to 34 according to official website), then why are we leaving Windows platform alone? This will bring in quite a lot more developers. You should look at MinGW as a development toolkit, not a platform. PostgreSQL builds and runs just fine on the Windows platform. Personally, I use Eclipse C/C++ with MinGW since it brings me a number of advantages. The most prominent one is that I only need to master one IDE regardless of platform. I am sure it's not going to be easy, but I am sure with this great community suppport, we sure can achieve it. Seems some people has done a lot of work to get things working with VC++ already. Search for the word MSVC on this list. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [pgsql-hackers-win32] Build with Visual Studio MSVC
`vcproject` is based on pgsql-8.0.3. It's purpose is to make pgsql built with MSVC++. But I found there are few people intrested on it, so I stopped maintaining it months ago. `vcproject` still need MSYS/MinGW, the basic idea behind it is: 1) Let we do configure, make, make install in MinGW first. This step can make sure our source code is OK under MinGW, building with GNU toolchain. 2) My major work is maintaining MSVC++'s special project files, including *.dsp and *.dsw. I have also do some minor changes to the source files, you can diff with pgsql-8.0.3. 3) Finally, I can build the while system with MSVC++'s IDE or command line MSVC.exe. See README for details. The link is: http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/vcproject/vcproject/README?rev=1 .8content-type=text/x-cvsweb-markup `vcproject` is not perfect, but it works for me. And I think it can work with pgsql-8.1. Sorry for the late response. Regards, William ZHANG ---(end of broadcast)--- TIP 1: 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] [pgsql-hackers] Daily digest v1.5568 (24 messages)
I wonder if this idea might be taken a little further, to allow read-only tablespaces? This would allow old partitions in very large databases to be kept on read-only media, and would allow normal backups to ignore this unchanging set of data. It also allows for certain specific optimisations for this type of data, as the MVCC rules are now relaxed. Inclusion of a row in a read-only index is now enough to guarantee the visibility of that row to all backends, and fetches based solely on the index now become possible. FWIW, Oracle does something like this. Just a thought. __ Marc On Mon, 2005-11-21 at 09:53 -0400, [EMAIL PROTECTED] wrote: Date: Sun, 20 Nov 2005 22:39:49 +0200 (EET) From: Heikki Linnakangas [EMAIL PROTECTED] To: pgsql-hackers@postgresql.org Subject: Data directory on read-only media Message-ID: [EMAIL PROTECTED] Hi, I've been thinking about running postgres from read-only media. It's handy for creating demo CDs etc. I hacked together a patch that allows you to run Postgres without write permissions to the data directory. signature.asc Description: This is a digitally signed message part
Re: [HACKERS] [pgsql-hackers] Daily digest v1.5568 (24 messages)
On Mon, 21 Nov 2005, Marc Munro wrote: I wonder if this idea might be taken a little further, to allow read-only tablespaces? This would allow old partitions in very large databases to be kept on read-only media, and would allow normal backups to ignore this unchanging set of data. I guess you could do that, but it's really quite a different problem. It also allows for certain specific optimisations for this type of data, as the MVCC rules are now relaxed. Inclusion of a row in a read-only index is now enough to guarantee the visibility of that row to all backends, and fetches based solely on the index now become possible. There's this TODO: Allow data to be pulled directly from indexes Currently indexes do not have enough tuple visibility information to allow data to be pulled from the index without also accessing the heap. One way to allow this is to set a bit to index tuples to indicate if a tuple is currently visible to all transactions when the first valid heap lookup happens. This bit would have to be cleared when a heap tuple is expired. That method doesn't require read-only tablespaces. - Heikki ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-hackers-win32] Time to close hackers-win32?
Magnus Hagander wrote: It occurs to me that there is no longer any great need to have a separate hackers list for win32 development. Perhaps we should close it down now and keep all development on -hackers? I also think this is a good idea. The number of win32 only issues of -hacker level is significantly smaller now, and having to bounce people between the lists can be kind of annoying... Agreed. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 5: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-hackers-win32] Time to close pgsql-cygwin?
Magnus Hagander schrieb: It occurs to me that there is no longer any great need to have a separate hackers list for win32 development. Perhaps we should close it down now and keep all development on -hackers? I also think this is a good idea. The number of win32 only issues of -hacker level is significantly smaller now, and having to bounce people between the lists can be kind of annoying... I believe we should close pgsql-cygwin also. The cygwin users should ask at the official cygwin list as described in the README and CYGWIN announcements, not at the pgsql-cygwin list. Most problems are cygwin specific, others are carried in the FAQ_README and the seperate /usr/share/doc/Cygwin/postgresql-x.x.x.README If so, I'll write a documentation patch. -- Reini Urban http://phpwiki.org/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-hackers-win32] Time to close hackers-win32?
It occurs to me that there is no longer any great need to have a separate hackers list for win32 development. Perhaps we should close it down now and keep all development on -hackers? I also think this is a good idea. The number of win32 only issues of -hacker level is significantly smaller now, and having to bounce people between the lists can be kind of annoying... //Magnus ---(end of broadcast)--- TIP 1: 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
[HACKERS] pgsql-hackers@postgresql.org
2) As long as we're using CVS, the only way to organize autonomous project teams that have authority over their special areas but no ability to change central code is to push out projects to separate CVS trees. This has never been an issue before, AFAIK, nobody with commit privliges in a separate package has ever changed the code where they weren't supposed to. To sum this up; the arguments presented are: 1) The tarball is/was too big however nobody ever complained. 2) CVS does not allow different groups to have commit privliges, but nobody has ever violated the trust FYI, subversion w/apache allows you to control access permissions. So you can have separate branches/sub-trees with different write permissions for different developers. Also, subversion does a fairly decent job of supporting the same command line options as CVS, so from the end user side it is fairly close to being a drop in replacement, because you don't need to re-learn too much. Of course there is the conversion from CVS to SVN, which is not necessarily easy and definetly not quick/simple. SVN also has a number of nice features like atomic commits, versioning directories, etc. Later Rob __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---(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] pgsql-hackers@postgresql.org
Rob Butler wrote: [details of some SVN features] please see reecent debates on the topic of SCM systems. Those who do not remember the debates on the mailing lists are bound to repeat them. cheers andrew ---(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] pgsql-hackers@postgresql.org
Rob Butler wrote: ... SVN also has a number of nice features like atomic commits, versioning directories, etc. Still, subversion identifies file content by it's location in the directory tree which makes the directory versioning a lot less useful than it could have been. Renaming directories or even renaming files creates havoc if you have several simultanious branches that need to be merged at some point. Serious design flaw IMHO. When will subversion be able to *really* rename or move an element as opposed to just remove and add? Regards, Thomas Hallgren ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
Tatsuo Ishii wrote: I do understand the problem, but don't undertstand the decision you guys made. The fact that UPPER/LOWER and some other functions does not work in win32 is surely a problem for some languages, but not a problem for otheres. For example, Japanese (and probably Chinese and Korean) does not have a concept upper/lower. So the fact UPPER/LOWER does not work with UTF-8/win32 is not problem for Japanese (and for some other languages). Just using C locale with UTF-8 is enough in this case. In summary, I think you guys are going to overkill the multibyte support functionality on UTF-8/win32 because of the fact that some langauges do not work. Same thing can be said to EUC-JP, EUC-CN and EUC-KR and so on as well. I strongly object the policy to try to unconditionaly disable UTF-8 support on win32. I have just applied a patch to CVS HEAD and 8.0.X that disables locale-aware handling of upper/lower/initcap when the locale is C or POSIX. With these changes, it seems safe to allow pginstaller to use UTF8 encoding of the locale is C/POSIX. If we don't do that, I am concerned that Asian users will either make a hacked installer or be required to run initdb manually by following complex instructions. We could throw a warning if the combination is selected as a compromise. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
Peter Eisentraut wrote: o Disallow encodings like UTF8 which PostgreSQL supports but the operating system does not (already disallowed by pginstaller) I think the warning that initdb shouts out is already enough for this. I don't think we want to disallow this for people who know what they are doing. I have updated the Win32 TODO item: o Add support for Unicode To fix this, the data needs to be converted to/from UTF16/UTF8 so the Win32 wcscoll() can be used, and perhaps other functions like towupper(). However, UTF8 already works with normal locales but provides no ordering or character set classes. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 7: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-hackers-win32] Repleacement for src/port/snprintf.c
I have reviewed this patch, and I already added these changes myself in CVS. Thanks. --- Nicolai Tufar wrote: On Mon, Feb 21, 2005 at 10:53:08PM -0500, Bruce Momjian wrote: Applied. Thanks a lot. The patch attached solves the tread safety problem. Please review it before applying, I am not sure I am doing the right thing On Tue, 22 Feb 2005 19:57:15 +0100, Kurt Roeckx [EMAIL PROTECTED] wrote: The configure test is a little broken. It needs to quote the $'s. I've rewritten the test a little. This one needs applying too. $'s do get scrambled. Best regards, Nicolai. [ Attachment, skipping... ] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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
Re: [HACKERS] [pgsql-hackers-win32] Repleacement for src/port/snprintf.c
Would you please check current CVS? I think I addressed most of these issues already. --- Nicolai Tufar wrote: On Mon, Feb 21, 2005 at 10:53:08PM -0500, Bruce Momjian wrote: Applied. Thanks a lot. The patch attached solves the tread safety problem. Please review it before applying, I am not sure I am doing the right thing On Tue, 22 Feb 2005 19:57:15 +0100, Kurt Roeckx [EMAIL PROTECTED] wrote: The configure test is a little broken. It needs to quote the $'s. I've rewritten the test a little. This one needs applying too. $'s do get scrambled. Best regards, Nicolai. [ Attachment, skipping... ] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 7: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-hackers-win32] snprintf causes regression tests to fail
Nicolai Tufar [EMAIL PROTECTED] writes: Amazingly enough HAVE_LONG_LONG_INT_64 is defined when compilation comes to src/port/snprintf.c but the result is still wrong. I looked into configure.in but the check for HAVE_LONG_LONG_INT_64 is too complicated for me to understand. Bruce, could you take a look at this? I am 90% sure it is an issue with some configure definitions. Just out of curiosity, do either HAVE_INT64 or HAVE_UINT64 get set in pg_config.h? The observed symptoms would be explained if typedef int64 were ending up as long rather than long long. Looking at the #ifdef nest in include/c.h, there are a couple of ways that could happen, including importing a definition from system header files. If this were happening, it would presumably break all int8 math not only snprintf, so I'm not sure it's the story. As far as I've seen, no one has actually posted the regression diffs seen in this failure, so most of us are in the dark about the details of the problem. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [pgsql-hackers-win32] snprintf causes regression tests to fail
On Tue, 01 Mar 2005 17:45:31 -0500, Tom Lane Just out of curiosity, do either HAVE_INT64 or HAVE_UINT64 get set in pg_config.h? pg_config.h is attached. What drew my attention is the following declaration: /* Define to 1 if `long long int' works and is 64 bits. */ #define HAVE_LONG_LONG_INT_64 is it normal? should it not be like this: #define HAVE_LONG_LONG_INT_64 1 /* src/include/pg_config.h. Generated by configure. */ /* src/include/pg_config.h.in. Generated from configure.in by autoheader. */ /* Define to the type of arg 1 of 'accept' */ #define ACCEPT_TYPE_ARG1 unsigned int /* Define to the type of arg 2 of 'accept' */ #define ACCEPT_TYPE_ARG2 struct sockaddr * /* Define to the type of arg 3 of 'accept' */ #define ACCEPT_TYPE_ARG3 int /* Define to the return type of 'accept' */ #define ACCEPT_TYPE_RETURN unsigned int PASCAL /* The alignment requirement of a `double'. */ #define ALIGNOF_DOUBLE 8 /* The alignment requirement of a `int'. */ #define ALIGNOF_INT 4 /* The alignment requirement of a `long'. */ #define ALIGNOF_LONG 4 /* The alignment requirement of a `long long int'. */ #define ALIGNOF_LONG_LONG_INT 8 /* The alignment requirement of a `short'. */ #define ALIGNOF_SHORT 2 /* Define to the default TCP port number on which the server listens and to which clients will try to connect. This can be overridden at run-time, but it's convenient if your clients have the right default compiled in. (--with-pgport=PORTNUM) */ #define DEF_PGPORT 5432 /* Define to the default TCP port number as a string constant. */ #define DEF_PGPORT_STR 5432 /* Define to 1 if you want National Language Support. (--enable-nls) */ /* #undef ENABLE_NLS */ /* Define to 1 to build client libraries as thread-safe code. (--enable-thread-safety) */ /* #undef ENABLE_THREAD_SAFETY */ /* Define to 1 if getpwuid_r() takes a 5th argument. */ /* #undef GETPWUID_R_5ARG */ /* Define to 1 if gettimeofday() takes only 1 argument. */ /* #undef GETTIMEOFDAY_1ARG */ #ifdef GETTIMEOFDAY_1ARG # define gettimeofday(a,b) gettimeofday(a) #endif /* Define to 1 if you have the `atexit' function. */ #define HAVE_ATEXIT 1 /* Define to 1 if you have the `cbrt' function. */ #define HAVE_CBRT 1 /* Define to 1 if you have the `class' function. */ /* #undef HAVE_CLASS */ /* Define to 1 if you have the `crypt' function. */ /* #undef HAVE_CRYPT */ /* Define to 1 if you have the crypt.h header file. */ /* #undef HAVE_CRYPT_H */ /* Define to 1 if you have the declaration of `fdatasync', and to 0 if you don't. */ #define HAVE_DECL_FDATASYNC 0 /* Define to 1 if you have the declaration of `snprintf', and to 0 if you don't. */ #define HAVE_DECL_SNPRINTF 1 /* Define to 1 if you have the declaration of `vsnprintf', and to 0 if you don't. */ #define HAVE_DECL_VSNPRINTF 1 /* Define to 1 if you have the dld.h header file. */ /* #undef HAVE_DLD_H */ /* Define to 1 if you have the `dlopen' function. */ /* #undef HAVE_DLOPEN */ /* Define to 1 if you have the editline/history.h header file. */ /* #undef HAVE_EDITLINE_HISTORY_H */ /* Define to 1 if you have the editline/readline.h header file. */ /* #undef HAVE_EDITLINE_READLINE_H */ /* Define to 1 if you have the endian.h header file. */ /* #undef HAVE_ENDIAN_H */ /* Define to 1 if you have the `fcvt' function. */ #define HAVE_FCVT 1 /* Define to 1 if you have the `fdatasync' function. */ /* #undef HAVE_FDATASYNC */ /* Define to 1 if you have finite(). */ #define HAVE_FINITE 1 /* Define to 1 if you have the `fpclass' function. */ /* #undef HAVE_FPCLASS */ /* Define to 1 if you have the `fp_class' function. */ /* #undef HAVE_FP_CLASS */ /* Define to 1 if you have the `fp_class_d' function. */ /* #undef HAVE_FP_CLASS_D */ /* Define to 1 if you have the fp_class.h header file. */ /* #undef HAVE_FP_CLASS_H */ /* Define to 1 if fseeko (and presumably ftello) exists and is declared. */ /* #undef HAVE_FSEEKO */ /* Define to 1 if your compiler understands __func__. */ #define HAVE_FUNCNAME__FUNC 1 /* Define to 1 if your compiler understands __FUNCTION__. */ /* #undef HAVE_FUNCNAME__FUNCTION */ /* Define to 1 if you have the `getaddrinfo' function. */ /* #undef HAVE_GETADDRINFO */ /* Define to 1 if you have the `gethostbyname_r' function. */ /* #undef HAVE_GETHOSTBYNAME_R */ /* Define to 1 if you have the `gethostname' function. */ /* #undef HAVE_GETHOSTNAME */ /* Define to 1 if you have the `getopt' function. */ #define HAVE_GETOPT 1 /* Define to 1 if you have the getopt.h header file. */ #define HAVE_GETOPT_H 1 /* Define to 1 if you have the `getopt_long' function. */ #define HAVE_GETOPT_LONG 1 /* Define to 1 if you have the `getpeereid' function. */ /* #undef HAVE_GETPEEREID */ /* Define to 1 if you have the `getpwuid_r' function. */ /* #undef HAVE_GETPWUID_R */ /* Define to 1 if you have the `getrusage' function. */ /* #undef HAVE_GETRUSAGE */ /* Define to 1 if you have the history.h header file. */ /* #undef HAVE_HISTORY_H */ /* Define to 1 if
Re: [HACKERS] [pgsql-hackers-win32] snprintf causes regression tests to fail
Nicolai Tufar wrote: On Tue, 01 Mar 2005 17:45:31 -0500, Tom Lane [EMAIL PROTECTED] wrote: Nicolai Tufar [EMAIL PROTECTED] writes: Just out of curiosity, do either HAVE_INT64 or HAVE_UINT64 get set in pg_config.h? The observed symptoms would be explained if typedef int64 were ending up as long rather than long long. Looking at the #ifdef nest in include/c.h, there are a couple of ways that could happen, including importing a definition from system header files. If this were happening, it would presumably break all int8 math not only snprintf, so I'm not sure it's the story. I am looking into it. Will report if find something of importance. As far as I've seen, no one has actually posted the regression diffs seen in this failure, so most of us are in the dark about the details of the problem. Regression diiff is attached. The problem is reported by Magnus and me. Probably nobody else compiles pg under Win32 these days. I am testing the failure here. I will keep at it until I find the cause. The only downside is that Win32 compiles are much slower than Unix. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 7: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
John Hansen wrote:
currently, upper/lower does not work with 2+ byte unicode
characters,
on any OS under the C locale.
Sure it does. It's just that the defined behavior of the C
locale is often useless in practice.
select upper('æøå');
ERROR: invalid multibyte character for locale
HINT: The server's LC_CTYPE locale is probably incompatible with the database
encoding.
Consequently it seems that is does not work.
... John
---(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] [pgsql-hackers-win32] Repleacement for src/port/snprintf.c
On Thu, 24 Feb 2005 22:18:11 -0500, Tom Lane [EMAIL PROTECTED] wrote: Didn't we do that already? No :( I promised to do it a couple of weeks ago but could not get to do it. Now with Magnus's help I finaly did it. The last patch should be fine. regards, tom lane Nicolai ---(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] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
John Hansen [EMAIL PROTECTED] writes:
Sure it does. It's just that the defined behavior of the C
locale is often useless in practice.
select upper('æøå');
ERROR: invalid multibyte character for locale
HINT: The server's LC_CTYPE locale is probably incompatible with the
database encoding.
Consequently it seems that is does not work.
It fails on my machine should not be read as it doesn't work for anyone.
It all depends on how your local mbstowcs() works.
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] [pgsql-hackers] Daily digest v1.4988 (21 messages)
Tom, As a proposal: feature freeze maybe early summer (June or July), beta maybe Aug/Sep, final as always when it's ready (maybe Oct/Nov with a good tailwind). I thought we were trying to get away from a midsummer feature freeze, due to the general lack of personnel in that season? I can tell you that, while I'm probably the least critical person for a feature freeze, I will be unavailable for anything development-related from July 10 to August 6th. And at least a dozen PG people will be presenting at OSCON, which means that their attention will be divided in the last week of July. And there's a bunch of European conventions in June, for that matter. So I'd advocate either freezing in May, or in September. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-hackers] Daily digest v1.4988 (21 messages)
Josh Berkus wrote: I thought we were trying to get away from a midsummer feature freeze, due to the general lack of personnel in that season? Better to do feature freeze with no one around than development or release preparations with no one around, no? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
select upper('æøå');
ERROR: invalid multibyte character for locale
HINT: The server's LC_CTYPE locale is probably
incompatible with the database encoding.
Consequently it seems that is does not work.
It fails on my machine should not be read as it doesn't
work for anyone.
It all depends on how your local mbstowcs() works.
Ok,... Do you have an example of a system on which it works?
... John
---(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] [pgsql-hackers] Daily digest v1.4988 (21 messages)
On Fri, 25 Feb 2005, Peter Eisentraut wrote: Josh Berkus wrote: I thought we were trying to get away from a midsummer feature freeze, due to the general lack of personnel in that season? Better to do feature freeze with no one around than development or release preparations with no one around, no? I'd say the other way around ... at least when 'noone is around', one person that is can still work on the feature they are working on ... feature freeze when nobody around means the code stagnants since nobody is around to test/give feedback ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
John Hansen [EMAIL PROTECTED] writes: It fails on my machine should not be read as it doesn't work for anyone. It all depends on how your local mbstowcs() works. Ok,... Do you have an example of a system on which it works? On HPUX 10.20, mbstowcs seems to treat all byte values as single-byte characters in C locale, so my sample-of-one says that it works everywhere ;-). Nonetheless, it's clear that in C locale mbstowcs cannot be buying us anything compared to using the old ctype.h macros, so I'm fine with adding a check on the locale as per previous discussion. regards, tom lane ---(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] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
On HPUX 10.20, mbstowcs seems to treat all byte values as single-byte characters in C locale, so my sample-of-one says that it works everywhere ;-). Right, so for the sample SQL I sent earlier, the result would be the same as the input? That's hardly a working upper/lower If a character doesn't have case then fine, but one that does, should at least produce a warning if it cannot be converted. ... John ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
John Hansen [EMAIL PROTECTED] writes: Right, so for the sample SQL I sent earlier, the result would be the same as the input? That's hardly a working upper/lower [ shrug... ] It works per the locale definition, which is that only 7-bit-ASCII a-z/A-Z get converted. The bottom line here is that we rely on the locale setting for this behavior, and that's not likely to change real soon. If you dislike the locale definition then you should be using a different locale. In particular I think the issue here is really that your platform's definition of C locale says that bytes above x7F are illegal characters. My platform's doesn't. The thing to be changing is the locale definition. regards, tom lane ---(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] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
Magnus Hagander wrote: The installer does not permit it, but initdb lets you do anything yuo want - I think that's where we are. If you know what you're doing, you can use it by manually initdbing. There is no such thing as unicode locale. Unicode (UTF8) is an encoding, that has to be paired with a locale. I assume you mean C locale. Oh, sorry. So there is no ordering in Unicode? No wonder some languages can't use Unicode effectively. I can see why ordering is meaningless for creating a document that is just displayed but important for a database. I have added the last sentence to the TODO list: o Disallow encodings like UTF8 which PostgreSQL supports but the operating system does not (already disallowed by pginstaller) To fix UTF8, the data needs to be converted to UTF16 and then the Win32 wcscoll() can be used, and perhaps other functions like towupper(). However, UTF8 already works with normal locales but provides no ordering. While UPPER/LOWER does not matter, sort order does - for indexes if nothing else. I'm unsure if this works - I think I read reports about itn ot working, but I haven't tried it out myself. I assume C just compares the bytes, meaning equality comparisons are fine, but greater/less than is consistent but meaningless. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
To fix UTF8, the data needs to be converted to UTF16 and then the Win32 wcscoll() can be used, and perhaps other functions like towupper(). However, UTF8 already works with normal locales but provides no ordering. Right,. So if that's fixed, then UTF8 will work only on windows? (currently, upper/lower does not work with 2+ byte unicode characters, on any OS) ... John ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
K, let me rephrase: currently, upper/lower does not work with 2+ byte unicode characters, on any OS under the C locale. ... John ---(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] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
John Hansen [EMAIL PROTECTED] writes: Right,. So if that's fixed, then UTF8 will work only on windows? No. (currently, upper/lower does not work with 2+ byte unicode characters, on any OS) This information is obsolete. 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] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
currently, upper/lower does not work with 2+ byte unicode characters, on any OS under the C locale. Btw,... There are only 15 cases in the utf8 repertoire that depends on locale, these are the only cases where pg should report: ERROR: invalid multibyte character for locale HINT: The server's LC_CTYPE locale is probably incompatible with the database encoding. When doing a select upper/lower (col) All others should work just fine. The error should probably also be changed to a warning, and just return the offending character unmodified. ... John ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-hackers-win32] Repleacement for src/port/snprintf.c
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Nicolai Tufar wrote: On Mon, Feb 21, 2005 at 10:53:08PM -0500, Bruce Momjian wrote: Applied. Thanks a lot. The patch attached solves the tread safety problem. Please review it before applying, I am not sure I am doing the right thing On Tue, 22 Feb 2005 19:57:15 +0100, Kurt Roeckx [EMAIL PROTECTED] wrote: The configure test is a little broken. It needs to quote the $'s. I've rewritten the test a little. This one needs applying too. $'s do get scrambled. Best regards, Nicolai. [ Attachment, skipping... ] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 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] [pgsql-hackers-win32] Repleacement for src/port/snprintf.c
Bruce Momjian pgman@candle.pha.pa.us writes: Your patch has been added to the PostgreSQL unapplied patches list at: Didn't we do that already? regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [pgsql-hackers-win32] Repleacement for src/port/snprintf.c
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: Your patch has been added to the PostgreSQL unapplied patches list at: Didn't we do that already? This patch is for thread safety: Thanks a lot. The patch attached solves the tread safety problem. Please review it before applying, I am not sure I am doing the right thing -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
Bruce Momjian wrote: Oh, sorry. So there is no ordering in Unicode? That statement is meaningless. Unicode is a character set, not a collation order. No wonder some languages can't use Unicode effectively. That has nothing to do with it. o Disallow encodings like UTF8 which PostgreSQL supports but the operating system does not (already disallowed by pginstaller) I think the warning that initdb shouts out is already enough for this. I don't think we want to disallow this for people who know what they are doing. I assume C just compares the bytes, meaning equality comparisons are fine, but greater/less than is consistent but meaningless. That statement is independent of whether you use Unicode or something else. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
John Hansen wrote: currently, upper/lower does not work with 2+ byte unicode characters, on any OS under the C locale. Sure it does. It's just that the defined behavior of the C locale is often useless in practice. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
The installer does not permit it, but initdb lets you do anything yuo want - I think that's where we are. If you know what you're doing, you can use it by manually initdbing. There is no such thing as unicode locale. Unicode (UTF8) is an encoding, that has to be paired with a locale. I assume you mean C locale. While UPPER/LOWER does not matter, sort order does - for indexes if nothing else. I'm unsure if this works - I think I read reports about itn ot working, but I haven't tried it out myself. I was hoping for a final solution for 8.1 which actually fixes it so it works all the way. Not sure if I can make that happen myself, but I can always try unless someone else does it. //mha -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: den 22 februari 2005 04:43 To: Tatsuo Ishii Magnus, where are we on this? Seems we should allow unicode encoding and just not unicode locale in pginstaller. Also, Unicode is changing to UTF-8 in 8.1. --- Tatsuo Ishii wrote: I do understand the problem, but don't undertstand the decision you guys made. The fact that UPPER/LOWER and some other functions does not work in win32 is surely a problem for some languages, but not a problem for otheres. For example, Japanese (and probably Chinese and Korean) does not have a concept upper/lower. So the fact UPPER/LOWER does not work with UTF-8/win32 is not problem for Japanese (and for some other languages). Just using C locale with UTF-8 is enough in this case. In summary, I think you guys are going to overkill the multibyte support functionality on UTF-8/win32 because of the fact that some langauges do not work. Same thing can be said to EUC-JP, EUC-CN and EUC-KR and so on as well. I strongly object the policy to try to unconditionaly disable UTF-8 support on win32. -- Tatsuo Ishii From: Magnus Hagander [EMAIL PROTECTED] Subject: RE: [pgsql-hackers-win32] UNICODE/UTF-8 on win32 Date: Sat, 1 Jan 2005 14:48:04 +0100 Message-ID: [EMAIL PROTECTED] UNICODE/UTF-8 does not work on the win32 server. The reason is that strcoll() and friends don't work with it. To support it on win32, it needs to be converted to UTF16 and use the wide-character versions of the fucntion. Which we do not do. (See http://archives.postgresql.org/pgsql-hackers-win32/2004-11/msg00036.php and http://archives.postgresql.org/pgsql-hackers-win32/2004-12/msg0 0106.php) I don't *think* we need to disable ito n the client. AFAIK, the client interfaces don't use any of these functions, and I've seen reports of people using that long before we had a native win32 server. //Magnus -Original Message- From: Tatsuo Ishii [mailto:[EMAIL PROTECTED] Sent: den 1 januari 2005 01:10 To: [EMAIL PROTECTED] Cc: Magnus Hagander; [EMAIL PROTECTED] Subject: Re: [pgsql-hackers-win32] UNICODE/UTF-8 on win32 Sorry, but I don't subscribe to pgsql-hackers-win32 list. What's the problem here? -- Tatsuo Ishii Magnus Hagander [EMAIL PROTECTED] writes: We know it's broken and won't be fixed for 8.0. If we just #ifndef WIN32 the definitions in utils/mb/encnames.c it won't be possible to select that encoding, right? Will that have any other unwanted effects (such as breaking client encodings)? If not, I suggest this is done. I believe the subscripts in those arrays have to match the encoding enum type, so you can't just ifdef out individual entries. (Or perhaps something can be done in pg_valid_server_encoding?) Making the valid_server_encoding function reject it might work. Tatsuo-san would know for sure. Should we also reject it as a client encoding, or does that work OK? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
Magnus, where are we on this? Seems we should allow unicode encoding and just not unicode locale in pginstaller. Also, Unicode is changing to UTF-8 in 8.1. --- Tatsuo Ishii wrote: I do understand the problem, but don't undertstand the decision you guys made. The fact that UPPER/LOWER and some other functions does not work in win32 is surely a problem for some languages, but not a problem for otheres. For example, Japanese (and probably Chinese and Korean) does not have a concept upper/lower. So the fact UPPER/LOWER does not work with UTF-8/win32 is not problem for Japanese (and for some other languages). Just using C locale with UTF-8 is enough in this case. In summary, I think you guys are going to overkill the multibyte support functionality on UTF-8/win32 because of the fact that some langauges do not work. Same thing can be said to EUC-JP, EUC-CN and EUC-KR and so on as well. I strongly object the policy to try to unconditionaly disable UTF-8 support on win32. -- Tatsuo Ishii From: Magnus Hagander [EMAIL PROTECTED] Subject: RE: [pgsql-hackers-win32] UNICODE/UTF-8 on win32 Date: Sat, 1 Jan 2005 14:48:04 +0100 Message-ID: [EMAIL PROTECTED] UNICODE/UTF-8 does not work on the win32 server. The reason is that strcoll() and friends don't work with it. To support it on win32, it needs to be converted to UTF16 and use the wide-character versions of the fucntion. Which we do not do. (See http://archives.postgresql.org/pgsql-hackers-win32/2004-11/msg00036.php and http://archives.postgresql.org/pgsql-hackers-win32/2004-12/msg00106.php) I don't *think* we need to disable ito n the client. AFAIK, the client interfaces don't use any of these functions, and I've seen reports of people using that long before we had a native win32 server. //Magnus -Original Message- From: Tatsuo Ishii [mailto:[EMAIL PROTECTED] Sent: den 1 januari 2005 01:10 To: [EMAIL PROTECTED] Cc: Magnus Hagander; [EMAIL PROTECTED] Subject: Re: [pgsql-hackers-win32] UNICODE/UTF-8 on win32 Sorry, but I don't subscribe to pgsql-hackers-win32 list. What's the problem here? -- Tatsuo Ishii Magnus Hagander [EMAIL PROTECTED] writes: We know it's broken and won't be fixed for 8.0. If we just #ifndef WIN32 the definitions in utils/mb/encnames.c it won't be possible to select that encoding, right? Will that have any other unwanted effects (such as breaking client encodings)? If not, I suggest this is done. I believe the subscripts in those arrays have to match the encoding enum type, so you can't just ifdef out individual entries. (Or perhaps something can be done in pg_valid_server_encoding?) Making the valid_server_encoding function reject it might work. Tatsuo-san would know for sure. Should we also reject it as a client encoding, or does that work OK? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [pgsql-hackers-win32] Repleacement for src/port/snprintf.c
On Sun, 13 Feb 2005 19:06:34 -0500 (EST), Bruce Momjian pgman@candle.pha.pa.us wrote: Anyway, this is too large to put into 8.0, but I am attaching a patch for 8.1 that has the proper configure tests to check if the C library supports this behavior. If it does not, the build will use our port/snprintf.c. One problem with that is that our snprintf.c is not thread-safe. Seems the increases use of it will require us to fix this soon. I have added to TODO: * Make src/port/snprintf.c thread-safe Okay, I am applying your patch to CVS HEAD and getting hands on making snprintf.c thread-safe. I will submit a roll up pathch in a day or two. Regards, Nicolai ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [pgsql-hackers] Allow GRANT/REVOKE permissions to be applied
I have added this syntax to the TODO list: * Allow GRANT/REVOKE permissions to be applied to all schema objects with one command The proposed syntax is: GRANT SELECT ON ALL TABLES IN public TO phpuser; GRANT SELECT ON NEW TABLES IN public TO phpuser; --- Matthias Schmidt wrote: Hi *, I will start implementing this stuff based on this syntax: GRANT SELECT ON ALL TABLES IN public TO phpuser; GRANT SELECT ON NEW TABLES IN public TO phpuser; so there are two seperate commands to use. is everybody fine with this aproach? cheers, Matthias PS.: Tom, shouldn't we mention the fact, that one can grant on views and sequences as well in the documentation? Am 29.01.2005 um 01:43 schrieb Tom Lane: Josh Berkus josh@agliodbs.com writes: GRANT SELECT ON ALL, NEW TABLES IN public TO phpuser; ... does both. Ah, I overlooked that part of your message. I think the above probably doesn't work in bison, but if not we could spell it like GRANT SELECT ON ALL AND NEW TABLES IN public TO phpuser; Or just make the user enter two commands for this case. Aside from syntactic simplicity, that might be a good idea anyway. The NEW TABLES case is *fundamentally* different from every other form of GRANT, in that it causes future actions. So it might be a wise idea from the standpoint of understandability to keep it as a separate command from the immediate-acting ALL TABLES. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Matthias Schmidt Viehtriftstr. 49 67346 Speyer GERMANY Tel.: +49 6232 4867 Fax.: +49 6232 640089 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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
Re: [HACKERS] [pgsql-hackers-win32] Repleacement for src/port/snprintf.c
Nicolai Tufar wrote:
Hello all,
I would like to submit my changes to src/port/snprintf.c to
enable %n$ format placeholder replacement in snprintf() and
vsnprintf(). Additionally I implemented a trivial printf().
I also attach a diff for configure.in to include snprintf.o
in pgport but I am sure it is not the right thing to do.
Could someone give a hint on where I need to place such a
definition.
Please review my patch. as Tom Lane pointed out there
are 150 messages in the following files that do not print
properly:
It took me a while to understand this but I get it now. This is the
best explanation I have seen, from Linux 2.6:
One can also specify explicitly which argument is taken, at each place
where an argument is required, by writing '%m$' instead of '%' and '*m$'
instead of '*', where the decimal integer m denotes the position in the
argument list of the desired argument, indexed starting from 1. Thus,
printf(%*d, width, num);
and
printf(%2$*1$d, width, num);
are equivalent. The second style allows repeated references to the
same argument. The C99 standard does not include the style using '$',
which comes from the Single Unix Specification. If the style using '$'
is used, it must be used throughout for all conversions taking an
argument and all width and precision arguments, but it may be mixed with
'%%' formats which do not consume an argument. There may be no gaps in
the numbers of arguments specified using '$'; for example, if
arguments 1 and 3 are specified, argument 2 must also be specified
somewhere in the format string.
I can see why this would be useful for translations because it uncouples
the order of the printf arguments from the printf string. However, I
have learned that Win32, HP-UX, NetBSD 2.0, and BSD/OS do not support
this. This is probably because it is not in C99 but in SUS (see above).
Anyway, this is too large to put into 8.0, but I am attaching a patch
for 8.1 that has the proper configure tests to check if the C library
supports this behavior. If it does not, the build will use our
port/snprintf.c.
One problem with that is that our snprintf.c is not thread-safe. Seems
the increases use of it will require us to fix this soon. I have added
to TODO:
* Make src/port/snprintf.c thread-safe
One change to the original port is that there was a define of a union
with no name:
+ union{
+ void* value;
+ long_long numvalue;
+ double fvalue;
+ int charvalue;
+ };
As far as I know a union with no name is illegal. I just removed the
union { and the closing brace.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: configure
===
RCS file: /cvsroot/pgsql/configure,v
retrieving revision 1.425
diff -c -c -r1.425 configure
*** configure 18 Jan 2005 05:23:35 - 1.425
--- configure 13 Feb 2005 23:50:46 -
***
*** 12162,12167
--- 12162,12224
done
+ echo $as_me:$LINENO: checking printf supports argument control 5
+ echo $ECHO_N checking printf supports argument control... $ECHO_C 6
+ if test ${pgac_cv_printf_arg_control+set} = set; then
+ echo $ECHO_N (cached) $ECHO_C 6
+ else
+ if test $cross_compiling = yes; then
+ pgac_cv_printf_arg_control=cross
+ else
+ cat conftest.$ac_ext _ACEOF
+ #line $LINENO configure
+ #include confdefs.h
+ #include stdio.h
+
+ int does_printf_have_arg_control()
+ {
+ char buf[100];
+
+ /* can it swap arguments? */
+ snprintf(buf, 100, %2$d|%1$d, 3, 4);
+ if (strcmp(buf, 4|3) != 0)
+ return 0;
+ return 1;
+ }
+ main() {
+ exit(! does_printf_have_arg_control());
+ }
+ _ACEOF
+ rm -f conftest$ac_exeext
+ if { (eval echo $as_me:$LINENO: \$ac_link\) 5
+ (eval $ac_link) 25
+ ac_status=$?
+ echo $as_me:$LINENO: \$? = $ac_status 5
+ (exit $ac_status); } { ac_try='./conftest$ac_exeext'
+ { (eval echo $as_me:$LINENO: \$ac_try\) 5
+ (eval $ac_try) 25
+ ac_status=$?
+ echo $as_me:$LINENO: \$? = $ac_status 5
+ (exit $ac_status); }; }; then
+ pgac_cv_printf_arg_control=yes
+ else
+ echo $as_me: program exited with status $ac_status 5
+ echo $as_me: failed program was: 5
+ cat conftest.$ac_ext 5
+ ( exit $ac_status )
+ pgac_cv_printf_arg_control=no
+ fi
+ rm -f core core.* *.core conftest$ac_exeext conftest.$ac_objext
conftest.$ac_ext
+ fi
+
+ fi
+ echo $as_me:$LINENO: result: $pgac_cv_printf_arg_control 5
+ echo ${ECHO_T}$pgac_cv_printf_arg_control
Re: [HACKERS] [pgsql-hackers] Patent issues and 8.1
Guys, BTW, if you hadn't guessed, that comment was supposed to be off-list. Unfortunately, I discovered a bug with KMail and list management, the hard way ... Sigh.Just in case anyone wants to know, KMail 1.5.1 + has a bug where, if you have list management turned on, it sometimes sends stuff to the list instead of the To: line you see on the screen. Dammit! Any other Linux-friendly mail GUIs that have list management features and don't have this problem? -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-hackers] Patent issues and 8.1
Andrew, On Thu, Jan 27, 2005 at 10:39:52AM -0800, Josh Berkus wrote: Thanks. As you know, I'm getting a little sick of the chicken little act among many of the -hackers I think this is a little bit of a mischaracterisation. Afilias is already a customer of IBM. BTW, if you hadn't guessed, that comment was supposed to be off-list. Unfortunately, I discovered a bug with KMail and list management, the hard way ... And to be perfectly frank, I was mostly thinking of Marc when I said that. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-hackers] Patent issues and 8.1
Marc, And to be perfectly frank, I was mostly thinking of Marc when I said that. Sorry, that was uncharitable. I meant that (at the time) you were panicking. Now you have something different to panic about. How goes the server shuffle? -- Josh Berkus Aglio Database Solutions San Francisco ---(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] [pgsql-hackers] Patent issues and 8.1
Josh Berkus wrote: Guys, BTW, if you hadn't guessed, that comment was supposed to be off-list. Unfortunately, I discovered a bug with KMail and list management, the hard way ... Sigh.Just in case anyone wants to know, KMail 1.5.1 + has a bug where, if you have list management turned on, it sometimes sends stuff to the list instead of the To: line you see on the screen. Dammit! Any other Linux-friendly mail GUIs that have list management features and don't have this problem? Evolution does although I haven't tried it in a while. J -- Command Prompt, Inc., your source for PostgreSQL replication, professional support, programming, managed services, shared and dedicated hosting. Home of the Open Source Projects plPHP, plPerlNG, pgManage, and pgPHPtoolkit. Contact us now at: +1-503-667-4564 - http://www.commandprompt.com begin:vcard fn:Joshua D. Drake n:Drake;Joshua D. org:Command Prompt, Inc. adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl. x-mozilla-html:FALSE url:http://www.commandprompt.com/ version:2.1 end:vcard ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [pgsql-hackers] Allow GRANT/REVOKE permissions to be applied to all schema
Hi *, I will start implementing this stuff based on this syntax: GRANT SELECT ON ALL TABLES IN public TO phpuser; GRANT SELECT ON NEW TABLES IN public TO phpuser; so there are two seperate commands to use. is everybody fine with this aproach? cheers, Matthias PS.: Tom, shouldn't we mention the fact, that one can grant on views and sequences as well in the documentation? Am 29.01.2005 um 01:43 schrieb Tom Lane: Josh Berkus josh@agliodbs.com writes: GRANT SELECT ON ALL, NEW TABLES IN public TO phpuser; ... does both. Ah, I overlooked that part of your message. I think the above probably doesn't work in bison, but if not we could spell it like GRANT SELECT ON ALL AND NEW TABLES IN public TO phpuser; Or just make the user enter two commands for this case. Aside from syntactic simplicity, that might be a good idea anyway. The NEW TABLES case is *fundamentally* different from every other form of GRANT, in that it causes future actions. So it might be a wise idea from the standpoint of understandability to keep it as a separate command from the immediate-acting ALL TABLES. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Matthias Schmidt Viehtriftstr. 49 67346 Speyer GERMANY Tel.: +49 6232 4867 Fax.: +49 6232 640089 ---(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] [pgsql-hackers] Patent issues and 8.1
On Mon, 31 Jan 2005, Josh Berkus wrote: Now you have something different to panic about. How goes the server shuffle? alot smoother today then it went yesterday ... and faster ... but, then again, *most* clients use 256MB of storage, so moving their VM around takes no time ... svr1 is @ ~13G :) Something like 3G is justin's mailbox alone ... and i miscalculated how long it would take to move it back over to neptune :( Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-hackers] Patent issues and 8.1
On Mon, 31 Jan 2005, Josh Berkus wrote: Marc, And to be perfectly frank, I was mostly thinking of Marc when I said that. Sorry, that was uncharitable. I meant that (at the time) you were panicking. Wait, I've not panic'd about all of this at any point ... the only 'chicken little' comment I made had to do with everyone panicking about a patent that doesn't yet exist, and comparing that to chicken little and his 'the sky is falling' ... *scratch head* Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] [pgsql-hackers] Patent issues and 8.1
Marc, alot smoother today then it went yesterday ... and faster ... but, then again, *most* clients use 256MB of storage, so moving their VM around takes no time ... svr1 is @ ~13G :) Something like 3G is justin's mailbox alone ... and i miscalculated how long it would take to move it back over to neptune :( I doubt that's intentional, why don't you ask him to truncate it? I noticed that you used to grant @postgresql.org addresses as unlimited, I changed the default to 5MB, which is what all the regional contacts now have. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-hackers] Allow GRANT/REVOKE permissions to be applied to all schema
* Tom Lane ([EMAIL PROTECTED]) wrote: Or just make the user enter two commands for this case. Aside from syntactic simplicity, that might be a good idea anyway. The NEW TABLES case is *fundamentally* different from every other form of GRANT, in that it causes future actions. So it might be a wise idea from the standpoint of understandability to keep it as a separate command from the immediate-acting ALL TABLES. I agree with this- issueing two seperate commands in this instance seems like it'd be fine and not terribly onerous. Stephen signature.asc Description: Digital signature
Re: [HACKERS] [pgsql-hackers] Patent issues and 8.1
On Friday 28 January 2005 12:36, Josh Berkus wrote:
Robert,
Read the law... willful vs. unknown infringement are two different
things.
We're not infringing anything, yet. That's a *pending* patent.
*sigh* Thats understood. But you were using the counter-argument that we
might be infringing on patents we know nothing about now so why treat this
one any different. I'm pointing out this one would be different because we
know about it and the law treats these things seperatly.
Um... thats the way our legal system works. You could do that to any
project if you had a patent they were infringing upon no matter how
stoic they tried to be about it. (By our I mean the U.S. system)
You're not following me. Imagine this:
1) Pervasive/Fujistsu/SRA/Mammoth PostgreSQL steals some big clients from
Obsolete Proprietary Database Company (OPDC).
2) OPDC has someone dig through their piles of patents and finds something
that looks like it might infringe on something PostgreSQL does.
3) OPDC gets a blogger or similar to post something And in the latest
patent infringment news ...
4) -Hackers hears about it and we derail development for another 3 months
in order to work around the patent.
Net Cost to OPDC: couple $thousand, to delay a PG release by 3+ months.
What's kept patent litigation from being used against OSS projects so far
is the bad PR that would attach, the potential cost of litigation, the
possibility of having the patent invalidated, and the dubvious prospect of
compensation. But if a competitor can disrupt an OSS project with a
*threatened* patent, then the cost is minimal and the effect is huge.
We will face this situation again -- at least, until software patents go
away -- and both I and Bruce feel that it's important to set a precedent in
dealing with them because you can bet this discussion is being read by
people who are not in favor of the spread of PostgreSQL.This isn't just
about the ARC patent, it's about the next one after that.
I guess I don't understand your rational here? You want to set a precendent
that the PGDG only responds to lawsuits? Seems we should be willing to
address anyones patent concerns in a resonable manner... but that will
depend on the size of the changes needed and what point in the development
cycle we are. This is a good size change and it comes at a time in the dev
cycle when we have all our options open (it would be different if we were 4
months in with all kinds of new things already added) and it's a feature that
*we all want to change anyway* so why not be agressive about it?
FWIW I've really only been advocating
BTW, my last post wasn't specifically addressed at you, but at the
viewpoint that we should drop everything and work on the ARC replacement to
get it out the door in 4 months.
that we don't do the change in a
patch branch, which I'm afraid the do nothing till the lawyers show up
plan would eventually lead to. We wouldn't normally do things that way
on technical grounds, so I'd prefer not to be forced into doing things
that way for other reasons; enough so that I think we ought to have a
plan to address it now.
It's not a choice between doing something and doing nothing; you're
mischaracterizing. It's a choice between:
1) Shall we begin development immediately on an 8.1 which does not include
the ARC code and can be upgraded without initdb, for plans to release this
version in 4 months or less?
2) Shall we work our regular 1-year development cycle, with plans to
replace ARC with an improved memory management approach as part of the
features of 8.1, keeping a reversion-to-LRU patch in reserve in case we
have to release it as a patch in the 8.0.x series?
I advocate (2), partly because I don't believe that (1) is really possible
for us. When's the last time we did a fast release? What I do advocate
doing *now* is:
I'm not mischarecterizing, I just feel that putting out an lru based 8.0.x
release is such a bad idea that I'd rather do (1) than gamble on (2).
Honestly I don't think anything will ever come of this, but if things go
spectacularly bad, the fewer arc-based releases out there the better. Not
to mention that the only downside I have seen to (1) is that people think it
will disrupt development too much but I don't buy that. We can branch 8.1
and 8.2 now, with 2month dev planned for 8.1 and a 12 month dev for 8.2 and
go about things. This would also have the advantage of pushing out a lot of
loose ends a bit sooner (do we really want to wait a year for things like
typo friendly psql?) as people get more understanding of the new features
made in 8.0.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] [pgsql-hackers] Patent issues and 8.1
Robert Treat [EMAIL PROTECTED] writes: I'm not mischarecterizing, I just feel that putting out an lru based 8.0.x release is such a bad idea that I'd rather do (1) than gamble on (2). I don't understand why you think it's such a bad idea. We do have the problem of getting adequate testing, but I think the answer to that is to put the same patch into HEAD as well. We can branch 8.1 and 8.2 now, with 2month dev planned for 8.1 and a 12 month dev for 8.2 and go about things. I will resist that idea strongly. We have no experience as a community with managing multiple active development branches, and I feel certain that we'd mess it up (eg, commit things into the wrong branch, or fail to commit things into both branches that need to be in both). Case in point: Teodor has already, without discussion, committed 8.1 changes in tsearch2 that should force an initdb. If we were taking the idea of a backward-compatible 8.1 seriously we'd have to make him back that out of 8.1. I can't see trying to ride herd on all the committers to make sure no one unintentionally breaks file-level compatibility over a whole dev cycle, even a short one. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [pgsql-hackers] Patent issues and 8.1
On Saturday 29 January 2005 11:33, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
I'm not mischarecterizing, I just feel that putting out an lru based
8.0.x release is such a bad idea that I'd rather do (1) than gamble on
(2).
I don't understand why you think it's such a bad idea. We do have the
problem of getting adequate testing, but I think the answer to that
is to put the same patch into HEAD as well.
The combination of inadequate testing, making support more difficult, and
general all around confusion that beta/rc's for a revision level release are
sure to cause. Not to mention that if the patent ever does materialize into a
problem, the scope of that problem will be that much greater the longer we
wait.
We can branch 8.1 and 8.2 now, with 2month dev planned for 8.1 and a
12 month dev for 8.2 and go about things.
I will resist that idea strongly. We have no experience as a community
with managing multiple active development branches, and I feel certain
that we'd mess it up (eg, commit things into the wrong branch, or fail
to commit things into both branches that need to be in both). Case in
point: Teodor has already, without discussion, committed 8.1 changes in
tsearch2 that should force an initdb. If we were taking the idea of a
backward-compatible 8.1 seriously we'd have to make him back that out of
8.1.
I think this is a false case since right now we are hanging in limbo, with
people unsure of what is proper to commit into what branch. If there had
been an official announcement that no initdb level changes were to go into
8.1 I think we'd be ok.
I can't see trying to ride herd on all the committers to make sure
no one unintentionally breaks file-level compatibility over a whole dev
cycle, even a short one.
I think the key is to put someone in charge of either 8.1 or 8.2 and let them
be the primary gatekeeper for that release. It can work either way... people
develop against 8.1 and we have an 8.2 gatekeeper(s) responsible for patching
forward any new commits into 8.2 and handling file-level incompatible feature
commits. Conversly we can have folks develop against 8.2 and have someone in
charge of backpatching any non file-level incompatible changes backwards and
the ARC changes.
There are other upsides to this as well. If we could do this now it would
help move us to the ability to keep feature development going year round.
Rather than having to stop 4-5 months every year to do beta we could create a
new branch during beta and let people continue on with that... we already had
some rumblings of that idea during the 8.0 beta cycle, this would give us a
good test run.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-hackers] Allow GRANT/REVOKE permissions to be applied to all schema
On Saturday 29 January 2005 09:14, Stephen Frost wrote:
* Tom Lane ([EMAIL PROTECTED]) wrote:
Or just make the user enter two commands for this case. Aside from
syntactic simplicity, that might be a good idea anyway. The NEW TABLES
case is *fundamentally* different from every other form of GRANT, in
that it causes future actions. So it might be a wise idea from the
standpoint of understandability to keep it as a separate command from
the immediate-acting ALL TABLES.
I agree with this- issueing two seperate commands in this instance seems
like it'd be fine and not terribly onerous.
In general I'd agree, although as I start to think of the different
combinations of tables/views/functions/sequences/types/operators/etc.. my
head does start to spin.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-hackers] Patent issues and 8.1
On Thu, 2005-01-27 at 12:51, Josh Berkus wrote:
We don't *have* to do anything when the patent is granted. When we *have*
to
do something is when IBM sends a cease-and-desist letter to a PostgreSQL
user. Not before.
With that attitude we don't have to do anything even then. We have a
good number of users that this patent claim will be unenforceable
on...right? We have the option of dealing with this now on our own
terms... if we gamble and lose we may have to deal with it in less
favorable conditions.
Now, if one of our commercial supporting companies is worried enough about
this to do something -- such as funding a hacker for a 3-month intensive
better-than-ARC development stint -- then let them step up to the plate.
Many of our programmers are happy to accept commercial development dollars
for what is a commercial concern. Let's not steer development based on
protecting what we think is protecting our commercial sponsors, when they
haven't even asked us!
I'm not sure if your glossing over this on purpose or your just unaware,
but it is not just commercial support companies that will be getting
those letters if IBM ever heads that route. (I'd agree that I don't
think they will, but let's not kid ourselves if they do)
Like *any* other piece of major software, we probably infringe on 50
different
patents which we don't know about, held by a variety of parties.
Read the law... willful vs. unknown infringement are two different
things.
If we let
this one *potential* patent panic us into a response we may regret later --
such as derailing 8.1 development, or releasing an insufficiently tested new
version -- then some other company will threaten us with patents with
malicious intent to watch us jump and scramble again.
Um... thats the way our legal system works. You could do that to any
project if you had a patent they were infringing upon no matter how
stoic they tried to be about it. (By our I mean the U.S. system)
Attorneys have already said that Linux infringes several dozen outstanding
patents. Do you see Linus suddenly overhauling the kernel? Dropping
everthing and rushing a non-infringing, under-tested 2.8 to release? No, you
don't.
Well, I suppose if we had someone's who job was supported by dozens of
multi-billion dollar corporations who all had patent portfolio's that
totaled into the thousands we'd probably have more legs to stand on, but
we don't so the WWLD plan may not be best for us.
FWIW I've really only been advocating that we don't do the change in a
patch branch, which I'm afraid the do nothing till the lawyers show up
plan would eventually lead to. We wouldn't normally do things that way
on technical grounds, so I'd prefer not to be forced into doing things
that way for other reasons; enough so that I think we ought to have a
plan to address it now.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-hackers] Allow GRANT/REVOKE permissions to be applied to all schema
Josh Berkus josh@agliodbs.com writes: Can't say I like either. I'd prefer: GRANT [PERM] ON ALL TABLES IN SCHEMA [schemaname] TO [user]; I agree that this syntax seems more SQL-ish than relying on a wildcard. GRANT SELECT, UPDATE, INSERT ON TABLES IN SCHEMA public TO php-user; .. would set the defaults for any NEW tables created in public, and this command: GRANT SELECT, UPDATE, INSERT ON TABLES IN SCHEMA public TO php-user CASCADE; ... would grant for existing tables as well. This however seems a rather whimsical reinvention of the meaning of CASCADE. I'm not sure if we really need to support both immediate and delayed inheritance of privileges from a schema, but if we do, let's please use some other keyword than CASCADE to distinguish the cases. Also it'd probably be better if they were independent commands, rather than one subsuming the other as you suggest. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-hackers] Allow GRANT/REVOKE permissions to be applied to all schema
Tom, This however seems a rather whimsical reinvention of the meaning of CASCADE. I'm not sure if we really need to support both immediate and delayed inheritance of privileges from a schema, but if we do, let's please use some other keyword than CASCADE to distinguish the cases. Also it'd probably be better if they were independent commands, rather than one subsuming the other as you suggest. Hmm, what about using, ALL and NEW? i.e. GRANT SELECT ON NEW TABLES IN public TO phpuser; GRANT SELECT ON ALL TABLES IN public TO phpuser; The first sets defaults for new objects, the second sets permissions on existing tables, and this: GRANT SELECT ON ALL, NEW TABLES IN public TO phpuser; ... does both. Of course, this assumes that tables named new or all are not possible ... are those reserved? -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(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] [pgsql-hackers] Allow GRANT/REVOKE permissions to be applied to all schema
Josh Berkus josh@agliodbs.com writes: Hmm, what about using, ALL and NEW? i.e. GRANT SELECT ON NEW TABLES IN public TO phpuser; GRANT SELECT ON ALL TABLES IN public TO phpuser; That seems good to me. More generally it would be GRANT perm [,...] ON NEW/ALL TABLES IN schema [,...] TO user [,...] which leaves us the freedom to later add GRANT perm [,...] ON NEW/ALL FUNCTIONS IN schema [,...] TO user [,...] and so on. Of course, this assumes that tables named new or all are not possible ... are those reserved? As long as you aren't allowed to omit the word TABLES, I think we can do this without making ALL or NEW any more reserved than they are already. I haven't actually tried it in bison though. TABLES (and later FUNCTIONS, etc) isn't a keyword at all right now IIRC, but as long as we can do this without making it reserved, I think that's not a big objection. 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] [pgsql-hackers] Allow GRANT/REVOKE permissions to be applied to all schema
Josh Berkus josh@agliodbs.com writes: GRANT SELECT ON ALL, NEW TABLES IN public TO phpuser; ... does both. Ah, I overlooked that part of your message. I think the above probably doesn't work in bison, but if not we could spell it like GRANT SELECT ON ALL AND NEW TABLES IN public TO phpuser; Or just make the user enter two commands for this case. Aside from syntactic simplicity, that might be a good idea anyway. The NEW TABLES case is *fundamentally* different from every other form of GRANT, in that it causes future actions. So it might be a wise idea from the standpoint of understandability to keep it as a separate command from the immediate-acting ALL TABLES. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [pgsql-hackers] Patent issues and 8.1
Marc, Tom, Robert, Bruce, et al: Bruce is advocating waiting until the Patent has been Granted, instead of doing something about it now, when we know the patent is going through the system (and will likely get granted) ... a reactive vs proactive response to the problem. No, we're reactive regardless. Proactive would have been to investigate the ARC paper when it was published for outstanding patent applications, and again before feature freeze. Or even to have considered the fact that when an IBM person publishes a paper on new technology, IBM probably has a patent on it ... they're the largest patent-holder in the world, after all. It's a little late for that, and would probably not even have been a good idea, lest we let legal concerns paralyze development. Basically, after the patent is granted, we are going to scramble to get rid of the ARC stuff, instead of taking the time leadign up to the granting to get rid of it so that when granted, it isn't something we have to concern ourselves with ... We don't *have* to do anything when the patent is granted. When we *have* to do something is when IBM sends a cease-and-desist letter to a PostgreSQL user. Not before. Tangentally, but relevant: a few years ago I was facing a potential lawsuit from a customer who had changed management and was suing all their former vendors as a path out of bankruptcy. Never having been sued before, I was inclined to panic. I called a classmate of mine who was a litigation attorney, and retained his services, and asked what I should do. First off, don't panic, he said. Have you been served yet? um, no Then don't worry about it. You may not be served. If you are served, you are likely to be able to get this dismissed. The last thing you want to do is panic and try to bargain with them now; they'll see that you're a softie and go on the attack. You've retained me, that's all you need to do now. (as it turned out, I was never served) Take a look again at the posting by Nicholai -- someone with professional experience in patents. Last I checked, nobody else on this list is a patent attorney, clerk, or IP litigation professional. 1) The patent may not be granted for another year. 2) The patent may never be granted. 3) When/if the patent is granted, its terms may have changed and we may no longer be infringing, *IF* we are now, which I have yet to see an *attorney's* opinion on. 4) IBM may put this patent in its set of GPL patents, since we are not the only OSS project using ARC. This would be a licensing headache for some of our users, but not a catastrophe. 5) Even if IBM does not OSS this patent, they may choose not to enforce it against us or other OSS projects since it would mean massively bad PR for them. Given that we're planning on replacing/overhauling ARC anyway, I really don't see that we need to do more at this time. Except maybe keep Neil's LRU-reversion patch somewhere handy in case we need it, and build a variant version and run it through tests at OSDL to see what it breaks (it would be good to do this anyway to see what, if anything, ARC is gaining us in terms of performance). Now, if one of our commercial supporting companies is worried enough about this to do something -- such as funding a hacker for a 3-month intensive better-than-ARC development stint -- then let them step up to the plate. Many of our programmers are happy to accept commercial development dollars for what is a commercial concern. Let's not steer development based on protecting what we think is protecting our commercial sponsors, when they haven't even asked us! Heck, the idea of a pluggable memory manager tickles my funny bone, even though I don't think such a thing is possible. Like *any* other piece of major software, we probably infringe on 50 different patents which we don't know about, held by a variety of parties. If we let this one *potential* patent panic us into a response we may regret later -- such as derailing 8.1 development, or releasing an insufficiently tested new version -- then some other company will threaten us with patents with malicious intent to watch us jump and scramble again. Attorneys have already said that Linux infringes several dozen outstanding patents. Do you see Linus suddenly overhauling the kernel? Dropping everthing and rushing a non-infringing, under-tested 2.8 to release? No, you don't. -- Josh Berkus Aglio Database Solutions San Francisco ---(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] [pgsql-hackers] Patent issues and 8.1
Josh, Bruce is advocating waiting until the Patent has been Granted, instead of doing something about it now, when we know the patent is going through the system (and will likely get granted) ... a reactive vs proactive response to the problem. Very well written Josh. Thanks. As you know, I'm getting a little sick of the chicken little act among many of the -hackers --Josh -- __Aglio Database Solutions___ Josh BerkusConsultant josh@agliodbs.comwww.agliodbs.com Ph: 415-752-2500Fax: 415-752-2387 2166 Hayes Suite 200San Francisco, CA ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-hackers] Re: Extending System Views: proposal for 8.1/8.2
Troels, Others, Generally: Nice. But have you considered if the INFORMATION_SCHEMA could be used? Unfortunately, the INFORMATION_SCHEMA currently has a major problem in its usefulness in PostgreSQL: http://troels.arvin.dk/db/rdbms/#cli-list_of_tables-postgresql-gotchas Actually, I did. However, the format and columns of INFORMATION_SCHEMA are defined by the SQL Standard, which will not cover a lot of PostgreSQL objects (such as custom types or operators) and covers a lot of others in rather awkward form. For that matter, your own editorial points out that we should really be UPPERCASEing all of the object names in information_schema, which would be SQL-spec but not generally useful. This reminds me: It would be nice if it were somehow possible to determine when (if ever) statistics have been gathered for a given schema object. This needs changes to more than VIEWs, though. Well, you can always query pg_stats. Do you propose that typemodifiers be one column? - If would prefer if it were several columns. And it would be useful if it were easy to determine if a column is - solely - or part of - a uniqueness constraint - solely - or part of - a foreign key (pointing where?) - if it is subject to a (set of) CHECK constraints Yeah, I gave this some thought. The problem as I see it is that in the future we may have additional types of typemodifiers which aren't covered, and I don't want to get in the habit of adding more and more columns to the view. However, that's not really an excuse; it might be better to: pg_columns -- new view schemaname tablename columnname datatype notnull references (name which links pg_foreignkeys, or boolean?) default constraints (array, references pg_constraints) othermodifiers (string of other column modifiers, for when such exist) comment In a way, though, it might be better for references to be a boolean column, and users can query pg_foriegnkeys to find the exact reference. BTW, People, I really don't see the point in prodiving a dual list -- that is, a list of OIDs in addition to the list of names provided in the columns of each view. The idea of these views is to keep the users *away* from technical details like OIDs, which can and will change with the advancing versions of PostgreSQL. -- Josh Berkus Aglio Database Solutions San Francisco ---(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] [pgsql-hackers] Re: Extending System Views: proposal for 8.1/8.2
On Sun, Jan 23, 2005 at 12:43:15PM -0800, Josh Berkus wrote: BTW, People, I really don't see the point in prodiving a dual list -- that is, a list of OIDs in addition to the list of names provided in the columns of each view. The idea of these views is to keep the users *away* from technical details like OIDs, which can and will change with the advancing versions of PostgreSQL. It's a question of if these views will also be used programatically. ISTM that OIDs are the preffered method of refering to things in code (in fact, aren't there some functions that only take OIDs?). If we want to make names the cannonical way to reference things in code, then I agree that there's not much use to OIDs. Is the long term plan to remove OIDs entirely? -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [pgsql-hackers] Re: Extending System Views: proposal for 8.1/8.2
Jim C. Nasby [EMAIL PROTECTED] writes: Is the long term plan to remove OIDs entirely? No. OIDs will be the real primary keys of most system catalogs for the foreseeable future. The only discussion that's going on concerns deprecating their use in user tables. 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] [pgsql-hackers] Re: Extending System Views: proposal for 8.1/8.2
Jim, It's a question of if these views will also be used programatically. ISTM that OIDs are the preffered method of refering to things in code (in fact, aren't there some functions that only take OIDs?). If we want to make names the cannonical way to reference things in code, then I agree that there's not much use to OIDs. Hmmm I think that you and I have different ideas about the purpose of the system views. My idea is to provide a stable (through multiple versions of pg), human-readable view of the system objects. You obviously want to do more -- I'd like details on what that more is, so that we can talk about it. Is the long term plan to remove OIDs entirely? No, but we want to discourage users from using them actively. Where they're apparent, users will be inclined to write code that references OIDs *by number* which will survive neither backup/restore, nor upgrades in pg versions. So where we can encourage users to refer to objects by name, we should. I see the OIDs, in fact, as one of the reasons to create the additional system views -- so that users aren't confused by them. If there are functions that need OIDs, my inclination would be to write shell functions for those that accept fully-qualified object names. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-hackers] Re: Extending System Views: proposal for 8.1/8.2
On Sun, Jan 23, 2005 at 02:37:28PM -0800, Josh Berkus wrote: Jim, It's a question of if these views will also be used programatically. ISTM that OIDs are the preffered method of refering to things in code (in fact, aren't there some functions that only take OIDs?). If we want to make names the cannonical way to reference things in code, then I agree that there's not much use to OIDs. Hmmm I think that you and I have different ideas about the purpose of the system views. My idea is to provide a stable (through multiple versions of pg), human-readable view of the system objects. You obviously want to do more -- I'd like details on what that more is, so that we can talk about it. Really, my only goal is to make using the system views/tables programatically easier by coming up with a better naming convention. This isn't directly related to the human-readable stuff, other than fields that would be common between both sets of views. Perhaps a good way to accomplish both goals is to have the set of human-readable views, and to add columns to the system tables/views that conform with the new, more logical naming convention. This way people accessing system information programmatically can use pg_catalog (and migrate to the new naming convention), while people who are doing ad-hoc queries can just hit the human-readable stuff. Make sense? -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(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] [pgsql-hackers] Re: Extending System Views: proposal for 8.1/8.2
Jim, Perhaps a good way to accomplish both goals is to have the set of human-readable views, and to add columns to the system tables/views that conform with the new, more logical naming convention. This way people accessing system information programmatically can use pg_catalog (and migrate to the new naming convention), while people who are doing ad-hoc queries can just hit the human-readable stuff. If you think that anyone on this list is going to let us re-name columns in the system *tables*, you're on more pain meds than I realized ... And in what way is using fully qualified names programmatically a problem? -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-hackers] Re: Extending System Views: proposal for 8.1/8.2
On Sun, Jan 23, 2005 at 02:53:11PM -0800, Josh Berkus wrote: Jim, Perhaps a good way to accomplish both goals is to have the set of human-readable views, and to add columns to the system tables/views that conform with the new, more logical naming convention. This way people accessing system information programmatically can use pg_catalog (and migrate to the new naming convention), while people who are doing ad-hoc queries can just hit the human-readable stuff. If you think that anyone on this list is going to let us re-name columns in the system *tables*, you're on more pain meds than I realized ... What I figured. And in what way is using fully qualified names programmatically a problem? It's not a problem; my only complaint is that the field names are awkward as hell, which is why I suggested a new naming convention. If it comes down to it, I'll settle for better names in the human readable stuff and hope it eventually can be migrated to pg_catalog stuff. I just figured changing both at the same time might make more sense. -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(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] [pgsql-hackers] Re: Translations at pgfoundry
Peter, Euler, others: OK, is anyone opposed to this idea? I would register a pgfoundry project (name suggestions? translations?), give most established translators commit access, and move the statistics pages there. BTW, there is already a translators mailing list. While I've been using it for the press releases, there's no reason why the translators can use it for all translations. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [pgsql-hackers] Re: Translations at pgfoundry
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Fri, 21 Jan 2005, Josh Berkus wrote: OK, is anyone opposed to this idea? I would register a pgfoundry project (name suggestions? translations?), give most established translators commit access, and move the statistics pages there. BTW, there is already a translators mailing list. While I've been using it for the press releases, there's no reason why the translators can use it for all translations. Are all regional contacts are also the translators of .po files? Translating a press release is somewhat a non-technical issue; but the .po translators have to know PostgreSQL internals, I think... So, translators ml should be limited to the press release translators as it is now; and we need to create a new ml for the .po translators. Just my 0.02 ... Regards, - -- Devrim GUNDUZ devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.tdmsoft.com http://www.gunduz.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFB8Ymdtl86P3SPfQ4RAp4zAJ918KcctE/c90xlA99/cI63wBn04gCdF5RQ ooljgkP59MdcRSrr98AjBzE= =QgSX -END PGP SIGNATURE- ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-hackers] Daily digest v1.4918 (23 messages)
On Mon, 2005-01-17 at 18:43 -0500, Tom Lane wrote: I have already suggested to core that we should insist on 8.1 not requiring an initdb, so as to ensure that people will migrate up to it easily from 8.0. So is it firm policy that changes that require a catversion update cannot be made during the 8.1 cycle? Not yet --- I suggested it but didn't get any yeas or nays. I don't feel this is solely core's decision anyway ... what do the assembled hackers think? (Needless to say, it would be good to get this sorted out early on in the 8.1 development cycle, to avoid the need to revert patches at some point down the line. For those of us working on large projects that will definitely require an initdb, it would also be good to know -- as this policy will likely prevent that work from getting into 8.1) Yes, it has to be decided one way or the other soon. One way to have our cake and eat it too would be for someone to resurrect pg_upgrade during this devel cycle. Anyone feel like working on that? Yup. I feel like working on that and not just feel as I been noising about it in the recent past. In fact I have opend a pgfoundry project for that exact work. regards, tom lane -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-hackers-win32] %2$, %1$ gettext placeholder replacement is not working under Win32
Nicolai Tufar [EMAIL PROTECTED] writes: Sorry for such a late submission. I just downloaded the latest postgresql-8.0.0-rc5-3.zip installer for windows and it appears that Windows' printf() does not support placeholder replacement as described in http://developer.postgresql.org/docs/postgres/nls.html#AEN57284 Original string is %s at or near \%s\ and we replaced it in Turkish for \%2$s\ yerinde %1$s. Hmm. Looking around, it seems that %n$ support is required by the Single Unix Spec: http://www.opengroup.org/onlinepubs/007908799/xsh/fprintf.html but it is *not* required by C99 as far as I can tell. I don't see any mention of support for it in my HPUX fprintf man page, either. So this construct may not be as portable as we could wish. There appear to be about 150 affected messages, in these files: src/backend/po/pt_BR.po src/backend/po/de.po src/backend/po/es.po src/backend/po/zh_CN.po src/backend/po/tr.po src/bin/pg_dump/po/zh_CN.po src/bin/pg_dump/po/tr.po src/bin/psql/po/zh_CN.po src/bin/psql/po/zh_TW.po src/bin/psql/po/tr.po src/bin/scripts/po/zh_CN.po I don't think we'll hold up release to fix this, but the affected translators may want to think about whether they can avoid the problem or not. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-hackers-win32] %2$, %1$ gettext placeholder replacement is not working under Win32
I wrote: I don't think we'll hold up release to fix this, but the affected translators may want to think about whether they can avoid the problem or not. Also, it looks like src/port/snprintf.c is not %n$ capable either. I'm not sure which platforms that affects. A possible route to a solution is to upgrade snprintf.c and then use it on platforms that don't have this support. This only fixes those cases where we go through snprintf, which is probably not all of the affected messages, but it might be enough. It's not happening for 8.0.0 though. 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] [pgsql-hackers-win32] %2$, %1$ gettext placeholder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Mon, 17 Jan 2005, Tom Lane wrote: snip I don't think we'll hold up release to fix this, :-) It seems nothing seems to stop you from holding up this release anymore: Neither ARC problem nor this one :) Regards, - -- Devrim GUNDUZ devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.tdmsoft.com http://www.gunduz.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFB7B0Ktl86P3SPfQ4RAqCFAJ9YLdaUP8ALAetKHQcpPxHfrlcXcQCgpKmX gKsYQYdu8nh4rGQOo2DQl3c= =g6q/ -END PGP SIGNATURE- ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [pgsql-hackers-win32] %2$, %1$ gettext placeholder replacement is not working under Win32
I don't think we'll hold up release to fix this, but the affected translators may want to think about whether they can avoid the problem or not. Also, it looks like src/port/snprintf.c is not %n$ capable either. I'm not sure which platforms that affects. A possible route to a solution is to upgrade snprintf.c and then use it on platforms that don't have this support. This only fixes those cases where we go through snprintf, which is probably not all of the affected messages, but it might be enough. It's not happening for 8.0.0 though. Might want to track down which platforms are affected by the file in port/, and then add win32 to it, and put it up somewhere on a list of known issues in 8.0? //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] [pgsql-hackers-win32] %2$, %1$ gettext placeholder replacement is not working under Win32
On Mon, 17 Jan 2005 14:54:44 -0500, Tom Lane [EMAIL PROTECTED] wrote: Also, it looks like src/port/snprintf.c is not %n$ capable either. I'm not sure which platforms that affects. A possible route to a solution is to upgrade snprintf.c and then use it on platforms that don't have this support. This only fixes those cases where we go through snprintf, which is probably not all of the affected messages, but it might be enough. It's not happening for 8.0.0 though. Bad news for the Turks. Turkish language syntax is lake Latin: the verb is always at the end. Because of that almost all messages that have two or more placeholders are broken under Windows. The solution you propose seem to be a trivial exercise: 1. write a replacement function, say, pg_snprintf() that would shuffle input arguments, replace %x$ with % and then call libc's snprintf(); 2. replace snprintf() in all source files with pg_snprintf(); 3. Update Makefiles to use our custom function on broken platforms or default to snprinf(). (Or maybe pg_snprintf() should be a #define); 4. Tell everyone to use pg_snprintf() instead of snprintf() from now on. I would like volunteer to implement this for 8.1 and would be honoured if I get a chance to contribute. regards, tom lane Best regards, Nicolai Tufar ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-hackers-win32] [BUGS] More SSL questions..
Bruce Momjian wrote: FWIW, I've seen several apps that use .txt for config files, but I can't think of an example right now. Most don't though - .cfg or .conf is probably most common. Except for the majority of windows programs that don't use config files - they use the registry. But I see no reason *at all* for us to want to do that :-) It also more or less requires you to write a GUI to change the config stuff and in that case the file extension becomes irrelevant. Where are we on this? I think Andrew and I both think *.txt is confusing. We need to decide on Monday if we should change the current *.txt names. We can either leave it unchanged, remove *.txt, or change it to *.config. APPDATA/postgresql/pgpass.txt APPDATA/postgresql/psqlrc.txt Another idea is to use *.conf. For what it's worth, I always thought that text configuration files on Windows platforms generally used the '.ini' extension. I believe on most Windows systems that extension is by default associated with Notepad. -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [pgsql-hackers-win32] [BUGS] More SSL questions..
Where are we on this? I think Andrew and I both think *.txt is confusing. We need to decide on Monday if we should change the current *.txt names. We can either leave it unchanged, remove *.txt, or change it to *.config. APPDATA/postgresql/pgpass.txt APPDATA/postgresql/psqlrc.txt Another idea is to use *.conf. We already have: pg_hba.conf pg_ident.conf pg_service.conf postgresql.conf recovery.conf If we want an extension on those two files, it seems *.conf is it, and one hopes they would have already configured XP to pull up their favorite editor for *.conf. Personally, I don't really care :-) My point was that .pgpass is bad. pgpass or pgpass.conf or pgpass.txt are all fine by me. I agree that .conf might be more logical than .txt. //Magnus ---(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] [pgsql-hackers-win32] [BUGS] More SSL questions..
Magnus Hagander [EMAIL PROTECTED] writes: Personally, I don't really care :-) My point was that .pgpass is bad. pgpass or pgpass.conf or pgpass.txt are all fine by me. I agree that .conf might be more logical than .txt. I think the analogy to .conf is bogus. The existing files named .conf are server config not client config, and they don't have leading dots in their names on Unix either. Also, the whole point of this exercise is to make these files easy to edit for newbies. The fact that an association *could* be configured for .conf seems to me to miss the point: anyone who knows enough to do that wouldn't have a problem with any spelling whatever... regards, tom lane ---(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] [pgsql-hackers-win32] [BUGS] More SSL questions..
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Personally, I don't really care :-) My point was that .pgpass is bad. pgpass or pgpass.conf or pgpass.txt are all fine by me. I agree that .conf might be more logical than .txt. I think the analogy to .conf is bogus. The existing files named .conf are server config not client config, and they don't have leading dots in their names on Unix either. I don't think it is bogus. The reason our client config files don't have *.conf is because they have dots --- the leading dot says it is a config file to me. Win32 doesn't support leading dots mean config files so we add *.conf. Also, pg_service.conf is a client file used by libpq. I don't see why file extensions for the server should not also be similar for clients. Also, the whole point of this exercise is to make these files easy to edit for newbies. The fact that an association *could* be configured for .conf seems to me to miss the point: anyone who knows enough to do that wouldn't have a problem with any spelling whatever... What I am saying is that no one else uses *.txt for config files on Win32 and it is confusing. The *.txt will confuse everyone, experts and novices, while *.conf is clear but will be a little harder for novices to open. Also remember the files will normally not exist so novices are going to have to create those files first anyway. At this point, Andrew, Magnus, and I who deal with Win32 regularly all feel *.conf is more logical than *.txt. I have not heard anyone say *.txt is better except Tom. Is that enough of a vote? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 8: explain analyze is your friend
Re: [HACKERS] [pgsql-hackers-win32] [BUGS] More SSL questions..
Bruce Momjian pgman@candle.pha.pa.us writes: At this point, Andrew, Magnus, and I who deal with Win32 regularly all feel *.conf is more logical than *.txt. I have not heard anyone say *.txt is better except Tom. Is that enough of a vote? AFAIR they both said they didn't care; you are the only one who is exercised about this. I don't particularly care either, but I do note that Peter already generated what was supposed to be the final version of the man pages, and we can't change this without changing those. Do what you want; I have more important problems to worry about right now. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [pgsql-hackers-win32] [BUGS] More SSL questions..
Bruce Momjian wrote: At this point, Andrew, Magnus, and I who deal with Win32 regularly all feel *.conf is more logical than *.txt. I have not heard anyone say *.txt is better except Tom. Is that enough of a vote? *ahem* :-) I though what I said was that we should leave the name alone except for removing a leading dot. I have seen other cases where .foorc became foo.rc on windows, which isn't a bad solution for such files. I honestly don't care that much - it's not worth a religious fight over. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-hackers-win32] [BUGS] More SSL questions..
Magnus Hagander wrote: My feeling is that the *.txt is actually misleading because people will think of it as a file full of freeform text (paragraphs) and not a configuration file. Why would they think that? If notepad tends to auto-wrap files then this argument has some force; I'm not very familar with it though. It does not. There is an option to make it *show* the file with wrapped line, but it does not even have the capability to wordwrap the files themselves. FWIW, I've seen several apps that use .txt for config files, but I can't think of an example right now. Most don't though - .cfg or .conf is probably most common. Except for the majority of windows programs that don't use config files - they use the registry. But I see no reason *at all* for us to want to do that :-) It also more or less requires you to write a GUI to change the config stuff and in that case the file extension becomes irrelevant. Where are we on this? I think Andrew and I both think *.txt is confusing. We need to decide on Monday if we should change the current *.txt names. We can either leave it unchanged, remove *.txt, or change it to *.config. Currently the two Win32 files with *.txt extensions are: APPDATA/postgresql/pgpass.txt APPDATA/postgresql/psqlrc.txt *.txt was added on Win32 to make them automatically start notepad.exe when clicked on. Here is a copy of the Mozilla directory on XP: [.][..] 1138945.s 1138945.w abook.mab bookmarks-1.html bookmarks-2.html bookmarks-3.html bookmarks-4.html bookmarks-5.html bookmarks-6.html bookmarks.html [Cache][Cache.Trash] cert8.db [chatzilla] [chrome] cookies.txtcookperm.txt downloads.rdf history.dathistory.mabhostperm.1 key3.db localstore.rdf [Mail] mailViews.dat mimeTypes.rdf panacea.datpanels.rdf parent.lockprefs.js search.rdf secmod.db URL.tblXUL.mfl There are no *.txt files even though they are all text files. They are not meant to be edited by hand though. I don't have any *.txt files under \Application Data on my machine. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-hackers-win32] [BUGS] More SSL questions..
Bruce Momjian wrote: [.][..] 1138945.s 1138945.w abook.mab bookmarks-1.html bookmarks-2.html bookmarks-3.html bookmarks-4.html bookmarks-5.html bookmarks-6.html bookmarks.html [Cache][Cache.Trash] cert8.db [chatzilla] [chrome] cookies.txtcookperm.txt downloads.rdf history.dathistory.mabhostperm.1 key3.db localstore.rdf [Mail] mailViews.dat mimeTypes.rdf panacea.datpanels.rdf parent.lockprefs.js search.rdf secmod.db URL.tblXUL.mfl There are no *.txt files even though they are all text files. They are Oops, sorry there are two *.txt files for cookies, but most of the configuration files are not *.txt. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 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] [pgsql-hackers-win32] [BUGS] More SSL questions..
Bruce Momjian wrote: Magnus Hagander wrote: My feeling is that the *.txt is actually misleading because people will think of it as a file full of freeform text (paragraphs) and not a configuration file. Why would they think that? If notepad tends to auto-wrap files then this argument has some force; I'm not very familar with it though. It does not. There is an option to make it *show* the file with wrapped line, but it does not even have the capability to wordwrap the files themselves. FWIW, I've seen several apps that use .txt for config files, but I can't think of an example right now. Most don't though - .cfg or .conf is probably most common. Except for the majority of windows programs that don't use config files - they use the registry. But I see no reason *at all* for us to want to do that :-) It also more or less requires you to write a GUI to change the config stuff and in that case the file extension becomes irrelevant. Where are we on this? I think Andrew and I both think *.txt is confusing. We need to decide on Monday if we should change the current *.txt names. We can either leave it unchanged, remove *.txt, or change it to *.config. APPDATA/postgresql/pgpass.txt APPDATA/postgresql/psqlrc.txt Another idea is to use *.conf. We already have: pg_hba.conf pg_ident.conf pg_service.conf postgresql.conf recovery.conf If we want an extension on those two files, it seems *.conf is it, and one hopes they would have already configured XP to pull up their favorite editor for *.conf. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 8: explain analyze is your friend
