Re: [HACKERS] COPY syntax
Bruce Momjian writes: > Peter Eisentraut wrote: > > Bruce Momjian writes: > > > > COPY table TO STDOUT WITH BINARY OIDS; > > > > Shouldn't the "binary", being an adjective, be attached to something? > > > Uh, it is attached to WITH? > > Attached to a noun phrase, like "mode" or "output". Note that all the > > other things the typically follow WITH in any command are nouns. > Should we add an optional MODE after BINARY? Are you serious? You'd like to mess up the COPY syntax even further for a purely grammatical reason! A good few months ago I put formward an idea to change (well migrate really) to "COPY TABLE" rather than "COPY" - this would allow a well designed and thoughtout syntax for the new version while retaining old compatibility. egards, Lee Kindness. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PL/Perl and Perl 5.8
Neil Conway <[EMAIL PROTECTED]> writes: > Well, I'm not happy with defining _GNU_SOURCE, but I don't agree that > just saying "it's a Perl problem" is a good answer. That may well be > the case, but it doesn't change the fact that a lot of people are > running 5.8.0, and will probably continue to do so during the 7.3 > lifecycle[1]. We work around braindamage on other systems -- strictely > speaking, we could say "the snprintf() bug with 64-bit Solaris is a > Sun libc problem", for example. Well, I'm not opposed to a workaround in principle; I'm just unconvinced that this is the right solution. Do we understand what is broken and why -D_GNU_SOURCE fixes it? 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] Current CVS has strange parser for float type
wow=# select 5.3::float; ERROR: Bad float8 input format '5.3' wow=# select 5.3::float8; ERROR: Bad float8 input format '5.3' wow=# select 5.3::float4; ERROR: Bad float4 input format '5.3' wow=# select 5.3e-1::float4; ERROR: Bad float4 input format '0.53' wow=# select -5.3e-1::float4; ERROR: Bad float4 input format '0.53' wow=# select -5.3::float4; ERROR: Bad float4 input format '5.3' wow=# select 5.3e2::float4; ERROR: Bad float4 input format '532.222' wow=# select version(); version - PostgreSQL 7.3b2 on i386-unknown-freebsd4.6, compiled by GCC 2.95.3 (1 row) Very strange or I missed something? This 'feature' appears only on FreeBSD, Linux works fine. -- Teodor Sigaev [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] default namespace (schema) confusion
I have been looking forward to schemas (namespaces) for sometime.
I had not been able to decipher the schema symantics necessary for a
default schema, until I hacked the source a bit.
Now I know that the rules to get a default schema using
db_user_namespace = true
search_path = '$user,public'
in postgresql.conf
the user logs in as
psql testdb testuser
but the userid is really
testuser@testdb
if a schema named "testuser@testdb" exists
the user gets it as a default schema
otherwise the default schema is public;
and if the user is a global user
the login is
psql testdb globuser@
and the required schema is "globuser"
this use of "@" in the default schema is a bit counter intuitive
so I offer the following patch against CVS
it tries the userid as found in pg_user,
then strips off the @db stuff if possible
--- src/backend/catalog/namespace.c Thu Oct 17 21:23:34 2002
+++ src/backend/catalog/namespace_2.c Thu Oct 17 21:21:52 2002
@@ -1386,8 +1386,10 @@
if (HeapTupleIsValid(tuple))
{
char *uname;
+char *uname_local;
uname = NameStr(((Form_pg_shadow)
GETSTRUCT(tuple))->usename);
namespaceId =
GetSysCacheOid(NAMESPACENAME,
CStringGetDatum(uname),
0, 0, 0);
@@ -1396,7 +1398,25 @@
!intMember(namespaceId,
oidlist) &&
pg_namespace_aclcheck(namespaceId, userId,
ACL_USAGE) == ACLCHECK_OK)
+{
oidlist = lappendi(oidlist,
namespaceId);
+}
+else
+{
+ uname_local = (char *)
malloc(strlen(uname)); + strcpy
(uname_local,uname);
+ uname_local =
strtok(uname_local,"@");
+ namespaceId =
GetSysCacheOid(NAMESPACENAME,
+
CStringGetDatum(uname_local),
+
0, 0, 0);
+ if (OidIsValid(namespaceId) &&
+ !intMember(namespaceId,
oidlist) &&
+
pg_namespace_aclcheck(namespaceId, userId,
+
ACL_USAGE) == ACLCHECK_OK)
+ oidlist =
lappendi(oidlist, namespaceId);
+ free(uname_local);
+}
+
}
}
else
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] default namespace (schema) confusion
Carl Anderson <[EMAIL PROTECTED]> writes: > this use of "@" in the default schema is a bit counter intuitive > so I offer the following patch against CVS Hmm, this seems like a wart, but then the db_user_namespace feature is an acknowledged wart already. I think I'd be willing to hold still for this if it happens only when db_user_namespace is on. Comments anyone? > + uname_local = (char *) > malloc(strlen(uname)); + strcpy > (uname_local,uname); Use pstrdup, please. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] default namespace (schema) confusion
Tom Lane wrote: > Carl Anderson <[EMAIL PROTECTED]> writes: > > this use of "@" in the default schema is a bit counter intuitive > > so I offer the following patch against CVS > > Hmm, this seems like a wart, but then the db_user_namespace feature > is an acknowledged wart already. > > I think I'd be willing to hold still for this if it happens only when > db_user_namespace is on. Comments anyone? I dislike double-testing the username in schema areas but not other places. Seems if we do it, we should do it consistently for all username references, or not at all. -- 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] orderRules() now a bad idea?
Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Tom Lane writes: > >> It looks like NAME comparison uses strcmp (actually strncmp). So it'll > >> be numeric byte-code order. > >> There's no particular reason we couldn't make that be strcoll instead, > >> I suppose, except perhaps speed. > > > But how will this work when we have per-column/datum collation order? > > And what about languages that don't have any useful collation order for > > their alphabets (far east)? ISTM that a globally viable feature of this > > sort would have to sort by something numeric. > > I'm confused; are you saying that NAME's sort behavior is good as-is? > If not, what would you have it do differently? Yes, exotic ordering of rules just doesn't seem warranted. I think it should match the ordering of pg_class.name, which is strcmp() already. Let's do ASCII ordering (strcmp) and see how things go. -- 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
Re: [HACKERS] "COPY FROM" recognize \xDD sequence - addition to
Gavin Sherry wrote: > On Wed, 16 Oct 2002, Tom Lane wrote: > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > Right now we assume \XXX is octal. We could support \x as hex because > > > \x isn't any special backslash character. However, no one has ever > > > asked for this. Does anyone else think this would be benficial? > > > > Well, it seems pretty localized and harmless. If it lets us import > > Sybase dumps, doesn't that boost our plans for world domination? ;-) > > Can we add: > > o World Domination > > To the TODO list? That's already in there, but in subliminal type. -- 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] COPY syntax
Lee Kindness wrote: > Bruce Momjian writes: > > Peter Eisentraut wrote: > > > Bruce Momjian writes: > > > > > COPY table TO STDOUT WITH BINARY OIDS; > > > > > Shouldn't the "binary", being an adjective, be attached to something? > > > > Uh, it is attached to WITH? > > > Attached to a noun phrase, like "mode" or "output". Note that all the > > > other things the typically follow WITH in any command are nouns. > > Should we add an optional MODE after BINARY? > > Are you serious? You'd like to mess up the COPY syntax even further > for a purely grammatical reason! > > A good few months ago I put formward an idea to change (well migrate > really) to "COPY TABLE" rather than "COPY" - this would allow a well > designed and thoughtout syntax for the new version while retaining old > compatibility. I don't like the added MODE either, but Peter doesn't seem to like BINARY alone, though it seems fine to me. -- 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] orderRules() now a bad idea?
Tom Lane writes: > I'm confused; are you saying that NAME's sort behavior is good as-is? > If not, what would you have it do differently? What I am primarily saying is that ordering the rule execution order alphabetically is not a really good solution. Consequently, I would not go out of my way to make code changes to pursue this goal. -- 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] COPY syntax
Lee Kindness writes: > Are you serious? You'd like to mess up the COPY syntax even further > for a purely grammatical reason! We already "messed up" the COPY syntax in this release to achieve better user friendliness. I do not think it's unreasonable to review this goal from a variety of angles. > A good few months ago I put formward an idea to change (well migrate > really) to "COPY TABLE" rather than "COPY" - this would allow a well > designed and thoughtout syntax for the new version while retaining old > compatibility. Well, I am the first to agree that the current syntax is not well designed, but I must admit that I don't quite see what benefit simply adding "TABLE" would have. -- 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] PL/Perl and Perl 5.8
Neil Conway writes: > gcc -O2 -g -fpic -I. -I/usr/lib/perl/5.8.0/CORE -I../../../src/include -c -o >plperl.o plperl.c -MMD > In file included from /usr/lib/perl/5.8.0/CORE/op.h:480, > from /usr/lib/perl/5.8.0/CORE/perl.h:2209, > from plperl.c:61: > /usr/lib/perl/5.8.0/CORE/reentr.h:602: field `_crypt_struct' has incomplete type > /usr/lib/perl/5.8.0/CORE/reentr.h:747: confused by earlier errors, bailing out > make[3]: *** [plperl.o] Error 1 Can you post some snippets from the relevant code sections? Following one of the links that were posted I gathered that this is related to crypt_r(), whose prototype is not exposed on my system unless you use _GNU_SOURCE. But I don't see any _crypt_struct here. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] orderRules() now a bad idea?
Peter Eisentraut wrote: > Tom Lane writes: > > > I'm confused; are you saying that NAME's sort behavior is good as-is? > > If not, what would you have it do differently? > > What I am primarily saying is that ordering the rule execution order > alphabetically is not a really good solution. Consequently, I would not > go out of my way to make code changes to pursue this goal. Well, it seems to make the users happy, so that's good enough for me. There was particular concern from users about what values are returned when multiple rules or multi-statement rules are fired, and ordering them by ASCII order does give them the tools needed to get the job done. We already order NAME by strcmp, so I don't see how we are breaking anything by doing the same for rules. -- 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
Re: [HACKERS] Current CVS has strange parser for float type
Works here: test=> select 5.3::float; float8 5.3 (1 row) --- Teodor Sigaev wrote: > wow=# select 5.3::float; > ERROR: Bad float8 input format '5.3' > wow=# select 5.3::float8; > ERROR: Bad float8 input format '5.3' > wow=# select 5.3::float4; > ERROR: Bad float4 input format '5.3' > wow=# select 5.3e-1::float4; > ERROR: Bad float4 input format '0.53' > wow=# select -5.3e-1::float4; > ERROR: Bad float4 input format '0.53' > wow=# select -5.3::float4; > ERROR: Bad float4 input format '5.3' > wow=# select 5.3e2::float4; > ERROR: Bad float4 input format '532.222' > wow=# select version(); > version > - > PostgreSQL 7.3b2 on i386-unknown-freebsd4.6, compiled by GCC 2.95.3 > (1 row) > > Very strange or I missed something? > This 'feature' appears only on FreeBSD, Linux works fine. > > > -- > Teodor Sigaev > [EMAIL PROTECTED] > > > > ---(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 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] Cleanup of /contrib
I am cleaning up /contrib by adding "autocommit = 'on'" and making it more consistent. Should I be adding this too: -- Adjust this setting to control where the objects get created. SET search_path = public; and doing all object creation in one transaction, like /contrib/cube does? -- 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] Current CVS has strange parser for float type
On Thu, 2002-10-17 at 23:34, Teodor Sigaev wrote: > wow=# select 5.3::float; > ERROR: Bad float8 input format '5.3' Could it be something with locales ? Try: select 5,3::float; - Hannu ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PL/Perl and Perl 5.8
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Can you post some snippets from the relevant code sections? Following one > of the links that were posted I gathered that this is related to > crypt_r(), whose prototype is not exposed on my system unless you use > _GNU_SOURCE. But I don't see any _crypt_struct here. Yeah, the seems to be the culprit. Line 480 of reentr.h is part of the definition of a monster struct; the relevent field is: #ifdef HAS_CRYPT_R #if CRYPT_R_PROTO == REENTRANT_PROTO_B_CCD CRYPTD* _crypt_data; #else struct crypt_data _crypt_struct; #endif #endif /* HAS_CRYPT_R */ The "crypt_data" struct is defined in crypt.h, but only if _GNU_SOURCE is defined -- just like crypt_r(). Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---(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] Cleanup of /contrib
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I am cleaning up /contrib by adding "autocommit = 'on'" and making it > > more consistent. Should I be adding this too: > > > -- Adjust this setting to control where the objects get created. > > SET search_path = public; > > Yes, that would be a good idea. Without that, the objects might well > get created in the owning user's private schema; which most of the time > would be unhelpful. I'm not thrilled with having to edit the script > if you do happen to want them in a non-public schema, but I have not > thought of a better approach yet. (Anyone?) > > > and doing all object creation in one transaction, like /contrib/cube > > does? > > The one-transaction thing seems unnecessary to me, but if you like it... Some have it, some don't. I will make it consistent, at least. -- 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] Current CVS has strange parser for float type
Tom Lane wrote: > I think this is a consequence of the changes made a little while back > (by Peter IIRC?) in locale handling. It used to be that we deliberately > did *not* allow any LC_ setting except LC_MESSAGES to actually take > effect globally in the backend, and this sort of problem is exactly > why. I think we need to revert some aspects of that change. > > Bruce, this is a "must fix" open item ... Added. -- 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 P O S T G R E S Q L 7 . 3 O P E NI T E M S Current at ftp://momjian.postgresql.org/pub/postgresql/open_items. Required Changes --- Schema handling - ready? interfaces? client apps? Drop column handling - ready for all clients, apps? Get bison upgrade on postgresql.org for ecpg only (Marc) Fix vacuum btree bug (Tom) Fix client apps for autocommit = off Fix pg_dump to handle 64-bit off_t offsets for custom format (Philip) Fix local handling of floats Optional Changes Add schema dump option to pg_dump Add/remove GRANT EXECUTE to all /contrib functions? Missing casts for bit operations \copy doesn't handle column names COPY doesn't handle schemas COPY quotes all table names Documentation Changes - Move documation to gborg for moved projects ---(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] Current CVS has strange parser for float type
Hannu Krosing <[EMAIL PROTECTED]> writes: > On Thu, 2002-10-17 at 23:34, Teodor Sigaev wrote: >> wow=# select 5.3::float; >> ERROR: Bad float8 input format '5.3' > Could it be something with locales ? Oooh, bingo! On HPUX: regression=# select 5.3::float; float8 5.3 (1 row) regression=# set lc_numeric = 'de_DE.iso88591'; SET regression=# select 5.3::float; ERROR: Bad float8 input format '5.3' I think this is a consequence of the changes made a little while back (by Peter IIRC?) in locale handling. It used to be that we deliberately did *not* allow any LC_ setting except LC_MESSAGES to actually take effect globally in the backend, and this sort of problem is exactly why. I think we need to revert some aspects of that change. Bruce, this is a "must fix" open item ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Cleanup of /contrib
Bruce Momjian <[EMAIL PROTECTED]> writes: > I am cleaning up /contrib by adding "autocommit = 'on'" and making it > more consistent. Should I be adding this too: > -- Adjust this setting to control where the objects get created. > SET search_path = public; Yes, that would be a good idea. Without that, the objects might well get created in the owning user's private schema; which most of the time would be unhelpful. I'm not thrilled with having to edit the script if you do happen to want them in a non-public schema, but I have not thought of a better approach yet. (Anyone?) > and doing all object creation in one transaction, like /contrib/cube > does? The one-transaction thing seems unnecessary to me, but if you like it... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] default namespace (schema) confusion
Bruce Momjian <[EMAIL PROTECTED]> writes: > I dislike double-testing the username in schema areas but not other > places. Seems if we do it, we should do it consistently for all > username references, or not at all. What other places do we have an explicit dependence on the username? 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] default namespace (schema) confusion
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I dislike double-testing the username in schema areas but not other > > places. Seems if we do it, we should do it consistently for all > > username references, or not at all. > > What other places do we have an explicit dependence on the username? Uh, what about CREATE/ALTER/DROP USER, and pg_hba.conf. Of course, those are more admin, but isn't the schema also sort of admin too? I am also concerned about opening cases where a CURRENT_USER test doesn't match the user's schema. -- 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] COPY syntax
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Well, I am the first to agree that the current syntax is not well > designed, but I must admit that I don't quite see what benefit simply > adding "TABLE" would have. I think the idea was that "COPY TABLE ..." could have a new clean syntax without the warts of the current syntax. TABLE wouldn't be a noise word, but a trigger for a different syntax for what follows. However, COPY's feature set is inherently pretty wart-y. Even if we had a green field to design syntax in, where exactly is the improvement going to come, assuming that functionality has to stay the same? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Postgresql and multithreading
On Wed, 16 Oct 2002, Bruce Momjian wrote: > It may be optional some day, most likely for Win32 at first, but we see > little value to it on most other platforms; of course, we may be wrong. > I am also not sure if it is a big win on Apache either; I think the > jury is still out on that one, hence the slow adoption of 2.X, and we > don't want to add threads and make a mess of the code or slow it down, > which does often happen. Actually, Apache2 is both multi-process and multi-thread, even in the 'multi-thread' model ... I've played a bit with it, and it works at a sort of 'half way point' taking advantage of advantages of both ... in fact, I really wish someone would look at it seriously, since it mimics alot of what we do to start with ... old apache - one parent process (ie. postmaster) with child process (ie. postgres) actually handling the work new apache - one parent process (ie. postmaster) with child processes (ie. postgres) actually handling the work, with a twist .. each child process can handle x threaded processes so, in a heavily loaded web server, you might see 10 httpd processes running, each of which handling 15 threaded connections ... even getting away from multiple db connections per child process, I could see some other areas where multi-threading could be useful, assuming that my limited knowleddge of threading is remotely correct ... a big/cool one could be: distributed/clustered databases a database could be setup on multiple servers, where the tables are created as 'CREATE TABLE newtable ON SERVER serverb', so that when you connect to that table, the child process knows to auto-matically establish connections to the remote servers to pull data in this would also work for inter-database queries, that several ppl in the past have asked for ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Postgresql and multithreading
Bruce Momjian <[EMAIL PROTECTED]> writes: > Let me add one more thing on this "thread". This is one email in a long > list of "Oh, gee, you aren't using that wizz-bang new > sync/thread/aio/raid/raw feature" discussion where someone shows up and > wants to know why. Does anyone know how to address these, efficiently? Simple: respond to 'em all with a one-line answer: "convince us why we should use it". The burden of proof always seems to fall on the wrong end in these discussions. 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] v7.3 Branched ...
On Thu, 17 Oct 2002, Justin Clift wrote: > > Thomas Swan wrote: > > > > Justin Clift wrote: > > > > Ok. Wonder if it's worth someone creating a "PostgreSQL Powertools" > > > type of package, that includes in one download all of these nifty > > > tools (pg_autotune, oid2name, etc) that would be beneficial to have > > > compiled and already available. Kind of like "contrib" is (oid2name is > > > already there I know), but so people don't have to go hunting all over GBorg > > > to find the bits that they'd want. > > > > > That would be wonderful if it included some of the more stable tools / > > add-ons that have been removed from the main distribution or have > > existed independent of the main PostgreSQL development. > > Hi Thomas, > > Want to get it together? Just a thought, and I've included chris in this ... is there some way of setting up maybe a 'meta package' on Gborg that would auto-pull in and package stuff like this? For instance, in FreeBSD ports, you can make such that when you type in 'make', it just goes to other ports and builds/installs those ... Baring that, how about the ability to create a new category that is maintained by someone that various project maintains could 'cross-link' their projects into? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Various OS Binaries (Was: Re: [HACKERS] v7.3 Branched ...)
On a different note ... if anyone out there would like to maintain/package up binaries for various OS similar to what Lamar does with RPMs, I'd love to see us extend our binaries section on the ftp server ... On 16 Oct 2002, Larry Rosenman wrote: > On Wed, 2002-10-16 at 16:05, Rod Taylor wrote: > > On Wed, 2002-10-16 at 16:56, Robert Treat wrote: > > > Perhaps one could just create a "PostgreSQL Powertools" section on > > > techdocs, naming the packages and where to get them. This would > > > eliminate the need to maintain a package that just duplicates other > > > packages... > > > > Let ye-old package managers make a shell package which simply points to > > the others as dependencies. > Sort of like a meta-port? > > > > I'd be willing to do this for FreeBSD (think Sean? would help as well) > > if someone comes up with the list. > That would be useful, and port(s) for the rest of contrib as well (like > contrib/tsearch). > > :-) > > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] > US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 > > ---(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] orderRules() now a bad idea?
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane writes: >> I'm confused; are you saying that NAME's sort behavior is good as-is? >> If not, what would you have it do differently? > What I am primarily saying is that ordering the rule execution order > alphabetically is not a really good solution. Consequently, I would not > go out of my way to make code changes to pursue this goal. I think what you are really driving at is that you'd like to have some other mechanism than choice-of-rule-name for users to determine ordering of rule expansion. That's a fair enough objection, but you'd still need to get rid of orderRules() along the way. Unless you *like* ordering restrictions that were made purely for implementation convenience? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_dump and large files - is this a problem?
I have made the changes to pg_dump and verified that (a) it reads old files, (b) it handles 8 byte offsets, and (c) it dumps & seems to restore (at least to /dev/null). I don't have a lot of options for testing it - should I just apply the changes and wait for the problems, or can someone offer a bigendian machine and/or a 4 byte off_t machine? was integral. 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Postgresql and multithreading
On Wed, 16 Oct 2002, Anuradha Ratnaweera wrote: > On Wed, Oct 16, 2002 at 01:25:23AM -0400, Bruce Momjian wrote: > > Anuradha Ratnaweera wrote: > > > > > ... what I want to know is whether multithreading is likely to get > > > into in postgresql, say somewhere in 8.x, or even in 9.x? > > > > It may be optional some day, most likely for Win32 at first, but we see > > little value to it on most other platforms; of course, we may be wrong. > > In that case, I wonder if it is worth folking a new project to add > threading support to the backend? Of course, keeping in sync with the > original would be lot of work. Actually, if you go through the archives, there has been talk about what would have to be done to the main source tree towards getting threading included ... as well as a lengthy discussion about the steps involved. the first and foremost issue that needs to be addressed is cleaning up the global variables that are used throughout ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
