Re: [HACKERS] Inheritance
On Fri, 16 Aug 2002, Zeugswetter Andreas SB SD wrote: Note that the other obvious way to solve this would be to store all of the information inherited from the parent in the parent table, so that you don't have to do anything special to make all of the constraints and whatnot apply. Seems with above you are not able to constrain what qualifies for a supertable row, you would only be able to specify constraints that apply to all it's subtables. Yes, that's the whole point. If I have a constraint on a table, I think it should *never* be possible for that constraint to be violated. If a subtable should not have constraint the supertable has, it shouldn't inherit from the supertable. To do otherwise breaks the relational model. The SQL inheritance is a class/subclass thing. All tables have instances (==rows) that are not (by itself) related. (Even if they happen to share all attribute values with another row of a supertable.) If you want that, then you need to resort to 3NF (or ROWREF's which iirc is another SQL99 feature). As I understand it, SQL99 has the restriction that a row with the same primary key appearing in a supertable and/or any of its subtables must be the result of a single INSERT statement. Thus, SQL99 doesn't allow what you're saying, if I understand what you're saying. (I'm not sure that I do.) Am I to take it that you think the inheritance should be inheritance of type information only? That is, if I have supertable A and subtable A', inserting a row into A' does not make a row appear in A? If so, I've got not real problem with that at present, but it's not what postgres currently does, nor would it conform to SQL99. What do others think of this idea? cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
On Thu, 15 Aug 2002, Peter Eisentraut wrote: integrate or remove new libpqxx integrate or add to gborg Pg:DBD Seems like gborg is the place for these. I would volunteer to package libpq++ separately. Okay, the procedure is simple, but where do we want to put this? Do we want to move the extracted libraries over to gborg (would be my first preference), or keep them in the core repository? Regardless of which, the extraction is simple ... but if GBorg, if you go over and make a project and let me know what it is, I can move the library from our CVS repository straight over there, so that we lose no logs or anything ... just let me know its created ... Bruce, can you make a project for Pg::DBD? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_restore and user defined types, several other pg_restore problems
Am Freitag, 16. August 2002 15:51 schrieben Sie: Mario Weilguni [EMAIL PROTECTED] writes: Here are the problems I've encountered: * pg_restore tries to create a table with ltree and ltree[] datatypes before the type itself is created, so it fails. Odd; what are the OIDs of the table and the datatypes? The table has 20517267, and the datatype has 85286596. The type was introduced later on, and added with alter table add. Maybe this is the problem? * several functions are already defined in template1, so create database will restore these functions. pg_restore will try to restore those functions as well and fails. Maybe create or replace function can be used here? No. Use pg_restore per the documentation: make an empty database for it to restore into (by cloning template0 instead of template1). Oops, I did not know this. What happens if I use the -C switch of pg_restore? The man page says: -C --create Create the database before restoring into it. (When this switch appears, the database named with -d is used only to issue the initial CREATE DATABASE command. All data is restored into the database name that appears in the archive.) But does pg_restore use template0 or template1? pg_restore: [archiver (db)] could not execute query: ERROR: data type ltree[] has no default operator class for access method gist You must specify an operator class for the index or define a default operator class for the data type Are you using recent sources? As of two weeks or so ago, pg_dump should know how to dump operator classes. No, I do not use 7.3cvs, this is version 7.2.1. But if this is fixed, it's not a problem for me, now I know how to restore the database, and 7.3 should not be too far away :-) Thanks! Best regards, Mario Weilguni ---(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] Function result cacheing
At 00:18 17/08/2002 -0400, Tom Lane wrote: Philip Warner [EMAIL PROTECTED] writes: Obviously this is not a 7.3 item, but would people support such functionality going into a future version? Actually, I wouldn't. This forces application-based caches, which in turn need indexed local temporary tables, and ideally the ability to either check if they exist, or a CREATE...IF NOT EXISTS. And I'd guess the indexes would not be used, whereas the 'checksum on args' model comes close to hash-index performance. I can think of very few situations where such caching is useful, Aside, of course, from any external functions that for whatever reason are expensive to execute, and which will be passwed the same args more than once in a single SELECT. As well as any functions that do complex lookups on reference data in the database; in short anything that only reads data and which does more than a simple lookup, and which gets the same args more than once. and I don't believe that the mechanism required would pay for itself. In what sense? The mechanism is close to cost-free if the flag is not set on the function, and would presumably only be set by the definer if there was likely to be a benefit. Coming from a database that supports such functions, I *know* they can help a great deal. In the cases where a cache does make sense, it's sufficiently application-specific that a generic cache on a key consisting of the function arguments isn't the right thing anyway; Not for the the uses I have. you'll find you want some internal logic to decide what to cache and what key to use to retrieve it. No, I don't. I am very happy with function parameters being used. Furthermore, a generic cache will have no clue whatever about cache-invalidating events, thus further restricting its usefulness. This is true, but mainly an argument for cacheing at the statement level; TX level cacheing seems like a bad idea. It's a matter for application design to ensure that when a developer marks a function as invariant, then they mean it. If it really becomes a problem, then *maybe* we need an application-level cache invalidation, but it seems very unlikely to be a problem. (Your suggestion of flush at transaction end is too short-term for most applications, too long-term for some, and just right for hardly any.) I actually suggested two options, and would personally prefer flush-at-statement-end. Build the cache internally to your function if you need it. Not too keen on building cacheing code into 3 different functions just on the one database; and doing the same on another which also would benefit. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Better handling of parse errors
Patch applied. Thanks. --- Gavin Sherry wrote: On Wed, 14 Aug 2002, Tom Lane wrote: Gavin Sherry [EMAIL PROTECTED] writes: ... do we want to modify every 7.2 error message? Nyet ... but I don't think tacking an offset onto the end of parse error at or near foo messages is likely to cause the sort of generalized havoc you suggest ... In that case, attached is a patch which locates the beginning of the offending token more efficiently (per your suggestion of using scanbuf). The new patch does the same as before: template1=# select * frum pg_class; ERROR: parser: parse error at or near frum at character 10 It also implement's Tom's suggestion: template1=# select * from pg_class where\g ERROR: parse: parse error at end of input Gavin Content-Description: [ Attachment, skipping... ] ---(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 [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: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Marc G. Fournier wrote: On Thu, 15 Aug 2002, Peter Eisentraut wrote: integrate or remove new libpqxx integrate or add to gborg Pg:DBD Seems like gborg is the place for these. I would volunteer to package libpq++ separately. Okay, the procedure is simple, but where do we want to put this? Do we want to move the extracted libraries over to gborg (would be my first preference), or keep them in the core repository? Regardless of which, the extraction is simple ... but if GBorg, if you go over and make a project and let me know what it is, I can move the library from our CVS repository straight over there, so that we lose no logs or anything ... just let me know its created ... Bruce, can you make a project for Pg::DBD? OK, I am ready to do the work, but I would like to get a plan of where we are going. I see in interfaces: cli ecpg jdbc libpgeasy libpgtcl libpq libpq++ libpqxx odbc perl5 python and we have Pg:DBD waiting to be added. Now, I know one of Marc's goals is to have libpq as a stand-alone tarball, but I thought we decided that this _didn't_ require it to be in a separate CVS repository. If we split these up based on activity, we have, in decreasing activity order: jdbc odbc libpq libpqxx cli ecpg libpq++ libpgtcl python libpgeasy Pg:DBD perl5 We already have separate web sites for jdbc and odbc, and they are in our main CVS. What goals do we have? Do we create gborg accounts for all/most of these so releases can be made independently of the main server? Do we move their CVS out of the main tree too? I don't think we should judge libpqxx differently than the other interfaces just because it is new. We should find a consistent solution and apply that to all of these interfaces. Let me add that odbc and jdbc have successfully made releases independent of our server for over a year now. I wonder if the best solution is to create gborg accounts for every interface and keep them in our main CVS, and do independent releases from there. Should we point to jdbc/odbc.postgresql.org from gborg? -- 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]
[HACKERS] TODO item: make pg_dump use dependencies to choose dump order
I can't find any TODO item that mentions fixing pg_dump's deficiencies concerning choosing an order to dump the database objects in. The existing method (basically, dump in OID order) tends to fail in situations where you've used ALTER TABLE, and in any case it breaks down completely after OID wraparound. When using a 7.3 or later database, pg_dump could use the pg_depend entries to deduce a safe order for dumping objects. This will be a big rewrite and I don't see it happening for 7.3, but I think it should be on the TODO list. 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] TODO item: make pg_dump use dependencies to choose dump order
Added: * Use dependency information to dump data in proper order --- Tom Lane wrote: I can't find any TODO item that mentions fixing pg_dump's deficiencies concerning choosing an order to dump the database objects in. The existing method (basically, dump in OID order) tends to fail in situations where you've used ALTER TABLE, and in any case it breaks down completely after OID wraparound. When using a 7.3 or later database, pg_dump could use the pg_depend entries to deduce a safe order for dumping objects. This will be a big rewrite and I don't see it happening for 7.3, but I think it should be on the TODO list. regards, tom lane -- 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] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
OK, with two people now asking to have the patch removed, and with no comment from Thomas, I have removed the patch. This removes XLogDir environment variable, and -X postmaster/postgres/initdb/pg_ctl flag. I have also removed the code that dynamically sized xlogdir. I will post the patch to patches, and keep the patch here in case it is needed later. --- Curt Sampson wrote: On Fri, 16 Aug 2002, Bruce Momjian wrote: Part of the reason we can't just continue to use the symlink method is that the PGXLOG environment variable situation is currently in CVS beyond initdb and in postmaster, postgres, and pg_ctl, so we do have to do something before 7.3 or we will have new environment variable handling in all those commands, and I don't think we have agreement on that. Well, let's take it out, then, and use the symlink instead. It may be in CVS now, but it's never been in a release, so there should be no problem with removing it. I think we've got some pretty strong opinions here that distributing configuration information amongst multiple environment variables is a Bad Idea. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- 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: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Bruce Momjian [EMAIL PROTECTED] writes: Now, I know one of Marc's goals is to have libpq as a stand-alone tarball, but I thought we decided that this _didn't_ require it to be in a separate CVS repository. Removing libpq is impossible since psql, pg_dump, etc all depend on it. I don't think we should judge libpqxx differently than the other interfaces just because it is new. The fact that it is new is a strike against it, and the fact that it is not integrated is a bigger strike against it. I think we should move out libpqxx and libpq++ now, and also perl5 if we are going to put DBD::Pg on gborg rather than in the main distro. We want to ensure there is a level playing field for libpqxx and DBD::Pg. jdbc and odbc should be moved if and only if their maintainers want it. I'm not in a hurry to move the rest; they're small and don't generate a lot of CVS traffic. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
Bruce Momjian [EMAIL PROTECTED] writes: OK, with two people now asking to have the patch removed, and with no comment from Thomas, I have removed the patch. This removes XLogDir environment variable, and -X postmaster/postgres/initdb/pg_ctl flag. I thought we intended to keep the -X switch for initdb (only), and have it make a symlink. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] more fulltextindex stuff
Christopher Kings-Lynne writes: I notice that the new default for the contrib Makefiles is to build libfti.so, etc. instead of the old fti.so. The default is to build nothing ... (?) Won't this cause dump restore problems for everyone already using the contrib? No, because what is build is not what is installed. Anyone mind if I change it to use MODULES instead of MODULE_big for backwards compatibility? MODULES_big can only build one shared object per directory but it can contain several object files. That is the tradeoff. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] where to put NO_MKTIME_BEFORE_1970?
Tom Lane writes: Really what we need is a test on the glibc version, which seems a bit difficult. Well, it's not that difficult to figure out the version (run /lib/libc.so.6), but I'm afraid the version is not going to tell you anything. For instance, the libc versions that are claimed to have the problem in Red Hat releases don't appear to have that problem here. In any case we don't currently have a mechanism for reflecting whatever configure would discover into the resultmap. That would appear to be very tricky. Maybe we need to misappropriate the alternate result file mechanism that was intended for the locale differences. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Marc G. Fournier [EMAIL PROTECTED] writes: Bruce, can you make a project for Pg::DBD? Erm, has anyone contacted the maintainer of DBD::Pg? Given that Bruce doesn't maintain it and AFAIK Jeffrey Baker (the current maintainer) and hasn't expressed any dissatisfaction with CPAN, I'm not sure why you'd like to move the software to GBorg... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Neil Conway wrote: Marc G. Fournier [EMAIL PROTECTED] writes: Bruce, can you make a project for Pg::DBD? Erm, has anyone contacted the maintainer of DBD::Pg? Given that Bruce doesn't maintain it and AFAIK Jeffrey Baker (the current maintainer) and hasn't expressed any dissatisfaction with CPAN, I'm not sure why you'd like to move the software to GBorg... Uh, I got OK from Edmund. I haven't talked to Jeffrey but I thought someone else had. I thought he had just taken it over and was OK with us handling it. -- 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] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, with two people now asking to have the patch removed, and with no comment from Thomas, I have removed the patch. This removes XLogDir environment variable, and -X postmaster/postgres/initdb/pg_ctl flag. I thought we intended to keep the -X switch for initdb (only), and have it make a symlink. The majority of the patch wasn't needed, so rather than muck it up, I just backed it all out. If we want that, and I think we do, someone should implent it as a separate patch that people can review. All the work is going to be done in initdb anyway. -- 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: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
On Sat, 17 Aug 2002, Bruce Momjian wrote: OK, I am ready to do the work, but I would like to get a plan of where we are going. I see in interfaces: cli ecpg jdbc libpgeasy libpgtcl libpq libpq++ libpqxx odbc perl5 python and we have Pg:DBD waiting to be added. Now, I know one of Marc's goals is to have libpq as a stand-alone tarball, but I thought we decided that this _didn't_ require it to be in a separate CVS repository. Ya, this one I had no problem with ... the only thing with libpq that I do request is that it has its own configure so that it can be completely standalone ... but, IMHO, if someone compiles the server, they are going to need libpq, I just want to make sure taht if they want libpq, they don't need the server ... If we split these up based on activity, we have, in decreasing activity order: jdbc odbc libpq libpqxx cli ecpg libpq++ libpgtcl python libpgeasy Pg:DBD perl5 We already have separate web sites for jdbc and odbc, and they are in our main CVS. What goals do we have? Do we create gborg accounts for all/most of these so releases can be made independently of the main server? Do we move their CVS out of the main tree too? IMHO, yes ... Let me add that odbc and jdbc have successfully made releases independent of our server for over a year now. Correct, so they should be the easiest to move out as well ... I wonder if the best solution is to create gborg accounts for every interface and keep them in our main CVS, and do independent releases from there. Should we point to jdbc/odbc.postgresql.org from gborg? Chris has made code changes to GBorg to allow for this based on requests from Dave Page (ie. PgAdminII) ... so there is no problems with that ... As for keeping them in our main CVS, the more we put over onto GBorg, the more it will get used, test, debugged, pounded and stabilized ... hell, maybe some of the 'dead projects' that are on GBorg will come alive again also if ppl are going to GBorg and find them, download them and hit the authors for fixes :) But, moving the interfaces over will at least give ppl a reason to go over and see what is there ... ---(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] Open 7.3 items
OK, I think we are doing this backwards. Instead of adding '@' to global users, and then removing it in the backend, why don't we have local users end with '@', that way, global users continue to connect just as they have before, and local users connect with @, so dave@db1 connects as 'dave@' and if he has other database access, he can use the same 'dave@' name. That removes some of the uglification, I think. --- Tom Lane wrote: BTW, I just thought of a small improvement to your patch that eliminates some of the ugliness. Suppose that when we recognize an attempt to connect as a global user (ie, feature flag is on and last character of username is '@'), we strip off the '@' before proceeding. Then we would have: global users appear in pg_shadow as foo local users appear in pg_shadow as foo@db and what this would mean is that you can flip between feature-enabled and feature-disabled states without breaking your global logins. So you don't need the extra step of creating a postgres@ before turning on the feature. (Which was pretty ugly anyway, since even though postgres@ could be made a superuser, he wouldn't be the same user as postgres --- this affects table ownership, for example, and would be a serious issue if you wanted any non-superuser global users.) I suppose some might argue that having to say postgres@ to log in, when your username is really just postgres as far as you can see in the database, is a tad confusing. But the whole thing is an acknowledged wart anyway, and I think getting rid of the two problems mentioned above is worth it. Also, if we do this then it's important to strip a trailing '@' only if it's the *only* one in the given username. Else a local user 'foo@db1' could cheat to log into db2 by saying username = 'foo@db1@' with requested database db2. But I can't see any other security hole. regards, tom lane -- 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: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
On Sat, 17 Aug 2002, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Now, I know one of Marc's goals is to have libpq as a stand-alone tarball, but I thought we decided that this _didn't_ require it to be in a separate CVS repository. Removing libpq is impossible since psql, pg_dump, etc all depend on it. I don't think we should judge libpqxx differently than the other interfaces just because it is new. The fact that it is new is a strike against it, and the fact that it is not integrated is a bigger strike against it. I think we should move out libpqxx and libpq++ now, and also perl5 if we are going to put DBD::Pg on gborg rather than in the main distro. We want to ensure there is a level playing field for libpqxx and DBD::Pg. jdbc and odbc should be moved if and only if their maintainers want it. I'm not in a hurry to move the rest; they're small and don't generate a lot of CVS traffic. Note: I'm happy enough seeing ppl starting to consider moving this stuff over to GBorg, I, by no means, expect everything to go overnight, or even before v7.3 ... As I mentioned in another message, I'm also kinda hoping that if we start to divert traffic to GBorg for stuff like this, then some of the other projects might 'come alive' again as well ... ---(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: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Marc G. Fournier wrote: Chris has made code changes to GBorg to allow for this based on requests from Dave Page (ie. PgAdminII) ... so there is no problems with that ... As for keeping them in our main CVS, the more we put over onto GBorg, the more it will get used, test, debugged, pounded and stabilized ... hell, maybe some of the 'dead projects' that are on GBorg will come alive again also if ppl are going to GBorg and find them, download them and hit the authors for fixes :) But, moving the interfaces over will at least give ppl a reason to go over and see what is there ... OK, so create gborg projects for all interfaces, and allow them to release independently. I think we have agreement on that. It can only be a win. That also gives us a mailing list and bug tracking for each interface, which is nice. I think the only unknown is whether their CVS's should be moved out of the main tree. -- 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] Open 7.3 items
Bruce Momjian [EMAIL PROTECTED] writes: OK, I think we are doing this backwards. Instead of adding '@' to global users, and then removing it in the backend, why don't we have local users end with '@', that way, global users continue to connect just as they have before, and local users connect with @, so dave@db1 connects as 'dave@' and if he has other database access, he can use the same 'dave@' name. No, *that* would be backwards. In installations that are using this feature, the vast majority of the users are going to be local ones. And the global users will be the presumably-more-sophisticated admins. Putting the onus of the '@' decoration on the local users instead of the global ones is exactly the wrong way to go. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
On Sat, 17 Aug 2002, Bruce Momjian wrote: Marc G. Fournier wrote: Chris has made code changes to GBorg to allow for this based on requests from Dave Page (ie. PgAdminII) ... so there is no problems with that ... As for keeping them in our main CVS, the more we put over onto GBorg, the more it will get used, test, debugged, pounded and stabilized ... hell, maybe some of the 'dead projects' that are on GBorg will come alive again also if ppl are going to GBorg and find them, download them and hit the authors for fixes :) But, moving the interfaces over will at least give ppl a reason to go over and see what is there ... OK, so create gborg projects for all interfaces, and allow them to release independently. I think we have agreement on that. It can only be a win. That also gives us a mailing list and bug tracking for each interface, which is nice. I think the only unknown is whether their CVS's should be moved out of the main tree. Yes, they should be ... maintaining sources in two places would be 'nightmarish' *and* at least GBorg will give a maintainer the ability to add other developers to have CVS access as well, or transferrign maintainership over to someone else ... GBorg is setup so that each project has its own CVSROOT, and its own access controls ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Marc G. Fournier [EMAIL PROTECTED] writes: I think the only unknown is whether their CVS's should be moved out of the main tree. Yes, they should be ... Certainly. I was a bit worried about losing CVS history, but Marc indicated he could make the move with history and all, so there's no downside. 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: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
On Sat, 17 Aug 2002, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: I think the only unknown is whether their CVS's should be moved out of the main tree. Yes, they should be ... Certainly. I was a bit worried about losing CVS history, but Marc indicated he could make the move with history and all, so there's no downside. Okay, here is what I'd like to suggest ... Bruce, let's start off really simple ... go create a project for libpq++ (I believe someone even volunteered to maintain it?) and let me know once created, and I'll move the CVS directory over for libpq++ and out of the pgsql-server directory ... ---(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] compile warnings in CVS
I get the following compiling the current CVS code with gcc 3.1: ... fe-connect.c: In function `connectDBComplete': fe-connect.c:1081: warning: suggest parentheses around within || fe-connect.c:1086: warning: implicit declaration of function `gettimeofday' ... pg_controldata.c: In function `main': pg_controldata.c:91: warning: `%c' yields only last 2 digits of year in some locales pg_controldata.c:93: warning: `%c' yields only last 2 digits of year in some locales Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] compile warnings in CVS
Neil Conway [EMAIL PROTECTED] writes: I get the following compiling the current CVS code with gcc 3.1: I also get 4 regression test failures, due to Gavin's improvements to the parser error messages. AFAICT no actual problems, the expected error message strings just needed to be updated. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(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] compile warnings in CVS
Neil Conway [EMAIL PROTECTED] writes: pg_controldata.c: In function `main': pg_controldata.c:91: warning: `%c' yields only last 2 digits of year in some locales pg_controldata.c:93: warning: `%c' yields only last 2 digits of year in some locales Yeah. I was willing to ignore that while pg_controldata was in contrib, but it's much more annoying when it's in the main tree. Anyone know if gcc has a --not-quite-so-nannyish warnings mode? IMHO %c is a perfectly reasonable format choice --- the strftime man page defines it as %cLocale's appropriate date and time representation. While we could go over to some %Y-%M-etc-etc notation, that doesn't strike me as a step forward. pg_controldata's output should be conveniently human-readable IMHO, and that means following local conventions. Another alternative is char *fmt = %c; ... strftime(..., fmt, ...); which I think will probably defeat gcc's check (haven't tried it though). Does anyone want to argue that %c is actually a bad choice? I think gcc's just being unreasonable here, but maybe I'm missing something (and no, Y2K arguments won't change my mind). 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
[HACKERS] Remove implicit unique index creation on SERIAL columns?
I'd like to propose dropping the auto-creation of UNIQUE indexes on serial columns for the following reasons: 1. Serials with indexes are quite difficult to handle in pg_dump. It means that the implicitly created unique index must be destroyed prior to loading the data, then re-created afterward else risk a performance hit. 2. SERIAL columns are usually used as the primary key of the table. As such one must specify PRIMARY KEY at creation time to override the implicitly created UNIQUE index. 3. Consistency with other databases. MySQL's AUTO_INCREMENT suggests quite heavily that an index be applied, but it doesn't appear to do it for you. Oracle has SEQUENCES, but it is up to the user to associate them with a column as per my understanding. At least, thats all I could find. SAP - SERIAL and SERIAL(n). No index is created (creates sequence / default) A nice side effect is that analyze.c will become somewhat cleaner. Any thoughts? Does anyone create serial columns without manually specifying UNIQUE when wanting an index? Examples in our documentation do. See section 5.1.4 in the current docset: http://developer.postgresql.org/docs/postgres/datatype.html Removal of implicit UNIQUE index creation would not affect structure of current or prior db versions -- strictly new tables on 7.3. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Remove implicit unique index creation on SERIAL columns?
Rod Taylor wrote: I'd like to propose dropping the auto-creation of UNIQUE indexes on serial columns for the following reasons: 1. Serials with indexes are quite difficult to handle in pg_dump. It means that the implicitly created unique index must be destroyed prior to loading the data, then re-created afterward else risk a performance hit. 2. SERIAL columns are usually used as the primary key of the table. As such one must specify PRIMARY KEY at creation time to override the implicitly created UNIQUE index. 3. Consistency with other databases. MySQL's AUTO_INCREMENT suggests quite heavily that an index be applied, but it doesn't appear to do it for you. Oracle has SEQUENCES, but it is up to the user to associate them with a column as per my understanding. At least, thats all I could find. SAP - SERIAL and SERIAL(n). No index is created (creates sequence / default) FWIW, also MSSQL. I agree 100%. If you want an index, unique constraint, or primary key on a SERIAL, I think you should explicitly add it. SERIAL should give me a column that automatically increments -- no more, no less. Joe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CVS Messages
On Fri, Aug 16, 2002 at 05:44:50PM -0400, Rod Taylor wrote: Is it possible for the cvs emails to include a URL to the appropriate entries in cvs web? The below is current: Modified files: src/backend/utils/adt: ruleutils.c If you're using a Web browser with support for smart bookmarks, nicknames, and javascript: URLs, then you can define a bookmark as something like: javascript:re=/(:.)/;window.location=http://developer.postgresql.org/cvsweb.cgi/pgsql-server/+%s.replace(re, /) and then cut-and-paste the line from the email into your location field using a nickname: pgcvs src/backend/utils/adt: ruleutils.c and have it bring up the cvsweb page. Works with galeon; I guess other recent browsers (Konqueror, Moz, IE?) can do something very similar if not quite identical. Richard ---(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] Open 7.3 items
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, I think we are doing this backwards. Instead of adding '@' to global users, and then removing it in the backend, why don't we have local users end with '@', that way, global users continue to connect just as they have before, and local users connect with @, so dave@db1 connects as 'dave@' and if he has other database access, he can use the same 'dave@' name. No, *that* would be backwards. In installations that are using this feature, the vast majority of the users are going to be local ones. And the global users will be the presumably-more-sophisticated admins. Putting the onus of the '@' decoration on the local users instead of the global ones is exactly the wrong way to go. OK, but it looks slightly less ugly. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] compile warnings in CVS
OK, I have fixed the first two with the following patch. The second
pair Tom has commented on.
---
Neil Conway wrote:
I get the following compiling the current CVS code with gcc 3.1:
...
fe-connect.c: In function `connectDBComplete':
fe-connect.c:1081: warning: suggest parentheses around within ||
fe-connect.c:1086: warning: implicit declaration of function `gettimeofday'
...
pg_controldata.c: In function `main':
pg_controldata.c:91: warning: `%c' yields only last 2 digits of year in some locales
pg_controldata.c:93: warning: `%c' yields only last 2 digits of year in some locales
Cheers,
Neil
--
Neil Conway [EMAIL PROTECTED]
PGP Key ID: DB3C29FC
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/interfaces/libpq/fe-connect.c
===
RCS file: /cvsroot/pgsql-server/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.192
diff -c -r1.192 fe-connect.c
*** src/interfaces/libpq/fe-connect.c 17 Aug 2002 12:33:17 - 1.192
--- src/interfaces/libpq/fe-connect.c 18 Aug 2002 00:04:07 -
***
*** 19,24
--- 19,25
#include fcntl.h
#include errno.h
#include ctype.h
+ #include time.h
#include libpq-fe.h
#include libpq-int.h
***
*** 1078,1095
}
! while (NULL == rp || remains.tv_sec 0 || remains.tv_sec == 0
remains.tv_usec 0)
{
/*
* If connecting timeout is set, get current time.
*/
! if ( NULL != rp -1 == gettimeofday(start_time, NULL))
{
conn-status = CONNECTION_BAD;
return 0;
}
! /*
* Wait, if necessary. Note that the initial state (just after
* PQconnectStart) is to wait for the socket to select for
* writing.
--- 1079,1096
}
! while (rp == NULL || remains.tv_sec 0 || (remains.tv_sec == 0
remains.tv_usec 0))
{
/*
* If connecting timeout is set, get current time.
*/
! if (rp != NULL gettimeofday(start_time, NULL) == -1)
{
conn-status = CONNECTION_BAD;
return 0;
}
! /*
* Wait, if necessary. Note that the initial state (just after
* PQconnectStart) is to wait for the socket to select for
* writing.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] compile warnings in CVS
Yes, very nanny-ish. Not sure how to turn it off. --- Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: pg_controldata.c: In function `main': pg_controldata.c:91: warning: `%c' yields only last 2 digits of year in some locales pg_controldata.c:93: warning: `%c' yields only last 2 digits of year in some locales Yeah. I was willing to ignore that while pg_controldata was in contrib, but it's much more annoying when it's in the main tree. Anyone know if gcc has a --not-quite-so-nannyish warnings mode? IMHO %c is a perfectly reasonable format choice --- the strftime man page defines it as %cLocale's appropriate date and time representation. While we could go over to some %Y-%M-etc-etc notation, that doesn't strike me as a step forward. pg_controldata's output should be conveniently human-readable IMHO, and that means following local conventions. Another alternative is char *fmt = %c; ... strftime(..., fmt, ...); which I think will probably defeat gcc's check (haven't tried it though). Does anyone want to argue that %c is actually a bad choice? I think gcc's just being unreasonable here, but maybe I'm missing something (and no, Y2K arguments won't change my mind). 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 -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] cvs-tip broken
n file included from fe-connect.c:24: libpq-int.h:337: warning: `struct timeval' declared inside parameter list libpq-int.h:337: warning: its scope is only this definition or declaration, which is probably not what you want. fe-connect.c: In function `connectDBComplete': fe-connect.c:1060: storage size of `remains' isn't known fe-connect.c:1060: storage size of `finish_time' isn't known fe-connect.c:1060: storage size of `start_time' isn't known fe-connect.c:1081: warning: suggest parentheses around within || fe-connect.c:1086: warning: implicit declaration of function `gettimeofday' fe-connect.c:1106: warning: passing arg 4 of `pqWaitTimed' from incompatible pointer type fe-connect.c:1114: warning: passing arg 4 of `pqWaitTimed' from incompatible pointer type fe-connect.c:1060: warning: unused variable `start_time' fe-connect.c:1060: warning: unused variable `finish_time' fe-connect.c:1060: warning: unused variable `remains' ---(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] Remove implicit unique index creation on SERIAL columns?
Joe Conway [EMAIL PROTECTED] writes: I agree 100%. If you want an index, unique constraint, or primary key on a SERIAL, I think you should explicitly add it. SERIAL should give me a column that automatically increments -- no more, no less. Hmm, do you also want to eliminate the implicit NOT NULL constraint? I think that efficiency and orthogonality are adequate reasons for dissociating UNIQUE from SERIAL. The efficiency argument is pretty weak in the case of the NOT NULL part, though, so maybe backwards compatibility should win out there. Another line of thought: as near as I can tell, SQL92 allows defaults and CHECK constraints to be associated with domains. Taking the viewpoint that SERIAL is a domain would say that the DEFAULT nextval() is okay, and CHECK NOT NULL is okay, but UNIQUE is not okay to be implied by the domain type. Perhaps the SQL authors knew what they were doing when they made that restriction... (Note that although I just dissuaded Rod from actually turning SERIAL into a domain on compatibility grounds, I don't see any reason why we shouldn't use the spec's rules about domains to reason about how it should work. In a slightly longer timeframe we may decide that we do want to make it a domain.) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] cvs-tip broken
I am not seeing the failure here on BSD/OS. I just fixed the libpq-int.h problem. Please update to cvs current and let me know what you see. --- Rod Taylor wrote: n file included from fe-connect.c:24: libpq-int.h:337: warning: `struct timeval' declared inside parameter list libpq-int.h:337: warning: its scope is only this definition or declaration, which is probably not what you want. fe-connect.c: In function `connectDBComplete': fe-connect.c:1060: storage size of `remains' isn't known fe-connect.c:1060: storage size of `finish_time' isn't known fe-connect.c:1060: storage size of `start_time' isn't known fe-connect.c:1081: warning: suggest parentheses around within || fe-connect.c:1086: warning: implicit declaration of function `gettimeofday' fe-connect.c:1106: warning: passing arg 4 of `pqWaitTimed' from incompatible pointer type fe-connect.c:1114: warning: passing arg 4 of `pqWaitTimed' from incompatible pointer type fe-connect.c:1060: warning: unused variable `start_time' fe-connect.c:1060: warning: unused variable `finish_time' fe-connect.c:1060: warning: unused variable `remains' ---(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 -- 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] cvs-tip broken
Bruce Momjian [EMAIL PROTECTED] writes: I am not seeing the failure here on BSD/OS. I just fixed the libpq-int.h problem. Please update to cvs current and let me know what you see. FWIW, libpq seems to build fine here (HPUX 10.20) both before and after your latest commit. Rod should probably mention what platform he's using, and where it defines struct timeval... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] cvs-tip broken
The code was clearly wrong, mentioning timeval with no time.h nor sys/types.h include. My patches should fix him [good]. :-) Who used to say, I will fix him good? I don't remember. --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I am not seeing the failure here on BSD/OS. I just fixed the libpq-int.h problem. Please update to cvs current and let me know what you see. FWIW, libpq seems to build fine here (HPUX 10.20) both before and after your latest commit. Rod should probably mention what platform he's using, and where it defines struct timeval... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html -- 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] compile warnings in CVS
I have applied patches to the regression test to fix this. Thanks. --- Neil Conway wrote: Neil Conway [EMAIL PROTECTED] writes: I get the following compiling the current CVS code with gcc 3.1: I also get 4 regression test failures, due to Gavin's improvements to the parser error messages. AFAICT no actual problems, the expected error message strings just needed to be updated. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(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 -- 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] Open 7.3 items
Bruce Momjian [EMAIL PROTECTED] writes: OK, here is the patch with the suggested changes. I am sending the patch to hackers because there has been so much interest in this. One minor gripe: + /* If user@, it is a global user, remove '@' */ + if (strchr(port-user, '@') == port-user + strlen(port-user)-1) This code is correct, but it tempts someone to replace the strchr() with a single-character check on the last character of the string. Which would introduce the security hole we discussed before. The code is okay, but *please* improve the comment to point out that you are also excluding the case where there are @'s to the left of the last character. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] cvs-tip broken
On Sat, 2002-08-17 at 22:08, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am not seeing the failure here on BSD/OS. I just fixed the
libpq-int.h problem. Please update to cvs current and let me know what
you see.
FWIW, libpq seems to build fine here (HPUX 10.20) both before and after
your latest commit. Rod should probably mention what platform he's
using, and where it defines struct timeval...
I still have to wait another 30 minutes before I can update to the
latest revision, but here's what's needed:
bash-2.05b$ uname -a
FreeBSD jester 4.6-RELEASE FreeBSD 4.6-RELEASE #8: Fri Jul 19 23:45:16
EDT 2002 root@jester:/usr/obj/usr/src/sys/JESTER i386
/*
* Copyright (c) 1982, 1986, 1993
* The Regents of the University of California. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
*must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors.
* 4. Neither the name of the University nor the names of its contributors
*may be used to endorse or promote products derived from this software
*without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* @(#)time.h 8.5 (Berkeley) 5/4/95
* $FreeBSD: src/sys/sys/time.h,v 1.42 1999/12/29 04:24:48 peter Exp $
*/
#ifndef _SYS_TIME_H_
#define _SYS_TIME_H_
#include sys/types.h
/*
* Structure returned by gettimeofday(2) system call,
* and used in other calls.
*/
struct timeval {
long tv_sec; /* seconds */
long tv_usec; /* and microseconds */
};
#ifndef _TIMESPEC_DECLARED
#define _TIMESPEC_DECLARED
struct timespec {
time_t tv_sec; /* seconds */
long tv_nsec; /* and nanoseconds */
};
#endif
#define TIMEVAL_TO_TIMESPEC(tv, ts) \
do {\
(ts)-tv_sec = (tv)-tv_sec;\
(ts)-tv_nsec = (tv)-tv_usec * 1000; \
} while (0)
#define TIMESPEC_TO_TIMEVAL(tv, ts) \
do {\
(tv)-tv_sec = (ts)-tv_sec;\
(tv)-tv_usec = (ts)-tv_nsec / 1000; \
} while (0)
struct timezone {
int tz_minuteswest; /* minutes west of Greenwich */
int tz_dsttime; /* type of dst correction */
};
#define DST_NONE 0 /* not on dst */
#define DST_USA 1 /* USA style dst */
#define DST_AUST 2 /* Australian style dst */
#define DST_WET 3 /* Western European dst */
#define DST_MET 4 /* Middle European dst */
#define DST_EET 5 /* Eastern European dst */
#define DST_CAN 6 /* Canada */
/*
* Structure used to interface to the machine dependent hardware support
* for timekeeping.
*
* A timecounter is a (hard or soft) binary counter which has two properties:
** it runs at a fixed, known frequency.
** it must not roll over in less than (1 + delta)/HZ seconds. delta
* is expected to be less than 20 msec, but no hard data has been
* collected on this. 16 bit at 5 MHz (31 msec) is known to work.
*
* get_timecount() reads the counter.
*
* counter_mask removes unimplemented bits from the count value.
*
* frequency is the counter frequency in hz.
*
* name is a short mnemonic name for this counter.
*
* cost is a measure of how long time it takes to read the counter.
*
* adjustment [PPM 16] which means that the smallest unit of correction
* you can apply amounts to 481.5 usec/year.
*
* scale_micro [2^32 * usec/tick].
* scale_nano_i [ns/tick].
* scale_nano_f [(ns/2^32)/tick].
*
* offset_count is the contents of the counter which corresponds to the
* rest of the offset_* values.
*
* offset_sec [s].
* offset_micro [usec].
* offset_nano [ns/2^32] is misnamed, the real unit is .23283064365...
* attoseconds (10E-18) and before you ask: yes, they are in fact
* called
Re: [HACKERS] cvs-tip broken
I think I added time.h and sys/types.h. That should do it for you. --- Rod Taylor wrote: On Sat, 2002-08-17 at 22:08, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I am not seeing the failure here on BSD/OS. I just fixed the libpq-int.h problem. Please update to cvs current and let me know what you see. FWIW, libpq seems to build fine here (HPUX 10.20) both before and after your latest commit. Rod should probably mention what platform he's using, and where it defines struct timeval... I still have to wait another 30 minutes before I can update to the latest revision, but here's what's needed: bash-2.05b$ uname -a FreeBSD jester 4.6-RELEASE FreeBSD 4.6-RELEASE #8: Fri Jul 19 23:45:16 EDT 2002 root@jester:/usr/obj/usr/src/sys/JESTER i386 [ Attachment, skipping... ] -- 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] compile warnings in CVS
I said: Another alternative is char *fmt = %c; ... strftime(..., fmt, ...); which I think will probably defeat gcc's check (haven't tried it though). I tried this, and it did shut up the warning in my local copy of gcc. So I committed it. Does anyone want to argue that %c is actually a bad choice? This is still open to debate if anyone wants to make the case... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 items
OK, applied, with that change. --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, here is the patch with the suggested changes. I am sending the patch to hackers because there has been so much interest in this. One minor gripe: + /* If user@, it is a global user, remove '@' */ + if (strchr(port-user, '@') == port-user + strlen(port-user)-1) This code is correct, but it tempts someone to replace the strchr() with a single-character check on the last character of the string. Which would introduce the security hole we discussed before. The code is okay, but *please* improve the comment to point out that you are also excluding the case where there are @'s to the left of the last character. regards, tom lane -- 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])
[HACKERS] Open 7.3 items
As you can see, the open items list is greatly shrunk. We have two weeks to go and most of these seems do-able, except for point-in-time recovery, which may not make it. I haven't heard anything recently on it. Would someone put together a porting document for schema changes and drop column changes? --- P O S T G R E S Q L 7 . 3 O P E NI T E M S Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. Source Code Changes --- Point-in-time recovery - status? (J.R., Richard) Schema handling - ready? interfaces? client apps? Drop column handling - ready for all clients, apps? ecpg and bison issues - solved? (Michael) have pg_dumpall dump out db privilege and per-user/db settings fix implicit type coercions that are worse Prepared statements - to be reviewed (Tom) improve macros in new tuple header code (Tom) integrate or move to gborg libpqxx, Pg:DBD Allow PL/PgSQL functions to return sets (Neil) Allow easy display of usernames in a group (pg_hba.conf uses groups now) fix BeOS and QNX4 ports Documentation Changes - Mention foreign keys and SERIAL dependencies will not be in 7.2 loaded tables Document need to add permissions to loaded functions and languages -- 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] cvs-tip broken
On Sat, 2002-08-17 at 22:44, Bruce Momjian wrote: I think I added time.h and sys/types.h. That should do it for you. Hmm.. whelp, the file in question on FreeBSD is sys/time.h (attached earlier) so this won't fix it. --- Rod Taylor wrote: On Sat, 2002-08-17 at 22:08, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I am not seeing the failure here on BSD/OS. I just fixed the libpq-int.h problem. Please update to cvs current and let me know what you see. FWIW, libpq seems to build fine here (HPUX 10.20) both before and after your latest commit. Rod should probably mention what platform he's using, and where it defines struct timeval... I still have to wait another 30 minutes before I can update to the latest revision, but here's what's needed: bash-2.05b$ uname -a FreeBSD jester 4.6-RELEASE FreeBSD 4.6-RELEASE #8: Fri Jul 19 23:45:16 EDT 2002 root@jester:/usr/obj/usr/src/sys/JESTER i386 [ Attachment, skipping... ] -- 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] cvs-tip broken
Rod Taylor [EMAIL PROTECTED] writes: Hmm.. whelp, the file in question on FreeBSD is sys/time.h (attached earlier) so this won't fix it. Added #include sys/time.h. We seem to use this unconditionally in many other files, so I don't see a reason not to include it here. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
