Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
On Thu, 2003-06-05 at 11:23, Josh Berkus wrote:
4) Does anyone else have any comments on the proposed re-ordering?
I think this was touched on before, but was there a final determination
of the ordering of the show all command? I'm hoping that will return
in the new order of the postgresql.conf
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] [GENERAL] Anonymous CVS access
cvsweb.cgi is fixed ... working on the rest tonight ... On Wed, 4 Jun 2003, Joe Conway wrote: (moving to HACKERS) Bruno Wolff III wrote: The CVS server seems to be working again, but logging in with an empty password doesn't work. The web interface to anonymous CVS doesn't work either. [EMAIL PROTECTED] bruno]$ cvs -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot login (Logging in to [EMAIL PROTECTED]) CVS password: /projects/cvsroot: no such repository cvs [login aborted]: authorization failed: server anoncvs.postgresql.org rejected access Yeah, I'm still getting failures on cvsup also: # cvsup -L 2 /root/postgres.cvsup Parsing supfile /root/postgres.cvsup Connecting to cvsup.postgresql.org Cannot connect to cvsup.postgresql.org: Connection refused Will retry at 21:14:17 Joe ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Status during copy [patch]
Added to TODO: o Have COPY return number of rows loaded/unloaded This is a backend change to return the number of rows affected as part of the command status string returned, like we do with UPDATE/INSERT/DELETE. --- Jim C. Nasby wrote: On Mon, Jun 02, 2003 at 03:23:26PM -0400, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: How do people feel about this patch? Currently COPY doesn't even return a line count of the number of lines processed, while this patch would make psql \copy produce date/time and count every 1000 rows, then print a similar completion message. Seems much too noisy for me. That would be appropriate behavior in a GUI, but psql is not and never will be a GUI. Martijn's concern about hacking the behavior depending on where stderr points demonstrates exactly why we don't want to do this. What about an option to enable it? Or a command to find out how many rows a running copy command has imported? It would be very handy to be able to know how far along a large copy operation is. -- Jim C. Nasby (aka Decibel!)[EMAIL PROTECTED] Member: Triangle Fraternity, Sports Car Club of America Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? -- 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] Groups and roles
I'm looking at representing privileges granted to groups in the information schema. For that purpose I would like to use the views that the standard defines for roles. Therefore I ask whether everyone agrees that groups and roles are basically equivalent concepts (and perhaps that we might in the future strive to make groups more compatible with the roles as defined in the SQL standard). Or does anyone see that roles might be implemented separately from groups sometime? -- 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] Wrong version of jdbc in 7.3.3 rpms
Lamar, I would prefer that it stay in the main source tree, (however there is no compelling reason for this) and that we have a seperate rpm that we can make, however Barry may have a different opinion. My reasoning for keeping it in the main source tree is that it makes it easier for people to download everything and have it run right out of the box so to speak. Having people going to another site to get the rpm, or jar is a bit of a hassle. FYI, all we really are doing it putting the jar inside the rpm, and having rpm install it. There's really nothing else to it. Aside from knowing the version number we don't even use the headers. Dave On Fri, 2003-06-06 at 11:33, Lamar Owen wrote: On Thursday 05 June 2003 11:39, Barry Lind wrote: Does anyone know why apparently the 7.3beta1 version of the jdbc drivers are what is included in the 7.3.3 rpms? The pg73b1jdbc3.jar file is very old (it is the 7.3 beta 1 version). What RPMs are you using? You should contact whoever produced those RPMs to get them built with the current version. The 'official' version is the source code that is tagged with the 7.3.3 freeze label (which is the version that is currently posted on the jdbc.postgresql.org web site) I am whoever. :-) I have not synced up with the version on jdbc.postgresql.org (primarily because I didn't know about there being a newer version). I do not have a JDK installed here, so I don't build the JDBC driver from source. So, I'll blame my own bit rot. Since the postgresql-jdbc RPM has no dependencies and is a distribution-independent RPM, I'll roll a new one. This won't require a rebuild on all the distributions supported, since we're talking distribution independent jars. However, I wouldn't mind pulling the JDBC subpackage out of the main set entirely, and having a separate RPM distribution for that. You could maintain that yourself easily enough. I can even give you a starting spec file, and the JDBC driver could have a separate release schedule, which might be appropriate anyway. Going the one obvious next step forward, is there a compelling reason to include the JDBC client as part of the main tarball, rather than a separate project (ODBC is separate, as is the C++ and Perl clients) (and the same thing can be said for the Python client)? Does the JDBC client need backend source code, or is it happy being built with just the necessary fe protocol headers? (I'm thinking out loud here -- I can see a reason for the JDBC driver to have a separate release schedule from the main tarball, but I'm not saying 'JDBC is a problem child! Let's yank it because I don't want to deal with it!'). Barry, what would be your preference? What would best serve JDBC users? (other than me installing all the software necessary to build the JDBC from source -- this requires non-vanilla software in the form of the JDK, as well as the build environment that the makefiles want, and with me not being a Java developer at this time, I wouldn't necessarily be up on what is considered the 'canonical' development or runtime environments. With the other portions of PostgreSQL, nothing beyond the stock distribution is required for build.) I think it would best serve the users for an active JDBC developer to make that distribution. Please advise how you would like to handle this. -- Dave Cramer [EMAIL PROTECTED] -- Dave Cramer [EMAIL PROTECTED] fastcrypt ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Result of a query(Need Help)
Hi! Could anyone tell me where excatly the result of a query is stored after the query is passed to pg_exec_query_string function and before it is printed. Please give me information about the Data structures where the result is stored Bye Srikanth ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Problems with renaming a column
As an interface writer, do you prefer dealing with functions like pg_get_constraintdef() or a view like the information schema provides? I would think it is easier to get the information from the information schema. That's most like what we're doing now getting the information from the pg_* tables and istm it's easier to browse the information The information schema is not appropriate for the task, but an information like schema would probably be best. Won't happen for this release, but I'm willing to take a look at it for the next. (He's on holiday for the next few days btw which is why I'm chiming in) I see.. Thanks. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Testing the return value of fclose() in the backend
Added to TODO: * Add checks for fclose() failure --- Gavin Sherry wrote: On Fri, 30 May 2003, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Gavin Sherry wrote: There are various places in the backend, such as FreeFile(), where the return value of fclose() is not tested. We are not checking fclose, probably because fclose failures are quite rare. Should we be concerned? Probably. Closing a valid file descriptor in itself can't provoke any error that I can imagine, but fclose() also implies fflush() --- so if you have written data that hasn't yet been forced out of the stdio buffers then out-of-disk-space is certainly a foreseeable failure. Yes. I think I brought that up in my original email. Heap access/WAL routines 'should not' suffer an fclose() problem because of fsync() calls. But this isn't necessarily the case for COPY. fclose failure on an open-for-read-only file seems like Assert() material; it can't happen. Right. If this generates an error, there are probably more serious issues. Gavin ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] default locale considered harmful? (was Re: [GENERAL]
On Thu, 5 Jun 2003, Alvaro Herrera Munoz wrote: On Thu, Jun 05, 2003 at 09:44:21AM -0600, scott.marlowe wrote: On Thu, 5 Jun 2003, Nigel J. Andrews wrote: Everything Nigel just wrote plus one thing. If it comes down to it, we could always require a --locale setting and refuse to initdb without it. That way, whether it's in an RPM or from source, somebody somewhere along the line has to choose something. Yeah, that way the RPM guys would put the --locale taking the locale from the environment and you're back to ground zero. There's no point in forcing things down the throat of users using this kind of mechanisms, because someone is going to automate the thing along the way. What is needed is a way to make the user aware of his system's configuration. But initdb IS different since it takes so much effort to change locales once you've set up a cluster. Unless the other locales can offer similar performance to the C locale, I would suggest that we make the C locale the default. IF they need something else they can change it after initdb. If you're an old time user, you know how to set locale, and the implications of a non-C locale, so a default of C is no big deal, and you're likely to be looking at initdb to see the message telling you it's using C. If you're a beginner you likely need or want a locale of C, but don't know it, and don't know that you can't change it without reinitdbing. My only concern with going with a default locale of C is if it causes a problem with data integrity (i.e. constraints that only behave right in a certain locale). ---(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] Proposal to Re-Order Postgresql.Conf, part II
4) Does anyone else have any comments on the proposed re-ordering? Since we're painting a shed, does it make sense to put the items in alphabetical order for each section? -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Postgres config file: autocommit = off
On Mon, Jun 02, 2003 at 03:14:33PM -0400, Bruce Momjian wrote: Oh, yes, sorry, I was confusing psql -c and -f. -c is clearly different. But if -f follows the ~/.psqlrc variable, then you'll definitively will have to put back the SET AUTOCOMMIT to off to scripts... (vacuumdb and clusterdb seem to be the only ones left, plus the ones in contrib) -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) La persona que no quería pecar / estaba obligada a sentarse en duras y empinadas sillas/ desprovistas, por cierto de blandos atenuantes (Patricio Vogel) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
