Re: [HACKERS] Anyone have a fresh Solaris 8 SPARC system to create
Justin Clift wrote: Hi guys, Have created a Solaris 8 Intel package for PostgreSQL 7.3.1, but don't have any SPARC boxes here any more. Does anyone have a SPARC box handy that would be available for compiling PostgreSQL 7.3.1 on? It would need to be Solaris 8 (or maybe 9), and have things like gcc 2.95.x and similar tools installed, as well as be patched with the latest recommended Solaris patches. Might be a huge ask, but am figuring it to be worth at least trying. :-) Regards and best wishes, Justin Clift I can get access to several boxes with Solaris 8 + gcc 2.95 ( maybe not right-up-to-the minute latest patches, but fairly recently patched). They are firewalled off from the internet with abolutely no chance of external access, but I can build whatever is required ( Pg 7.3.1 is already installed from source) and upload it to techdocs.postgresql.org (or similar). ...I've never tried to create a Solaris package so I will need answers to all the usual dumb questions - including what extra configure options are required as I've been building with *none* :-) regards Mark ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] Vacuum verbose output?
On 14 Jan 2003 10:54:29 -0500, Robert Treat <[EMAIL PROTECTED]> wrote: >Changed = the number of pages that had to be modified. This counts only pages changed due to heap tuple header updates (FrozenTransactionId, hint bits). It does not count page changes due to removal of dead tuples, cf. Julian's log: | NOTICE: Pages 342: Changed 0, Empty 0; Tup 8325: Vac 838, Keep 0, UnUsed 5614. | [...] | NOTICE: Pages 361: Changed 0, Empty 0; Tup 8229: Vac , Keep 0, UnUsed 5981. I don't know whether this is intentional or just an oversight. If it is the latter, let me know and I'll send a patch. Servus Manfred ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Anyone have a fresh Solaris 8 SPARC system to create
Mark Kirkwood wrote: I can get access to several boxes with Solaris 8 + gcc 2.95 ( maybe not right-up-to-the minute latest patches, but fairly recently patched). They are firewalled off from the internet with abolutely no chance of external access, but I can build whatever is required ( Pg 7.3.1 is already installed from source) and upload it to techdocs.postgresql.org (or similar). ...I've never tried to create a Solaris package so I will need answers to all the usual dumb questions - including what extra configure options are required as I've been building with *none* :-) That's cool. Making Solaris packages is pretty easy, and all of the files that might be tricky have already been created. The compilation notes taken whilst making the Solaris 8 Intel packages are at: http://techdocs.postgresql.org/guides/PackagingForSolaris It doesn't mention how to do the packaging bit, but it wouldn't be hard to create step by step instructions for you with minimal effort. :) Sound like a plan? Will also need someone else with a Solaris 8 SPARC system to try the packages out too, just in case there are weird library dependencies happening that might catch us out. Also, am wondering if learning how to do "cross compiling" instead might be worthwhile. Don't yet know anything about it, but it gets mentioned in a lot of documents. :-) Regards and best wishes, Justin Clift regards Mark -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] UNION result
Stephan Szabo <[EMAIL PROTECTED]> writes: > Hmm, I think (but am not sure) that the spec bit > in SQL92 that addresses this is 9.3 > Set operation result data types based on the > text in 7.10 query expression. It seems > to say to me that should always be an > approximate numeric (if 1.0 is an approximate > numeric). Am I reading that right? Yeah, the existing algorithm for determining CASE/UNION result datatype does not have any smarts about preferring numeric over integer, which is what's missing to handle this case per-spec. There has been some speculation about junking the existing code (which is mostly driven by a hardwired notion of "preferred types") in favor of something driven by the contents of pg_cast. (At least I recall a message or two about it, but I can't find it in the archives at the moment.) Nobody's made a specific proposal though --- and I'm more than a little bit worried about the possible speed penalty of turning what's presently a simple C switch-statement into a bunch of catalog lookups. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] UNION result
On Wed, 15 Jan 2003, Tom Lane wrote: > Stephan Szabo <[EMAIL PROTECTED]> writes: > > Hmm, I think (but am not sure) that the spec bit > > in SQL92 that addresses this is 9.3 > > Set operation result data types based on the > > text in 7.10 query expression. It seems > > to say to me that should always be an > > approximate numeric (if 1.0 is an approximate > > numeric). Am I reading that right? > > Yeah, the existing algorithm for determining CASE/UNION result datatype > does not have any smarts about preferring numeric over integer, which is > what's missing to handle this case per-spec. > > There has been some speculation about junking the existing code (which > is mostly driven by a hardwired notion of "preferred types") in favor of > something driven by the contents of pg_cast. (At least I recall a > message or two about it, but I can't find it in the archives at the > moment.) It seems to me that the spec has a fairly hardwired notion of what types should come out given the sql types. The biggest problems that I can see are that it doesn't extend well to an extensible type system and that in alot of cases it doesn't seem to allow conversions (for example select CAST(1 as float) union select '1' - if you were to allow conversions the rules seem to be ambiguous) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] UNION result
Stephan Szabo <[EMAIL PROTECTED]> writes: > It seems to me that the spec has a fairly hardwired notion of what types > should come out given the sql types. The biggest problems that I can > see are that it doesn't extend well to an extensible type system and that > in alot of cases it doesn't seem to allow conversions (for example > select CAST(1 as float) union select '1' - if you were to allow > conversions the rules seem to be ambiguous) Agreed, we can't make use of the spec's rules as anything much better than "spiritual guidance". But it'd be nice if the rules we use match what the spec says for the cases covered by the spec. In particular, I think it's intuitively correct that numeric union int should yield numeric no matter which order you write them in. Actually, now that I look at the code, 7.3 does in fact get this case right, because we did add a check on pg_cast: it will prefer a type over another if there is an implicit cast in only one direction. regression=# select 1 union select 1.2; ?column? -- 1 1.2 (2 rows) The OP may have been fooled by this behavior: regression=# select 1 union select 1.0; ?column? -- 1 (1 row) which happens because '1' and '1.0' are considered equal numeric values, even though they print differently. I'm not convinced that the UNION algorithm is right yet, but surely it's better than it was before. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] inet regression test
Looks like some ORDER BY statements would be useful. *** ./expected/inet.out Sat Jun 16 22:05:20 2001 --- ./results/inet.out Wed Jan 15 10:18:40 2003 *** *** 193,212 select * from inet_tbl where i<<'192.168.1.0/24'::cidr; c|i +-- 192.168.1.0/24 | 192.168.1.0/25 192.168.1.0/24 | 192.168.1.255/25 - 192.168.1.0/24 | 192.168.1.226 (3 rows) select * from inet_tbl where i<<='192.168.1.0/24'::cidr; c|i +-- - 192.168.1.0/24 | 192.168.1.0/24 192.168.1.0/24 | 192.168.1.226/24 ! 192.168.1.0/24 | 192.168.1.255/24 192.168.1.0/24 | 192.168.1.0/25 192.168.1.0/24 | 192.168.1.255/25 - 192.168.1.0/24 | 192.168.1.226 (6 rows) set enable_seqscan to on; --- 193,212 select * from inet_tbl where i<<'192.168.1.0/24'::cidr; c|i +-- + 192.168.1.0/24 | 192.168.1.226 192.168.1.0/24 | 192.168.1.0/25 192.168.1.0/24 | 192.168.1.255/25 (3 rows) select * from inet_tbl where i<<='192.168.1.0/24'::cidr; c|i +-- 192.168.1.0/24 | 192.168.1.226/24 ! 192.168.1.0/24 | 192.168.1.226 ! 192.168.1.0/24 | 192.168.1.0/24 192.168.1.0/24 | 192.168.1.0/25 + 192.168.1.0/24 | 192.168.1.255/24 192.168.1.0/24 | 192.168.1.255/25 (6 rows) set enable_seqscan to on; -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Anyone have a fresh Solaris 8 SPARC system to create
On Wednesday 15 January 2003 09:20, Justin Clift wrote: > Sound like a plan? Will also need someone else with a Solaris 8 SPARC > system to try the packages out too, just in case there are weird library > dependencies happening that might catch us out. I have access to several (two dozen) currently unused Ultra30 systems. I can install Sol8 on one and Sol9 on another and provide ssh access (once I figure out how to get ssh working on Solaris) to you, once I know your static IP address or subnet range. It may be a few days to a week before I can do the actual installation, however. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] UNION result
On Wed, 15 Jan 2003, Tom Lane wrote: > Stephan Szabo <[EMAIL PROTECTED]> writes: > > It seems to me that the spec has a fairly hardwired notion of what types > > should come out given the sql types. The biggest problems that I can > > see are that it doesn't extend well to an extensible type system and that > > in alot of cases it doesn't seem to allow conversions (for example > > select CAST(1 as float) union select '1' - if you were to allow > > conversions the rules seem to be ambiguous) > > Agreed, we can't make use of the spec's rules as anything much better > than "spiritual guidance". But it'd be nice if the rules we use match > what the spec says for the cases covered by the spec. In particular, > I think it's intuitively correct that numeric union int should yield > numeric no matter which order you write them in. > > Actually, now that I look at the code, 7.3 does in fact get this case > right, because we did add a check on pg_cast: it will prefer a type over > another if there is an implicit cast in only one direction. > The OP may have been fooled by this behavior: > > regression=# select 1 union select 1.0; And I was fooled by select '1' union select 1; because I'd forgotten that '1' isn't exactly a character string constant. select '1'::text union select 1; properly errors. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] inet regression test
OK, I have applied an patch to ORDER BY on those queries. I don't see the ordering you have here, but this should fix it for you. I also uppercased the keywords while I was in there. --- Rod Taylor wrote: -- Start of PGP signed section. > Looks like some ORDER BY statements would be useful. > > *** ./expected/inet.out Sat Jun 16 22:05:20 2001 > --- ./results/inet.outWed Jan 15 10:18:40 2003 > *** > *** 193,212 > select * from inet_tbl where i<<'192.168.1.0/24'::cidr; > c|i > +-- >192.168.1.0/24 | 192.168.1.0/25 >192.168.1.0/24 | 192.168.1.255/25 > - 192.168.1.0/24 | 192.168.1.226 > (3 rows) > > select * from inet_tbl where i<<='192.168.1.0/24'::cidr; > c|i > +-- > - 192.168.1.0/24 | 192.168.1.0/24 >192.168.1.0/24 | 192.168.1.226/24 > ! 192.168.1.0/24 | 192.168.1.255/24 >192.168.1.0/24 | 192.168.1.0/25 >192.168.1.0/24 | 192.168.1.255/25 > - 192.168.1.0/24 | 192.168.1.226 > (6 rows) > > set enable_seqscan to on; > --- 193,212 > select * from inet_tbl where i<<'192.168.1.0/24'::cidr; > c|i > +-- > + 192.168.1.0/24 | 192.168.1.226 >192.168.1.0/24 | 192.168.1.0/25 >192.168.1.0/24 | 192.168.1.255/25 > (3 rows) > > select * from inet_tbl where i<<='192.168.1.0/24'::cidr; > c|i > +-- >192.168.1.0/24 | 192.168.1.226/24 > ! 192.168.1.0/24 | 192.168.1.226 > ! 192.168.1.0/24 | 192.168.1.0/24 >192.168.1.0/24 | 192.168.1.0/25 > + 192.168.1.0/24 | 192.168.1.255/24 >192.168.1.0/24 | 192.168.1.255/25 > (6 rows) > > set enable_seqscan to on; > > -- > Rod Taylor <[EMAIL PROTECTED]> > > PGP Key: http://www.rbt.ca/rbtpub.asc -- End of PGP section, PGP failed! -- 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/test/regress/expected/inet.out === RCS file: /cvsroot/pgsql-server/src/test/regress/expected/inet.out,v retrieving revision 1.13 diff -c -c -r1.13 inet.out *** src/test/regress/expected/inet.out 17 Jun 2001 02:05:20 - 1.13 --- src/test/regress/expected/inet.out 15 Jan 2003 16:34:09 - *** *** 168,174 (14 rows) -- check the conversion to/from text and set_netmask ! select '' AS ten, set_masklen(inet(text(i)), 24) FROM INET_TBL; ten | set_masklen -+-- | 192.168.1.226/24 --- 168,174 (14 rows) -- check the conversion to/from text and set_netmask ! SELECT '' AS ten, set_masklen(inet(text(i)), 24) FROM INET_TBL; ten | set_masklen -+-- | 192.168.1.226/24 *** *** 188,196 (14 rows) -- check that index works correctly ! create index inet_idx1 on inet_tbl(i); ! set enable_seqscan to off; ! select * from inet_tbl where i<<'192.168.1.0/24'::cidr; c|i +-- 192.168.1.0/24 | 192.168.1.0/25 --- 188,196 (14 rows) -- check that index works correctly ! CREATE INDEX inet_idx1 ON inet_tbl(i); ! SET enable_seqscan TO off; ! SELECT * FROM inet_tbl WHERE i<<'192.168.1.0/24'::cidr ORDER BY c,i; c|i +-- 192.168.1.0/24 | 192.168.1.0/25 *** *** 198,204 192.168.1.0/24 | 192.168.1.226 (3 rows) ! select * from inet_tbl where i<<='192.168.1.0/24'::cidr; c|i +-- 192.168.1.0/24 | 192.168.1.0/24 --- 198,204 192.168.1.0/24 | 192.168.1.226 (3 rows) ! SELECT * FROM inet_tbl WHERE i<<='192.168.1.0/24'::cidr ORDER BY c,i; c|i +-- 192.168.1.0/24 | 192.168.1.0/24 *** *** 209,213 192.168.1.0/24 | 192.168.1.226 (6 rows) ! set enable_seqscan to on; ! drop index inet_idx1; --- 209,213 192.168.1.0/24 | 192.168.1.226 (6 rows) ! SET enable_seqscan TO on; ! DROP INDEX inet_idx1; Index: src/test/regress/sql/inet.sql === RCS file: /cvsroot/pgsql-server/src/test/regress/sql/inet.sql,v retrieving revision 1.7 diff -c -c -r1.7 inet.sql *** src/test/regress/sql/inet.sql 17 Jun 2001 02:05:20 - 1.7 --- src/test/regress/sql/inet.sql 15 Jan 2003 16:34:10 - *** *** 52,63 FROM INET_TBL; -- check the conversion to/from text
Re: [HACKERS] Anyone have a fresh Solaris 8 SPARC system to create
Lamar Owen wrote: On Wednesday 15 January 2003 09:20, Justin Clift wrote: Sound like a plan? Will also need someone else with a Solaris 8 SPARC system to try the packages out too, just in case there are weird library dependencies happening that might catch us out. I have access to several (two dozen) currently unused Ultra30 systems. I can install Sol8 on one and Sol9 on another and provide ssh access (once I figure out how to get ssh working on Solaris) to you, once I know your static IP address or subnet range. It may be a few days to a week before I can do the actual installation, however. I dont have Solaris 9... so Lamar's plan sounds like the way to go However, I am can still built for '8 if Lamar and/or yourself get snowed under cheers Mark ---(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] SQL flagger
THe SQL Flagger is only required for Intermediate SQL. SQL'92 23.4 says Entry SQL may, but are not required to. This said, it is a nice to have feature for the reasons that Peter pointed out. But as I understand it, this is a sort of warning feature, and depending on the "extent of checking" option may be just something that the parser itself detects (Sysntax only) or something we detect in the analyzer code (catalog lookup). The second one has security issues (the standard suggests using a specific Information Schema) so we may want to avoid it for now. Basically we would issue a FLAGGER message, if "level of flagging" is set to "Entry SQL Flagging" every time the parser finds a clause that is not Entry SQL. Similarly for non Intermediate SQL constructs if level is "Intermediate SQL Flagging". We would, of course, issue a FLAGGER message for all our PostgreSQL specific extensions in any level (if Flagging enabled). If I understood it correctly, we only need a new elog level and add a few elog calls in some of gram.y clauses... Regards, Fernando Tom Lane wrote:> Peter Eisentraut <[EMAIL PROTECTED]> writes: The SQL standard requires conforming implementations to provide an "SQL flagger" facility ... I think we could implement this with relatively little intrusion if we create an interface routine, say SQLFlagger(), which takes the entire parsetree as its argument can then analyze the syntax in as much detail as it likes. (Of course that function would only be called if a certain Boolean flag is set.) But a few syntax elements would need to checked right within gram.y, such as the omission of the drop behavior or the use of TEMP vs. TEMPORARY, which is resolved right in the parser and cannot be detected later. Should we implement this? I think we would be better off to implement this as a standalone program rather than as a backend mode option. In general, gram.y's behavior should never depend on any runtime variables. If it does, you get inconsistent results from SET var = val ; ... other stuff ... (one query string) compared to SET var = val ... other stuff ... (two query strings), because the whole query string is fed through gram.y before any of it is executed. Plan B, if you really want to do this in the backend, would be to alter gram.y's output trees so that all the non-spec constructs are still recognizable in the raw parse tree, and any conversions needed are done in analyze.c's processing (which would also be the place to issue the flagger warnings). This is not necessarily a bad idea; I've always thought that we do too much work in gram.y anyway. But you will be fighting a permanent rear-guard action to keep people from re-introducing variant syntaxes by quick gram.y hacks. In general I like the idea of a standalone program better, however. It would be able to have its own grammar tuned to its needs. I don't think there would be much maintenance problem introduced thereby, since presumably the flagger's grammar is driven by the spec and won't need to change when we change what Postgres accepts. 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 -- Fernando Nasser Red Hat - Toronto E-Mail: [EMAIL PROTECTED] 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] A modest proposal for a FAQ addition
Tom Lane wrote: > Ian Barwick <[EMAIL PROTECTED]> writes: > > On Sunday 12 January 2003 17:55, Bruce Momjian wrote: > >> I can't say "don't use CHAR(n)" because there are valid reasons to use > >> it. > > > I think what Tom is saying is "always use VARCHAR(n) unless you know > > for sure CHAR(n) is what you want, because if you slept through that part of > > the SQL course CHAR(n) is not what you might think." > > Yes. It is not clear from either the FAQ or the documentation that > CHAR() should not be one's default choice for a character field. I think part of our problem is that we say CHAR() first, then VARCHAR(), in the docs and the FAQ. This of course suggests to look at CHAR() first, then VARCHAR(), which is wrong. I have fixed the FAQ, and now the SGML docs. I think this will help. -- 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] copying perms to another user
Christopher Kings-Lynne writes: > We have roles? Until two days ago I was under the impression that roles were schema objects, but apparently this is not the case, and it seems that roles are really just an extension of our group concept. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Anyone have a fresh Solaris 8 SPARC system to create
Lamar Owen wrote: On Wednesday 15 January 2003 09:20, Justin Clift wrote: Sound like a plan? Will also need someone else with a Solaris 8 SPARC system to try the packages out too, just in case there are weird library dependencies happening that might catch us out. I have access to several (two dozen) currently unused Ultra30 systems. I can install Sol8 on one and Sol9 on another and provide ssh access (once I figure out how to get ssh working on Solaris) to you, once I know your static IP address or subnet range. It may be a few days to a week before I can do the actual installation, however. Wow, thanks Lamar. *That's* about as good an offer as I was hoping for. Mark, I can still teach you how to package stuff if you want. In this instance, having direct remote access to systems and being able to ensure things are 100% fresh and correct is that bit safer, as well as having other systems to test against. The easiest way to get OpenSSH up and running on a new Solaris box is to follow the instructions at: http://www.sunfreeware.com/openssh.html He provides packages there for just about everything, although you will need to download the official Solaris patch from the sunsolve.sun.com site that adds the /dev/random and urandom devices to the device tree. It's all pretty straightforward. :-) Can't wait! (But am going to have to). ;-) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(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] Anyone have a fresh Solaris 8 SPARC system to create
Justin Clift writes: > Also, am wondering if learning how to do "cross compiling" instead might > be worthwhile. Don't yet know anything about it, but it gets mentioned > in a lot of documents. The hard part about cross-compiling is getting a cross-compiler (especially if you have to build it yourself). After that it might be as easy as running 'configure --host=toaster ...'. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Oracle rant
I just wanted to post this note. I have been in Oracle hell for four days now, and in between the 5 minutes of work and the hours of watings, dealing with table spaces, extents, and all that, I just keep thinking about how much easier PostgreSQL is to work with. We all may bitch and moan about bugs and stuff, but my project would have been easier with PostgreSQL. Has anyone ever noticed that Oracle has all these nice little arcane ways to fail? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Oracle rant
On Wed, 15 Jan 2003, mlw wrote: > I just wanted to post this note. > > I have been in Oracle hell for four days now, and in between the 5 > minutes of work and the hours of watings, dealing with table spaces, > extents, and all that, I just keep thinking about how much easier > PostgreSQL is to work with. > > We all may bitch and moan about bugs and stuff, but my project would > have been easier with PostgreSQL. > > Has anyone ever noticed that Oracle has all these nice little arcane > ways to fail? Yes. I was doing some work with a company. I wanted to introduce Postgres. They're traditionally an oracle shop. "Our Oracle DBAs don't know Postgres, we're going to have to employ *another* DBA". No they don't. :-) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Oracle rant
Gavin Sherry wrote: On Wed, 15 Jan 2003, mlw wrote: I just wanted to post this note. I have been in Oracle hell for four days now, and in between the 5 minutes of work and the hours of watings, dealing with table spaces, extents, and all that, I just keep thinking about how much easier PostgreSQL is to work with. We all may bitch and moan about bugs and stuff, but my project would have been easier with PostgreSQL. Has anyone ever noticed that Oracle has all these nice little arcane ways to fail? Yes. I was doing some work with a company. I wanted to introduce Postgres. They're traditionally an oracle shop. "Our Oracle DBAs don't know Postgres, we're going to have to employ *another* DBA". No they don't. :-) This is the truth, we have had an oracle box for two and a half years, we have had 4 PostgreSQL boxes with it. The Oracle system is on a 4 CPU Sun box. The PostgreSQL systems are on 2 CPU PIII boxes. We had "certified oracle DBA"s setup the oracle box. I setup the PostgreSQL boxes. The PostgreSQL boxes NEVER had an unscheduled interruption in service. The Oracle system stops from time to time because of various arcane reasons. You get the error message, look it up on alltheweb.com, and fix it. The whole system is bogus. It DEMANDS a full time DBA. PostgreSQL does not.
Re: [HACKERS] inet regression test
Rod Taylor <[EMAIL PROTECTED]> writes: > Looks like some ORDER BY statements would be useful. To do what? Those queries should already be producing indexscan plans. If you're not getting the expected answers, there is something that needs to be fixed, not papered over. Please try create index inet_idx1 on inet_tbl(i); set enable_seqscan to off; explain select * from inet_tbl where i<<'192.168.1.0/24'::cidr; 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] inet regression test
If you get it working, I can remove the ORDER BY's I added. --- Tom Lane wrote: > Rod Taylor <[EMAIL PROTECTED]> writes: > > Looks like some ORDER BY statements would be useful. > > To do what? Those queries should already be producing indexscan plans. > If you're not getting the expected answers, there is something that > needs to be fixed, not papered over. > > Please try > > create index inet_idx1 on inet_tbl(i); > set enable_seqscan to off; > explain select * from inet_tbl where i<<'192.168.1.0/24'::cidr; > > 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Oracle rant
The Oracle system stops from time to time because of various arcane reasons. You get the error message, look it up on alltheweb.com, and fix it. The whole system is bogus. It DEMANDS a full time DBA. PostgreSQL does not. I could be accused of being cynical here (gosh)... but I think thats the whole idea - (hook'em with product and leverage "consulting" or "expert dba"..). One could be excused for thinking that "its all about money". Once upon a time I did the Oracle 7.3 certification thing , however I subsequently I feel that I really dont *need* to buy into this "Dba Guild" mentality that the whole business seemed to be about (i.e. arcane little "need to know" things that trap all but the initiated... and of course certification is all about *being* the initiated...oh...and... maybe the exam fees help perpetuate this thing too...). Thanks to you guys for providing the opportunity to share this ;-) Mark ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] inet regression test
regression=# regression=# regression=# create index inet_idx1 on inet_tbl(i); CREATE INDEX regression=# set enable_seqscan to off; SET regression=# explain select * from inet_tbl where i<<'192.168.1.0/24'::cidr; QUERY PLAN --- Index Scan using inet_idx1 on inet_tbl (cost=0.00..4.68 rows=7 width=64) Index Cond: ((i > '192.168.1.0/24'::inet) AND (i <= '192.168.1.255'::inet)) Filter: (i << '192.168.1.0/24'::inet) (3 rows) regression=# select * from inet_tbl where i<<'192.168.1.0/24'::cidr; c|i +-- 192.168.1.0/24 | 192.168.1.0/25 192.168.1.0/24 | 192.168.1.255/25 192.168.1.0/24 | 192.168.1.226 (3 rows) On Wed, 2003-01-15 at 14:58, Tom Lane wrote: > Rod Taylor <[EMAIL PROTECTED]> writes: > > Looks like some ORDER BY statements would be useful. > > To do what? Those queries should already be producing indexscan plans. > If you're not getting the expected answers, there is something that > needs to be fixed, not papered over. > > Please try > > create index inet_idx1 on inet_tbl(i); > set enable_seqscan to off; > explain select * from inet_tbl where i<<'192.168.1.0/24'::cidr; > > regards, tom lane -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] inet regression test
With Bruce's patch came a few others -- plus a recompile with all updates. > ... and that's the expected result. So why'd you get a different result > while running the regression test? Curiouser and curiouser... -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] inet regression test
On Wed, 2003-01-15 at 15:29, Tom Lane wrote: > Rod Taylor <[EMAIL PROTECTED]> writes: > > With Bruce's patch came a few others -- plus a recompile with all > > updates. > > Which patch exactly? The regression test was still passing for me > as of yesterday's sources plus the large planner commit I just made. > I'm resyncing to CVS tip at the moment ... Last update was about 5 minutes after Bruce's header fix went into place. -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] inet regression test
Rod Taylor <[EMAIL PROTECTED]> writes: > With Bruce's patch came a few others -- plus a recompile with all > updates. Which patch exactly? The regression test was still passing for me as of yesterday's sources plus the large planner commit I just made. I'm resyncing to CVS tip at the moment ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] inet regression test
Rod Taylor <[EMAIL PROTECTED]> writes: > Index Scan using inet_idx1 on inet_tbl (cost=3D0.00..4.68 rows=3D7 > width=3D64) >Index Cond: ((i > '192.168.1.0/24'::inet) AND (i <=3D > '192.168.1.255'::inet)) >Filter: (i << '192.168.1.0/24'::inet) > (3 rows) That's the expected plan ... > regression=3D# select * from inet_tbl where i<<'192.168.1.0/24'::cidr; >c|i=20 > +-- > 192.168.1.0/24 | 192.168.1.0/25 > 192.168.1.0/24 | 192.168.1.255/25 > 192.168.1.0/24 | 192.168.1.226 > (3 rows) ... and that's the expected result. So why'd you get a different result while running the regression test? Curiouser and curiouser... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] copying perms to another user
Peter Eisentraut wrote: > Christopher Kings-Lynne writes: > > > We have roles? > > Until two days ago I was under the impression that roles were schema > objects, but apparently this is not the case, and it seems that roles are > really just an extension of our group concept. Yep. We have already beefed up group handling quite a bit in the past few releases, so if we can take it the extra steps needed, we can just make ROLE and GROUP synonymous and be done with it. I think the one missing item mentioned was for group ownership of an object. However, if we give group _permission_ to the object, I am not sure why ownership is an issue. Are there certain permission we can't give to the group? -- 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] inet regression test
Rod Taylor <[EMAIL PROTECTED]> writes: > Last update was about 5 minutes after Bruce's header fix went into > place. Hm. I just finished verifying that CVS tip builds and passes cleanly on both HPUX and Linux (Red Hat 8.0). So either you've got a build error (did you do a "make clean" after your last update?) or there's some really weird platform dependency involved. What's your platform again? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] inet regression test
On Wed, 2003-01-15 at 16:07, Tom Lane wrote: > Rod Taylor <[EMAIL PROTECTED]> writes: > > Last update was about 5 minutes after Bruce's header fix went into > > place. > Hm. I just finished verifying that CVS tip builds and passes cleanly > on both HPUX and Linux (Red Hat 8.0). So either you've got a build > error (did you do a "make clean" after your last update?) or there's > some really weird platform dependency involved. What's your platform > again? I do a make distclean. FreeBSD 4.7 -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] inet regression test
Rod Taylor <[EMAIL PROTECTED]> writes: > On Wed, 2003-01-15 at 16:07, Tom Lane wrote: >> Hm. I just finished verifying that CVS tip builds and passes cleanly >> on both HPUX and Linux (Red Hat 8.0). So either you've got a build >> error (did you do a "make clean" after your last update?) or there's >> some really weird platform dependency involved. What's your platform >> again? > I do a make distclean. > FreeBSD 4.7 I'm still not able to duplicate any problem. Any other FreeBSD folk see inet regression failures in CVS tip? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] psql and readline
Eric B.Ridge writes: > What about expanding the history capabilities of psql's history command > (\s) to include something more bash/tcsh-like? For example: > !insert >-- execute the last command that began with "insert" > !23 >-- execute item #23 in my history If you peruse the documentation of the readline and history libraries you should find that those features already exist. For example, you can use C-r and C-s to search through the history. AFAIK, bash just uses readline as is, so anything that works there should work for psql as well. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] SQL flagger
Fernando Nasser writes: > THe SQL Flagger is only required for Intermediate SQL. SQL'92 23.4 says Entry > SQL may, but are not required to. SQL 92 is obsolete. In SQL 99 and later it's a core feature. > If I understood it correctly, we only need a new elog level and add a few elog > calls in some of gram.y clauses... As was already mentioned, you cannot evaluate run-time parameters (which the flagger would be) in gram.y because of some transaction issues. You need to do it in the analyze phase after the parser. "A few" is also an optimistic statement. While the majority of the utility commands can be rejected outright, getting the details right to a usable degree on the rest is tricky. -- Peter Eisentraut [EMAIL PROTECTED] ---(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] Oracle rant
> (i.e. arcane > little "need to know" things that trap all but the initiated... So, for postgres, that means: - a good thing the autovacuum thingy is coming along - postgres should auto-tune itself - the *cost could perhaps be adjusted after some statistics have been collected, and there should be some sensible way to determine an optimal setting for the famous shared_buffers (and the default should be something that gets reasonable performance on common cases) No, I don't expect the second one soon - I know how hard it is. No, I'm not debating that PostgreSQL is not much, much, much easier to administrate and set up than Oracle. I'm just saying that there are *some* small arcane details in postgres, too (although, at least, they don't affect stability, just performance). cheers -- vbi -- pub 1024D/92082481 2002-02-22 Adrian von Bidder Key fingerprint = EFE3 96F4 18F5 8D65 8494 28FC 1438 5168 9208 2481 signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Oracle rant
Adrian 'Dagurashibanipal' von Bidder wrote: I'm just saying that there are *some* small arcane details in postgres, too (although, at least, they don't affect stability, just performance). Indeed you are right... Pg has its own collection of arcane details too, but hopefully the culture of Postgesql (in common with all open source projects) is to "expose and educate" rather than "confine to a group of the initiated". Does that sound better ? ( i.e no so rabid Oracle bashing) Cheers mark ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [BUGS] Bug #876: Bugs Inserts Arrays
[EMAIL PROTECTED] writes:
> Sample Code
> create table teste(serie integer,aula text[][]);
> //it´s ok when insert this
> insert into teste values (1,'{{"004","009"},{"009"},{""},
> {"001","002"}}');
> //But when I insert this..
> insert into teste values
> (1,'{{"004","009","002"},{"009","001"},{""},{"001","002"}}');
> ^^ -> lost information ^^ -> array dimension last
>entrance.
Yeah, this seems to be a long-standing misbehavior. I get the same
results as far back as PG 7.0 (the oldest version I have running):
play=> select * from teste;
serie |aula
---+-
1 | {{"004","009"},{"009",""},{"",""},{"001","002"}}
1 | {{"004","009"},{"009","001"},{"",""},{"001","002"}}
(2 rows)
On the other hand, the last time I fixed what seemed an obvious bug in
the array-value parser, I got flak for it. Anyone want to defend the
present behavior?
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] inet regression test
> >> Hm. I just finished verifying that CVS tip builds and passes cleanly > >> on both HPUX and Linux (Red Hat 8.0). So either you've got a build > >> error (did you do a "make clean" after your last update?) or there's > >> some really weird platform dependency involved. What's your platform > >> again? > > > I do a make distclean. > > > FreeBSD 4.7 > > I'm still not able to duplicate any problem. Any other FreeBSD folk see > inet regression failures in CVS tip? Unable to reproduce this on 5.0 with PostgreSQL HEAD as of 8:10PST. -sc -- Sean Chittenden ---(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] inet regression test
On Wed, 2003-01-15 at 20:15, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > On Wed, 2003-01-15 at 16:07, Tom Lane wrote:
> >> Hm. I just finished verifying that CVS tip builds and passes cleanly
> >> on both HPUX and Linux (Red Hat 8.0). So either you've got a build
> >> error (did you do a "make clean" after your last update?) or there's
> >> some really weird platform dependency involved. What's your platform
> >> again?
>
> > I do a make distclean.
>
> > FreeBSD 4.7
>
> I'm still not able to duplicate any problem. Any other FreeBSD folk see
> inet regression failures in CVS tip?
Comes out fine now (~ 12:30 EST5EDT). I'll keep an eye out, but it must
be something else I was doing at the time that threw it off (compiler
glitch?)
Ran the below:
make distclean > /dev/null
cvs update -dP
CFLAGS="-O2 -Wall -Wmissing-prototypes -Wmissing-declarations"
export CFLAGS
PGDIR=`pwd | sed -E 's/(.*)\/pgsql([^\/]+)$/db\2/g'`
export PGDIR
./configure --prefix=${HOME}/work/postgresql/${PGDIR} \
--enable-depend \
--enable-debug \
--enable-cassert \
--with-pgport=`perl -e 'print int(rand(a) * 999) + 6000;'`
make install > /dev/null
make check
--
Rod Taylor <[EMAIL PROTECTED]>
PGP Key: http://www.rbt.ca/rbtpub.asc
signature.asc
Description: This is a digitally signed message part
