Re: [HACKERS] A plan to improve error messages with context, hint
(1) Lexical/syntax error source localisation An extract of the offending source must be shown if possible along syntax error messages. You would do well to go to the archives and read some of the previous discussion of these issues. I'll do that. In particular, we determined that the appropriate place for this sort of thing is on the client side, not in the backend. The current status of clients is that none of those I use will report anything useful. The server can use the DETAIL field (which is not used anyway) so as to give the details, and the client can chose to ignore it if it can do a better job. That would be providing a basic capability common to all clients, instead of waiting for a final implementation in all clients. Only the client knows what is a reasonable way to mark the error position. Sure. All generated error messages, especially from the parser, should be assorted with a HINT to help the user, if possible. Something like: I think the odds of doing anything very successful in the way of syntax hints are small. The cases where you can produce a reliable hint (ie, one that's not likely to be misleading) are not very interesting. This is an a-priori jugement. I hope this is not ground to reject any patch without a try. What I can do is take notice of all syntax errors from my students and use them as test cases to see what hint would help;-) I just have to turn on the database logs. [...] That will be enough to cause you to deliver the wrong hint, and a wrong hint is worse than none. I agree that if the hint are always wrong, then no hint is better. So in case we do not know, it is better not to say anything. However, I think that a lot of cases can be given good hints, and for those cases it should be done. Also, it is better to judge on the result. ISTM that client-side code that pops up the syntax summary for the command would probably accomplish far more, for far less work. We do have some hints for semantic errors, and adding more isn't a bad project, but you still have the same hazard of whether you can deliver useful hints. I agree. ... in the processing of the command. The problem is different because it occurs in functions that can be called from quite different contexts, and the context is not really known to the function. Thus when the error occurs in the function, it cannot provide a useful context. As none is provided, the user must guess... I am not understanding what you have against the existing error context stack mechanism. Certainly it could be used in more places than it is, but why do you feel a need to build a separate one? What I understand of the error stack is that it is for error message recursion. About the context field, I have seen in my quick browsing is how one can add information to it, but I haven't seen (yet) how to remove some information to put some other in place. Tell me if I'm wrong. If I'm wrong, it means that the infractructure is already in place, and one just need to put some more context calls. What is really needed is indeed a context stack in the error stack, and what I've seen is a simple string in the error stack, where contexts are appended one to the other at the string level. - processing create table hello - processing constraint $1: CHECK (ind0) - - processing constraint foo: xxx REFERENCES bye - - processing constraint bla: data NOT NULL - - Have a nice day, -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] A plan to improve error messages with context, hint
(2) Does someone has any comment about these problems or
the way I intend to try to address them?
About the implementation idea with hints. I'm not sure will be so easy to
implement as you suggested. Maybe if one add hints to every construct,
and set to empty hint where it does not make sense.
Sure.
What I'm afraid of is to get hints or advices that are plain wrong.
CREATE TABLE foo (bar int key);
HINT: table name expected
or something.
Sure, I agree with you.
But if it works good in practice, why not having hints.
I agree that the actual validation is whether the result looks good,
and are most of the time useful.
stmt: CREATE TABLE ( anything ); { generate error missing table name }
Yes, that's an idea, but it would change the syntax definition, and
may create conflicts, so it's an harder way to do it.
--
Fabien Coelho - [EMAIL PROTECTED]
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [pgsql-hackers-win32] [HACKERS] Tablespaces
On Friday 05 March 2004 07:51, Thomas Swan wrote: Apparently, I have failed tremendously in addressing a concern. The question is does PostgreSQL need to rely on symlinks and will that dependency introduce problems? There is an active win32 port underway (see this mailing list). One proposal was to try to use an OS specific filesystem feature to perform a symlink on NTFS. Can the special symlink that NTFS allegedly supports be archived the same way symlinks are archived on Unix? If so, is there a utility that can do this (zip, tar, etc). Why not try and find out? http://www.nedprod.com/programs/Win32/SymLink/ This will apparently create symlinks on NTFS5 volumes via a simple dialogue box. You'd probably want to test using pkzip/winzip, Symantec/Norton - anyone think of any others? -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-hackers-win32] [HACKERS] Tablespaces
First of all, symlinks are a pretty popular feature. Even Windows supports what would be needed. Second of all, PostgreSQL will still run on OSes without symlinks, tablespaces won't be available, but PostgreSQL will still run. Since we are all using PostgreSQL without My idea for platforms that don't support symlinks would be to simply create a tblspaceoid directory inplace instead of the symlink (maybe throw a warning). My feeling is, that using the same syntax on such platforms is important, but actual distribution is not (since they will most likely be small systems). Andreas ---(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
[HACKERS] notice about costly ri checks (3)
Dear patchers, New submission attempt, with new message wording. Also, the message is only shown once, and the offending key component is not shown. Have a nice day, -- Fabien Coelho - [EMAIL PROTECTED] costly_ri_notice.patch.gz Description: Binary data ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Slony-I makes progress
On Fri, Mar 05, 2004 at 12:47:23AM +0100, Jochem van Dieten wrote: I personally don't think that a GUI tool should be the province of the Slony project. Seriously. I think that Slony should focus on a I very much agree with this, but this is Jan's baby, so I didn't say anything. I have personally never used a GUI with a postgres database (well, okay, I used one for a bit to troubleshoot a problem my boss was having with a pg node once), and I don't really plan to. I guess I was unaware this is a common usage pattern. command-line api and catalogs, and allow the existing GUI projects to build a slony-supporting interface. Why a command line api? I believe it would make sense to be able to configure and control all nodes of the entire system from psql connected to any of the nodes. That would also facilitate the existing GUI projects in adding a Slony-manager. In theory, most of the stuff that Slony is doing is within the database, and as such, could be configurable via stored procedures. I see a few problems with this. First off, it is not possible to configure external applications (such as erserver has a daemon) from within the database except through the modification of tables within the database which are monitored by said application. Second, it increases the footprint of Slony on the database. I am fairly uneasy about adding more tables, functions, and triggers to my (already quite taxed) production database. To add further functions for configuration, as well as related tables and triggers, makes my job managing the database more difficult. Additionally, those commands are queries. For something as trivial as configuration data, I would much rather not be issuing queries against an already very busy database. I am much more comfortable with the principle of external configuration files and programs. Lastly, and I may be the black sheep here, I don't find sql to be particularly useful for doing things that require a complex grammar. In this instance, I don't want to have to do something like: production=# select slony_config_setval( 'log_dir', '/data/slony_logs'); to manage the configuration. Obviously, this could be worse than the above example. I don't understand the opposition to an external set of tools (even a gui if need be). It seems to me, that until the postmaster has some kind of native replication, all replication efforts will be based on external programs. As such, they should be configured externally, and be treated as any other daemon would be. Alex -- [EMAIL PROTECTED] Alex J. Avriette, Unix Systems Gladiator v shpxvat ungr jvaqbjf naq v ubcr ovyy tngrf oheaf va uryy. - Ronald O. Thompson, 13 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] A plan to improve error messages with context, hint and details.
Fabien COELHO [EMAIL PROTECTED] writes: In particular, we determined that the appropriate place for this sort of thing is on the client side, not in the backend. The current status of clients is that none of those I use will report anything useful. So fix the clients. We have been through this discussion before; you are not the first to claim we should do a quick-and-dirty solution on the backend side. That wasn't the consensus then, and I don't think it is now. I think the odds of doing anything very successful in the way of syntax hints are small. The cases where you can produce a reliable hint (ie, one that's not likely to be misleading) are not very interesting. This is an a-priori jugement. I hope this is not ground to reject any patch without a try. No, but it will be a likely reason for rejecting the patch *after* trying it ;-). Consider yourself warned that the first thing I'll do is try to make the patch produce misleading hints. I am not understanding what you have against the existing error context stack mechanism. About the context field, I have seen in my quick browsing is how one can add information to it, but I haven't seen (yet) how to remove some information to put some other in place. Why would you want to? Removing available information is never correct. What is really needed is indeed a context stack in the error stack, and what I've seen is a simple string in the error stack, where contexts are appended one to the other at the string level. I think you're misinterpreting what the code does. The context hooks are installed and removed as if on a stack, but we don't form an error string until an error actually occurs. At that point, stringing together the outputs of the active hooks is the correct thing to do. 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: [pgsql-hackers-win32] [HACKERS] Tablespaces
Thomas Swan wrote: The fact of the matter is that PostgreSQL runs better on some platforms than others, and it probably always will. Heck, as of today, PostgreSQL is officially supported on the Gamecube. Does that mean that the PostgreSQL developers should limit themselves to the features offered by the Gamecube? What, precisely, is the point of developing for the lowest common denominator? The other option proposed was to give win32 a subset of features that would be available to other platforms. In this case, that would be that the win32 port could support tablespaces. This is strikingly different than a performance issue. It would be one thing for tablespaces to perform poorly, it's another for them to fail or not exist altogether. Perhaps if you could give us an example of an actual case where some actual PostgreSQL users (or potential users) might be affected? See the comment from Tom Lane on limiting features. Look at the potential Win32 market which outnumbers the unix market in number of computers and developers by a large margin. Let me put it this way. Unix tools like tar can already use symlinks, as can administrators from the command line, so symlinks are best on that platform, period. If we have a platform that doesn't have symlinks (and I think Win32 might), we will have to implement a different way to do tablespace lookups _only_ for those platforms. The use of symlinks on Unix has just too many advantages to use a another sub-optimal solution on that platform. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 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] Sigh, 7.3.6 rewrap not right
Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: Please, don't call it 7.3.6. Streamlining releases is terrible. 7.3.7 or 7.3.6.1 or SOMETHING other than 7.3.6, and just let 7.3.6 be a brown paper bag release (like 6.4.1 was). There were no code-change differences in this rewrap, so I see no real need to change the version number. The lesson I'd prefer to see us take away from this is that Marc needs to automate his release wrapping process more. These sorta mistakes shouldn't have happened in the first place ... regards, tom lane How about in future, packaging it all up as a release candidate, (ie. 7.4.2-rc1) for a week or so before official final release, so package maintainers can build their scripts etc, and small problems like this ironed out. If anything needs to be corrected, it can be repackaged with a bumped rc number until it is determined that everything is fine. At which point the latest rc is renamed as the final release (ie. 7.4.2). Unless you already do this, and I've completely missed it somehow -- Mark Gibson gibsonm |AT| cromwell |DOT| co |DOT| uk Web Developer Database Admin Cromwell Tools Ltd. Leicester, England. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-hackers-win32] [HACKERS] Tablespaces
Zeugswetter Andreas SB SD wrote: First of all, symlinks are a pretty popular feature. Even Windows supports what would be needed. Second of all, PostgreSQL will still run on OSes without symlinks, tablespaces won't be available, but PostgreSQL will still run. Since we are all using PostgreSQL without My idea for platforms that don't support symlinks would be to simply create a tblspaceoid directory inplace instead of the symlink (maybe throw a warning). My feeling is, that using the same syntax on such platforms is important, but actual distribution is not (since they will most likely be small systems). Nice idea --- so you can create tablespaces, but can't specify a different location for it --- makes sense. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] A plan to improve error messages with context, hint
Fabien COELHO wrote: The current status of clients is that none of those I use will report anything useful. pgAdmin3's query tool will set a mark on the offending line. Regards, Andreas ---(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] Sigh, 7.3.6 rewrap not right
On Friday 05 March 2004 09:50 am, Mark Gibson wrote: How about in future, packaging it all up as a release candidate, (ie. 7.4.2-rc1) for a week or so before official final release, We do this already for major versions. Maybe we should consider this for minors too. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Sigh, 7.3.6 rewrap not right
On Thursday 04 March 2004 7:28 pm, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: Please, don't call it 7.3.6. Streamlining releases is terrible. 7.3.7 or 7.3.6.1 or SOMETHING other than 7.3.6, and just let 7.3.6 be a brown paper bag release (like 6.4.1 was). There were no code-change differences in this rewrap, so I see no real need to change the version number. I have to agree with Lamar et. al. The _code_ may not have changed but the product did and the version number should reflect that. This issue was discussed in InfoWorld a couple years back. I don't recall reading a single comment from someone who felt this practice benefitted them but there were plenty of tales of pain an frustration caused by even seemingly small changes between versions. Perhaps the fourth digit could represent non-code related updates such as documentation and packaging fixes. Cheers, Steve ---(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: [pgsql-hackers-win32] [HACKERS] Tablespaces
On Fri, 5 Mar 2004, Thomas Swan wrote: [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: My feeling is that we need not support tablespaces on OS's without symlinks. To create symlinked directories on Win2k NTFS see: http://www.sysinternals.com/ntw2k/source/misc.shtml#junction I think Win2000 or XP would be a reasonable restriction for Win32 PG installations that want tablespaces. Oh, good --- symlinks for directories are all that we need for this design. I think that settles it then. What archival tools are there that would restore this to this back to the filesystem: tar? zip? What would happen if a symlink were removed or pointed to an invalid location while the postmaste was running? Well, for backup, just run tar or find on /data with a flag to follow symlinks, and you are done. Can't get much easier than that. I'm ruferring to NTFS and the win32 platforms. How does tar handle these symlinks on the NTFS filesystem? What about if someone finds that FAT32 is significantly better for the database? tar doesn't know anything about PostgreSQL system catalogs. If we use symlinks for tablespaces then it would be possible to backup downed databases with a simple tar command on every platform *I* care about (and probably Windows too). Using system catalogs for this stuff would simply guarantee that I would have to read the system catalogs and then back up each tablespace manually. In short, your idea would trade off (maybe) having to backup tablespaces manually on a few platforms for the certainty of having to backup tablespaces manually on all platforms. How is that a win? Apparently, I have failed tremendously in addressing a concern. The question is does PostgreSQL need to rely on symlinks and will that dependency introduce problems? There is an active win32 port underway (see this mailing list). One proposal was to try to use an OS specific filesystem feature to perform a symlink on NTFS. Can the special symlink that NTFS allegedly supports be archived the same way symlinks are archived on Unix? If so, is there a utility that can do this (zip, tar, etc). The backup operator would still need to know what directories needed to be archived in addtion to the pgdata directory.Is this symlink structure a normal/special file that can be archived by normal means (tar,zip, etc)? According to this page: http://www.linuxinfor.com/en/man1/ln.1.html from the linux man pages, On existing implementations, if it is at all possible to make a hard link to a directory, this may be done by the superuser only. POSIX forbids the system call link(2) and the utility ln to make hard links to directories (but does not forbid hard links to cross filesystem boundaries). and states that the command ln is POSIX 1003.2. However, POSIX 1003.2 (1996) does not discuss soft links. Soft links were introduced by BSD, and do not occur in System V release 3 (and older) systems. I fear the more useful of the two would be soft links, but if soft links are not a part of the POSIX standard, then postgresql probably shouldn't base key features on them unless said features would be onerous to implement without soft links. Oddly enough though, Microsoft has now released their unix services package for free, and it comes with the commands to create a symbolic link, and runs on Windows NT 4.0. Windows 2000. Windows XP. and Windows Server 2003. So, soft links would appear to not be a real non-starter, as long as the ability to make softlinks on those systems won't rely on having some strange package installed (like MS's Unix services package.) I imagine there's a standard OS call in modern MS OSes that will let you create a symbolic link with no special libs installed, and if that's the case, the the argument that maybe FAT would be a better file system comes under the same heading as running your database on NFS. Neither is a good idea, and PGSQL can't guarantee normal, reliable operation. Example: PGDATA is C:\pgdata I have a tablespace in Z:\1\ and Z:\2\ There exists an alleged symlink in C:\pgdata\data\base\tablespaces\schmoo - Z:\1 Can I archive [ C:\pgdata, Z:\1, Z:\2 ], restore them, and have postgresql working just as before? Have you tried building said structure and backing up and restoring it to see? We aren't talking about a feature that work[s] on Linux on not on FreeBSD. We are talking about a feature that works on every OS that suports symlinks (which includes even operating systems like Windows that PostgreSQL doesn't currently support). Hello? What was this response from Tom Lane? My feeling is that we need not support tablespaces on OS's without symlinks. That seems to be indicative of a feature set restriction
[HACKERS] IN joining
Hi
I have a problem understanding the code to make certain in join are
performed properly. Specifically I have problems understading when
IN_UNIQUE_{INNER,OUTER} is a valid jointype.
Its in joinrels.c:make_join_rel.
Consider this example:
SELECT * FROM a,b WHERE a.id = b.id AND (a.id) IN (SELECT c.id FROM c)
the possible execution trees are {{a,b}, {c}}, {{a,c},{b}} and the code
seems to also permit {{b,c},{a}}. It is the latter I'm having problems with.
When joining {b} and {c} it will fall through and suggest a
IN_UNIQUE_{INNER,OUTER} jointype.
My logic is this: {c} \in {c,b} so it is a valid plan according to the
first check.
We have an issue according to the second check and we haven't done the
work before according to the 3rd and 4th checks.
Since the lefthand of the IN {a} is not in either {b} or {c} we skip the
IN_JOIN{_REVERSE}.
But since one of the relations is equal to the right side {c} of the IN
we determine that IN_UNIQUE_{INNER,OUTER} is a valid jointype.
Now, the next join between {a} and {b,c} is the one I fail to understand
when it can ever happen...
{c} \in {a,b,c} so it is a valid plan according to the first check.
We have an issue according to the second check.
Since we have no trace of the IN's left hand {a} in {b,c} 3rd and 4th
check says we have not done the work?!?
The final checks fail because {c} != {b,c}, thus we determine it is an
invalid plan.
My question is: When is it ever a valid jointype to use
IN_UNIQUE_{INNER,OUTER}? Or am I missing something?
--
Dennis
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [pgsql-hackers-win32] [HACKERS] Tablespaces
Quoting Bruce Momjian [EMAIL PROTECTED]: Zeugswetter Andreas SB SD wrote: My idea for platforms that don't support symlinks would be to simply create a tblspaceoid directory inplace instead of the symlink (maybe throw a warning). My feeling is, that using the same syntax on such platforms is important, but actual distribution is not (since they will most likely be small systems). Nice idea --- so you can create tablespaces, but can't specify a different location for it --- makes sense. If this is the way it is handled then I don't guess I have any objections. You would end up with the files for a single database spread out, possibly over multiple disks. I think I would still prefer the option of using an XML file to this, but I can also see the need to limit the platform specific code. I guess if I feel strongly enough about it, through the magic of Open Source I can patch it to work the way I want. If the way Junctions work on NTFS becomes an issue after the port, it won't be a problem, it will be an opportunity. Quoting Bruce Momjian [EMAIL PROTECTED]: The use of symlinks on Unix has just too many advantages to use a another sub-optimal solution on that platform. And creating separate solutions for different platforms has too many disadvantages to warrent a compile time option. Ok, implement this and move on to porting so that I can use it in the world I work in. :-) Seriously, thanks for doing all you guys do. I will be activly evangelizing as soon as I can get a version working standalone where I am. Lawrence E. Smithmier, Jr. MCP, MCAD (919) 522-9738 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-hackers-win32] [HACKERS] Tablespaces
Thomas Swan [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: [snip] Apparently, I have failed tremendously in addressing a concern. The question is does PostgreSQL need to rely on symlinks and will that dependency introduce problems? There is an active win32 port underway (see this mailing list). One proposal was to try to use an OS specific filesystem feature to perform a symlink on NTFS. Can the special symlink that NTFS allegedly supports be archived the same way symlinks are archived on Unix? If so, is there a utility that can do this (zip, tar, etc). The backup operator would still need to know what directories needed to be archived in addtion to the pgdata directory. Is this symlink structure a normal/special file that can be archived by normal means (tar,zip, etc)? Example: PGDATA is C:\pgdata I have a tablespace in Z:\1\ and Z:\2\ There exists an alleged symlink in C:\pgdata\data\base\tablespaces\schmoo - Z:\1 Can I archive [ C:\pgdata, Z:\1, Z:\2 ], restore them, and have postgresql working just as before? My point is that if you are using some sort of sytem table, catalog file, or whatever else (besides symlinks), you are still going to have to backup up c:\pgdata z:\1 and z:\2 manually anyhow. Unless, of course, you have some magical version of tar or zip that reads the PostgreSQL specific configuration file and somehow does the right thing. At least with symlinks you have a fighting chance on some platforms of being able to do: tar zcvf /tmp/backup.tgz /usr/local/postgres/pgdata/ and have it do the right thing. Using PostgreSQL specific catalogs you would force UNIX users (the majority of PostgreSQL users right now) to back up their tablespaces manually. Forcing platforms with symlinks to use your wacky symlink replacement just guarantees that all platforms work equally poorly. It doesn't make the Win32 port any better. You would still have to backup c:\pgdata z:\1\ and z:\2\ separately on Win32. The only difference is that now your misery would have the company of all of the rest of us. It seems a little insane to introduce an OS/filesystem dependency at the onset of a porting effort especially if you hope to be OS agnostic for feature sets. I think someone would be crying foul if a new feature only worked on Linux and not on FreeBSD. First of all, symlinks are a pretty popular feature. Even Windows supports what would be needed. Second of all, PostgreSQL will still run on OSes without symlinks, tablespaces won't be available, but PostgreSQL will still run. Since we are all using PostgreSQL without tablespaces now, it can hardly be argued that tablespaces are a critical feature. We aren't talking about a feature that work[s] on Linux on not on FreeBSD. We are talking about a feature that works on every OS that suports symlinks (which includes even operating systems like Windows that PostgreSQL doesn't currently support). Hello? What was this response from Tom Lane? My feeling is that we need not support tablespaces on OS's without symlinks. That seems to be indicative of a feature set restriction base on platform. Tom Lane works for Red Hat. You can't hardly expect him to spend all of his time working around the limitations of the competition's operating system. Additionally, another developer noted the advantage of a text file is that it would be easy for someone to develop tools to help if it became difficult to edit or parse. Additionally, there could be a change away from a flat file format to an XML format to configure the tablespace area. The advantage of symlinks is that no tools would have to be written and 'ls -l' would show everything you would need to know about where your tablespaces actually were. Where is 'ls -l' on a win32 box? If you will follow the discussion of symlinks under MinGW you will see that they don't work as commanded. And, postgresql is supposed to be compiled under MinGW, but not require it to run. From Windows 2000, 'ls' is not recognized as an internal or external command, operable program or batch file. Yes, Windows lacks 'ls', but it has similar tools. XML files are relatively easy to parse, but they certainly aren't as easy as simply letting PostgreSQL follow a symlink. Why reinvent the wheel with what would essentially be PostgreSQL's own implementation of a symlink? Is opening a file recreating a symlink? If you are opening file descriptors why rely on symlinks. If you know the location either from the system catalog, a or configuration file, is it any terribly more complicated? Basically, if a tablespace needed to be renamed, or moved, or changed, your going to have to do file management anyway. The symlink saves you just a lookup as to what files go where? If you kept this small hash in memory, it's not a continuous lookup because you have the redirection internally. And, it's more portable. Yes, and the implementation of tablespaces apparently
[HACKERS] 7.4.2 release notes
Here are the 7.4.2 release notes I made. I have a few question: What detail do we need on the pg_statistics alignment fix? Do we need to show an UPDATE query to fix database? What are the ramifications of leaving it alone? A few categories list various fixes for rare fixes we made in a few areas. We would not normally spell those out in detail in a major release, and I assume we wouldn't do that in a minor release either. I will add comments to a few of them later. --- Release Notes Release 7.4.2 Release date: 2004-03-?? This release contains a variety of fixes from 7.4.1. _ Migration to version 7.4.2 A dump/restore is *not* required for those running 7.4.X. _ Changes As of 2004-03-02 * Fix problems with ALTER TABLE during concurrent access (Tom) * Improve hash build reliability (Tom) * Fix statistics alignment bug that could affect optimizer, initdb required (Tom) * Optimizer improvements (Tom) * Permission fix for view updates (Tom) * Allow non-super users to update pg_settings (Tom) * Fix for multibyte handling in position() (Korea PostgreSQL Users' Group) * Various multibyte fixes * Fix problem with hitting open file limit, especially on OS X (Tom) * Have pg_dump set client encoding on restore (Tom) * Allow ecpg to again use C keywords as column names (Michael) * Added ecpg WHENEVER NOT_FOUND to SELECT/INSERT/UPDATE/DELETE (Michael) * Fix ecpg crash for queries calling set-returning functions (Michael) * Various ecpg fixes (Michael) * Fixes for Borland compiler * Thread build improvements (Bruce) * Fix for configure --disable-shared support (Tom) * Various build fixes * Various jdbc fixes -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] IN joining
Dennis Haney [EMAIL PROTECTED] writes:
Consider this example:
SELECT * FROM a,b WHERE a.id = b.id AND (a.id) IN (SELECT c.id FROM c)
the possible execution trees are {{a,b}, {c}}, {{a,c},{b}} and the code
seems to also permit {{b,c},{a}}.
No, it does not --- as you say, that would give wrong answers. That
case is eliminated by the tests following this comment:
* JOIN_IN technique will work if outerrel includes LHS and
* innerrel is exactly RHS; conversely JOIN_REVERSE_IN handles
* RHS/LHS.
*
* JOIN_UNIQUE_OUTER will work if outerrel is exactly RHS;
* conversely JOIN_UNIQUE_INNER will work if innerrel is
* exactly RHS.
Joining {b,c} to {a} does not meet any of those four allowed cases.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.4.2 release notes
On Fri, Mar 05, 2004 at 03:00:18PM -0500, Bruce Momjian wrote: _ Migration to version 7.4.2 A dump/restore is *not* required for those running 7.4.X. _ [ . . . ] * Fix statistics alignment bug that could affect optimizer, initdb required (Tom) Does this mean that it's optional? It maybe ought to say so, then, because as it stands, I'm confused. A -- Andrew Sullivan | [EMAIL PROTECTED] The plural of anecdote is not data. --Roger Brinner ---(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] IN joining
Tom Lane wrote:
Dennis Haney [EMAIL PROTECTED] writes:
Consider this example:
SELECT * FROM a,b WHERE a.id = b.id AND (a.id) IN (SELECT c.id FROM c)
the possible execution trees are {{a,b}, {c}}, {{a,c},{b}} and the code
seems to also permit {{b,c},{a}}.
No, it does not --- as you say, that would give wrong answers. That
case is eliminated by the tests following this comment:
* JOIN_IN technique will work if outerrel includes LHS and
* innerrel is exactly RHS; conversely JOIN_REVERSE_IN handles
* RHS/LHS.
*
* JOIN_UNIQUE_OUTER will work if outerrel is exactly RHS;
* conversely JOIN_UNIQUE_INNER will work if innerrel is
* exactly RHS.
Joining {b,c} to {a} does not meet any of those four allowed cases.
Exactly my point... So why ever bother creating the {b,c} node which is
legal by the above definition?
--
Dennis
use Inline C = q{void p(char*g){
printf("Just Another %s Hacker\n",g);}};p("Perl");
Re: [HACKERS] IN joining
Dennis Haney [EMAIL PROTECTED] writes:
Joining {b,c} to {a} does not meet any of those four allowed cases.
Exactly my point... So why ever bother creating the {b,c} node which is
legal by the above definition?
We don't, because there is no such join clause.
regards, tom lane
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] 7.4.2 release notes
Andrew Sullivan wrote: On Fri, Mar 05, 2004 at 03:00:18PM -0500, Bruce Momjian wrote: _ Migration to version 7.4.2 A dump/restore is *not* required for those running 7.4.X. _ [ . . . ] * Fix statistics alignment bug that could affect optimizer, initdb required (Tom) Does this mean that it's optional? It maybe ought to say so, then, because as it stands, I'm confused. This is an item that needs clarification, as I mentioned. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 7.4.2 release notes
On Fri, Mar 05, 2004 at 06:26:52PM -0500, Bruce Momjian wrote: This is an item that needs clarification, as I mentioned. Yes, you certainly did. I apologise, I'm being unusually stupid today. -- Andrew Sullivan ---(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] 7.4.2 release notes
Andrew Sullivan wrote: On Fri, Mar 05, 2004 at 06:26:52PM -0500, Bruce Momjian wrote: This is an item that needs clarification, as I mentioned. Yes, you certainly did. I apologise, I'm being unusually stupid today. I looked again and the text mentioned statistics, but my comments referred to pg_statistic, so it was easy to miss. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Sigh, 7.3.6 rewrap not right
Steve Crawford wrote: Please, don't call it 7.3.6. Streamlining releases is terrible. 7.3.7 or 7.3.6.1 or SOMETHING other than 7.3.6, and just let 7.3.6 be a brown paper bag release (like 6.4.1 was). There were no code-change differences in this rewrap, so I see no real need to change the version number. I have to agree with Lamar et. al. The _code_ may not have changed but the product did and the version number should reflect that. I second this. As someone has said, we should probably use the -rc mechanism in the future (changing the versioning from 7.3.6 into 7.3.6.1 has a greater chance of breaking things). Allow at least one week before the final -rc turns into final. The last -rc will be byte-to-byte identical with the final, we just rename it. *If* the final turns out to contain some stupid mistake, we'll just have to make 7.3.7... Once something is released, it should not change at all. -- dave ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-hackers-win32] [HACKERS] Tablespaces
[ lots of opinions about depending on symlinks for tablespaces ] One thing that I think hasn't been noted in this thread is that our initial implementation won't bind us forever. If it becomes clear that a symlink-based implementation has real problems, we can change it. But if we spend extra effort to avoid symlinks from the start, we will never know whether that effort was justified or wasted. We have enough work to do to make tablespaces happen that I feel we should take the path of least resistance to start with. I do not think it would cost us much wasted effort if the decision proves out wrong. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Any Gentoo users interested in a slotted PostgreSQL
Mark Gibson wrote: Are there any Gentoo users here? Do you wish the PostgreSQL ebuild made use of SLOTS? I've submitted a slotted ebuild for testing at: http://bugs.gentoo.org/show_bug.cgi?id=42894 It's the first slotted ebuild i've attempted, so it may be total rubish! But I have managed to get 7.3.5 and 7.4.1 installed and running in parallel (see attachment notes on bugs.gentoo.org). -- Mark Gibson gibsonm |AT| cromwell |DOT| co |DOT| uk Web Developer Database Admin Cromwell Tools Ltd. Leicester, England. ---(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
