Re: [HACKERS] The Contrib Roundup (long)
Josh Berkus wrote:
intagg: what does this module do which is not already available
through the built-in array functions and operators? Maybe I
don't understand what it does. Unnatributed in the README. Move
to pgfoundry?
Short summary:
Is there an equivalent of int_array_enum() built in?
I use it for substantial (9X) performance improvements
for doing joins similar to those described in its README.
I think it can be used to do somewhat similar things with
integer arrays that the SQL2003 UNNEST operator does
on MULTISETs (but yeah, they're quite different too).
Long and boring, but with examples:
I find that it can speed up certain kinds of joins (like
those described in it's readme) drastically. I have a
pretty big application that has a lot of joins that use
int_array_enum() to expand an array stored in one
column into something that looks like a table instead
of having a third join table connecting two tables.
Note that this is often much faster than the
array IN/ANY/SOME/NOT IN comparisons because when
planning the join it can all the various join plans
like hash joins; while the array operators seem to
just do linear searches of the arrays.
This trick is especially useful in conjunction with an aggregate
based on the _int_union function from the intarray/ contrib
module (similar to the FUSION operator for MULTISETS) when you
only want distinct values for that type of join. Sample queries
from an actual application showing a factor-of-9 performance
improvement(7 seconds to 800ms) are shown below.
-- similar to the standard FUSION operator for MULTISETS.
create aggregate intarray_union_agg (
sfunc = _int_union,
basetype = int[],
stype = int[],
initcond = '{-1}'
);
explain analyze select fac_nam from userfeatures.point_features join
entity_facets using (entity_id) where featureid=115 group by fac_nam;
-- Total runtime: 7125.322 ms
explain analyze select fac_nam from (select distinct int_array_enum(fac_ids) as
fac_id from (select distinct fac_ids from entity_facids natural join
point_features where featureid=115) as a) as a join facet_lookup using (fac_id);
-- Total runtime: 1297.558 ms
explain analyze select fac_nam from (select distinct int_array_enum(fac_ids) as
fac_id from (select intarray_union_agg(fac_ids) as fac_ids from entity_facids
natural join point_features where featureid=115) as a) as a join facet_lookup
using (fac_id);
-- Total runtime: 803.187 ms
I don't have access to the system right now, so I don't have the
full table definitions - but the basic problem is that there are
many facets for each row in the point_features table and there
are many features with featureid=115. The queries are trying
to find the names of each facet available from that set of point_features.
intarray: data_types/
Well, the array of int's data type is built in, so I think
this module is more about the functions, operators, and
indexes that it provides that operate on arrays of ints.
Would that make it fit better under functions/ in your new
directory tree?
If I had a vote, I'd think it nice if the intagg module got
merged with the intarray module (wherever it ends up) because
they really are quite complementary in providing useful
tools for manipulating arrays of ints.
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] The Contrib Roundup (long)
elein wrote: intarray: data_types/ what does this do that arrays do not? It provides lossy indexes that work well on big arrays; as well as some quite useful convenience functions that work on arrays of ints. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] linuxtag 2005
On Wed, Jun 08, 2005 at 10:06:18AM +0530, Abhijit Menon-Sen wrote: Are any PostgreSQL hackers planning to be at Linuxtag in Karlsruhe? Yes and there will be a PostgreSQL booth organized by Peter. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] adding new pages bulky way
Tom Lane [EMAIL PROTECTED] writes I very seriously doubt that there would be *any* win I did a quick proof-concept implemenation to test non-concurrent batch insertion, here is the result: Envrionment: - Pg8.0.1 - NTFS / IDE -- batch 16 pages extension -- test=# insert into t select * from t; INSERT 0 131072 Time: 4167.000 ms test=# insert into t select * from t; INSERT 0 262144 Time: 8111.000 ms test=# insert into t select * from t; INSERT 0 524288 Time: 16444.000 ms test=# insert into t select * from t; INSERT 0 1048576 Time: 41980.000 ms -- batch 32 pages extension -- test=# insert into t select * from t; INSERT 0 131072 Time: 4086.000 ms test=# insert into t select * from t; INSERT 0 262144 Time: 7861.000 ms test=# insert into t select * from t; INSERT 0 524288 Time: 16403.000 ms test=# insert into t select * from t; INSERT 0 1048576 Time: 41290.000 ms -- batch 64 pages extension -- test=# insert into t select * from t; INSERT 0 131072 Time: 4236.000 ms test=# insert into t select * from t; INSERT 0 262144 Time: 8202.000 ms test=# insert into t select * from t; INSERT 0 524288 Time: 17265.000 ms test=# insert into t select * from t; INSERT 0 1048576 Time: 44063.000 ms -- batch 128 pages extension -- test=# insert into t select * from t; INSERT 0 131072 Time: 4256.000 ms test=# insert into t select * from t; INSERT 0 262144 Time: 8242.000 ms test=# insert into t select * from t; INSERT 0 524288 Time: 17375.000 ms test=# insert into t select * from t; INSERT 0 1048576 Time: 43854.000 ms -- one page extension -- test=# insert into t select * from t; INSERT 0 131072 Time: 4496.000 ms test=# insert into t select * from t; INSERT 0 262144 Time: 9013.000 ms test=# insert into t select * from t; INSERT 0 524288 Time: 19508.000 ms test=# insert into t select * from t; INSERT 0 1048576 Time: 49962.000 ms Benefits are there, and it is an approximate 10% improvement if we select good batch size. The explaination is: if a batch insertion need 6400 new pages, originally it does write()+file system logs 6400 times, now it does 6400/64 times(though each time the time cost is bigger). Also, considering write with different size have different cost, seems for my machine 32 is the an optimal choice. What I did include: (1) md.c Modify function mdextend(): - extend 64 pages each time; - after extension, let FSM be aware of it (change FSM a little bit so it could report freespace also for an empty page) (2) bufmgr.c make ReadPage(+empty_page) treat different of an empty page and non-empty one to avoid unnecesary read for new pages, that is: if (!empty_page) smgrread(reln-rd_smgr, blockNum, (char *) MAKE_PTR(bufHdr-data)); else PageInit((char *) MAKE_PTR(bufHdr-data), BLCKSZ, 0); /* Only for heap pages and race could be here ... */ (3) hio.c RelationGetBufferForTuple(): - pass correct empty_page parameter to ReadPage() according to the query result from FSM. Regards, Qingqing ---(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] The Contrib Roundup (long)
Am Dienstag, 7. Juni 2005 19:53 schrieb Josh Berkus: I think it would also be helpful to users if we could create subdirectories to organize contrib into categories. This would help users and packagers find what they want. These directories would be: data_types/ functions/ utilities/ I think this is out of the question both because these categories are fuzzy and it would destroy the CVS history. It might be equally effective to organize the README file along these lines. I'll point out that several people (including one of our RPM builders) spoke up in favor of the idea of adding ./contrib command line options for individual contrib items. Packagers should simply build all contrib items. No extra options are needed. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Daily DBT-3 (DSS) Results on CVS head
Mark Wong [EMAIL PROTECTED] writes http://developer.osdl.org/markw/postgrescvs/ The last two jump points looks nice! They are pulled from CVS on 5.30 and 6.1. Where the performance improvements come from? I could remember: * 5.30: avoid unnecessary foregin key check Seems CRC patch is not tested yet (on 6.2). Regards, Qingqing ---(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] linuxtag 2005
Abhijit Menon-Sen wrote: Are any PostgreSQL hackers planning to be at Linuxtag in Karlsruhe? I'll be at the booth. Regards, Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Correlated subselect in regression test
The regression test file subselect.sql contains the following query under the heading Correlated subselects: SELECT '' AS five, f1 AS Correlated Field FROM SUBSELECT_TBL WHERE (f1, f2) IN (SELECT f2, CAST(f3 AS int4) FROM SUBSELECT_TBL WHERE f3 IS NOT NULL); It has been pointed out to me that there is no correlation in this query. Is there some other special purpose to this query or is it simply categorized wrongly? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] regexp_replace
David Fetter wrote: On Tue, Jun 07, 2005 at 10:27:28PM +0900, Atsushi Ogawa wrote: David Fetter wrote: Ogawa-san, I think that this would be a case for function overloading: function regexp_replace( string text, pattern text, replacement text ) RETURNS TEXT; /* First only */ regexp_replace( string text, pattern text, replacement text, global bool ) RETURNS TEXT; /* Global if global is TRUE, first only otherwise */ What do you think of this idea? One trouble is that there are some other options. For example, one could add switches for all combinations of global, case insensitive, compile once, exclude whitespace, etc. as perl does. Do we want to go this route? My idea is opposite. I think that the regexp_replace() should make replace all a default. Because the replace() of pgsql replaces all string, and regexp_replace() of oracle10g is also similar. I respectfully disagree. Although Oracle does things this way, no other regular expression search and replace does. Historically, you can find that Oracle does it this way is not a reason why we would do it. Text editors, programming languages, etc., etc. do replace the first by default and replace globally only when told to. I agree. Let's stop the way to Oracle. And I think that it is better to be able to specify the option with text. I think that case insensitive is a good thing to add separately as a boolean :) I don't like to specify operation with boolean. ;) Because when a SQL is read, the meaning becomes indistinct. How about changing the function name of each usage? regexp_replace:replace first regexp_replace_all:replace all regexp_ic_replace: replace first and case insensitive regexp_ic_replace_all: replace all and case insensitive regards, -- Atsushi Ogawa ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Correlated subselect in regression test
Peter Eisentraut [EMAIL PROTECTED] writes: The regression test file subselect.sql contains the following query under the heading Correlated subselects: SELECT '' AS five, f1 AS Correlated Field FROM SUBSELECT_TBL WHERE (f1, f2) IN (SELECT f2, CAST(f3 AS int4) FROM SUBSELECT_TBL WHERE f3 IS NOT NULL); It has been pointed out to me that there is no correlation in this query. Is there some other special purpose to this query or is it simply categorized wrongly? I think it's just mislabeled. Looking at the CVS history, that particular query hasn't been changed since Tom Lockhart first created this test back in 6.3. I don't see any reason to think it has a special purpose in mind. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] regexp_replace
On K, 2005-06-08 at 21:32 +0900, Atsushi Ogawa wrote: How about changing the function name of each usage? regexp_replace:replace first regexp_replace_all:replace all regexp_ic_replace: replace first and case insensitive regexp_ic_replace_all: replace all and case insensitive perhaps just regexp_ireplace, we already have ILIKE not IC_LIKE -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] adding new pages bulky way
Qingqing Zhou [EMAIL PROTECTED] writes: What I did include: make ReadPage(+empty_page) treat different of an empty page and non-empty one to avoid unnecesary read for new pages, that is: In other words, if FSM is wrong you will overwrite valid data? No thanks ... this is guaranteed to fail under simple concurrent usage, let alone any more interesting scenarios like FSM being actually out of date. 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] The Contrib Roundup (long)
On Tue, Jun 07, 2005 at 02:53:32PM -0300, Josh Berkus wrote:
noupdate: this is a cool example of a simple C trigger and would
be lovely to have in a doc somewhere. However, its
functionality is easily replicated through a simple PL/pgSQL
trigger so it seems unnecessary as a contrib module. Author
unattributed.
Does noupdate even work correctly? The README is pretty thin so
maybe I've misunderstood something. First of all, the example fails
due to a case problem:
CREATE TABLE TEST ( COL1 INT, COL2 INT, COL3 INT );
CREATE TRIGGER BT BEFORE UPDATE ON TEST FOR EACH ROW
EXECUTE PROCEDURE
noup ('COL1');
INSERT INTO TEST VALUES (10,20,30);
UPDATE TEST SET COL1 = 5;
ERROR: noup: there is no attribute COL1 in relation test
If we fix the case problem then this particular example works:
DROP TRIGGER BT ON TEST;
CREATE TRIGGER BT BEFORE UPDATE ON TEST FOR EACH ROW
EXECUTE PROCEDURE
noup ('col1');
UPDATE TEST SET COL1 = 5;
WARNING: col1: update not allowed
UPDATE 0
But the trigger won't allow updates on other columns either:
UPDATE TEST SET COL2 = 15;
WARNING: col1: update not allowed
UPDATE 0
...unless we *do* change COL1 to NULL:
UPDATE TEST SET COL1 = NULL, COL2 = 15;
UPDATE 1
The code rejects the update if the new value for the designated
column (col1 in this case) is not NULL, rather than checking if
its value has changed. Is that the intended behavior?
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] The Contrib Roundup (long)
Peter, Packagers should simply build all contrib items. No extra options are needed. No, they shoudn't. 3 of the packages currently in /contrib are GPL. Building them makes all of PostgreSQL GPL. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] The Contrib Roundup (long)
Peter, I think this is out of the question both because these categories are fuzzy and it would destroy the CVS history. It might be equally effective to organize the README file along these lines. Ach, I forgot about this lovely property of CVS. Well, scratch that proposal. SVN is looking better and better ... Packagers should simply build all contrib items. No extra options are needed. Hmmm, when an RPM builds a contrib item, where does the .sql file go? How does an RPM user actually add the functions/datatypes/etc to their database? -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] The Contrib Roundup (long)
Josh Berkus josh@agliodbs.com writes: Packagers should simply build all contrib items. No extra options are needed. No, they shoudn't. 3 of the packages currently in /contrib are GPL. Building them makes all of PostgreSQL GPL. The fix for that is to remove or relicense those packages, not to complicate the build process. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] The Contrib Roundup (long)
Tom, The fix for that is to remove or relicense those packages, not to complicate the build process. OK. Then we'll make BSD licensing an absolute requirement for /contrib? Also, we'll add --build-all-contrib to ./configure? -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] The Contrib Roundup (long)
On Wed, Jun 08, 2005 at 08:45:42AM -0700, Josh Berkus wrote: Peter, Packagers should simply build all contrib items. No extra options are needed. No, they shoudn't. 3 of the packages currently in /contrib are GPL. Building them makes all of PostgreSQL GPL. No, it means the distributors are illegally distributing software they don't have permission to distribute. The GPL doesn't make everything else GPL right away, that's a myth. The only entity that can change PostgreSQL's license is the copyright owner. Since it's a rather big and unidentified entity, that's difficult. So the only lawful (legal?) way to distribute a binary PostgreSQL distribution is to refrain from distributing GPL-licensed contrib modules. Or we could remove them from contrib. -- Alvaro Herrera (alvherre[a]surnet.cl) Hoy es el primer día del resto de mi vida ---(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] The Contrib Roundup (long)
Josh Berkus josh@agliodbs.com writes: Tom, The fix for that is to remove or relicense those packages, not to complicate the build process. OK. Then we'll make BSD licensing an absolute requirement for /contrib? That's been the intention for a very long time: everything in the core tarball should be under the same license. Someone's got to do the legwork of contacting the module authors involved to see if they're willing to relicense ... and so far it just hasn't gotten to the top of the to-do queue. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] The Contrib Roundup (long)
On Wed, Jun 08, 2005 at 08:59:37AM -0700, Josh Berkus wrote: Peter, I think this is out of the question both because these categories are fuzzy and it would destroy the CVS history. It might be equally effective to organize the README file along these lines. Ach, I forgot about this lovely property of CVS. Well, scratch that proposal. SVN is looking better and better ... I'll argue for a change as soon as Monotone is able to import our current repository. I think a distributed SCM is the way to go ... -- Alvaro Herrera (alvherre[a]surnet.cl) Acepta los honores y aplausos y perderás tu libertad ---(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] The Contrib Roundup (long)
On Wednesday 08 June 2005 12:05, Alvaro Herrera wrote:
On Wed, Jun 08, 2005 at 08:45:42AM -0700, Josh Berkus wrote:
Peter,
Packagers should simply build all contrib items. No extra options are
needed.
No, they shoudn't. 3 of the packages currently in /contrib are GPL.
Building them makes all of PostgreSQL GPL.
No, it means the distributors are illegally distributing software they
don't have permission to distribute. The GPL doesn't make everything
else GPL right away, that's a myth.
In the above scenario, the packages must be distributed under the GPL. This
is perfectly legal for both postgresql and those gpl contrib modules.
It would be incorrect (and therefore technically illegal) to distribute the
above combo with postgresql as bsd and the contribs as gpl, since that
violates the license that has been granted by the contrib modules.
The only entity that can change PostgreSQL's license is the copyright
owner. Since it's a rather big and unidentified entity, that's
difficult. So the only lawful (legal?) way to distribute a binary
PostgreSQL distribution is to refrain from distributing GPL-licensed
contrib modules.
Thats just not true. Anyone can relicense thier own distribution of
postgresql under any license they see fit, as long as they adhere to the
license that they were given with thier copy of postgresql (which basically
just means keeping the copyrights intact). Thats how folks can sell
proprietary packages under closed licenses.
Or we could remove them from contrib.
That's what I would recommend if we cant them relicensed.
--
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] The Contrib Roundup (long)
People: No, it means the distributors are illegally distributing software they don't have permission to distribute. The GPL doesn't make everything else GPL right away, that's a myth. I'm not talking out of my hat here. I consulted a staff member of the FSF about it (will give name as soon as I sort through my business cards from the conference). According to him, if someone builds PostgreSQL with a GPL contrib module, then all of *their copy* of PostgreSQL becomes GPL. While there is nothing illegal about this, it is would not be desirable for most PostgreSQL users and they would be absolutely right to be mad at us for building a licensing booby trap into /contrib. That's what I would recommend if we cant them relicensed. I will point out that all three GPL modules are currently unmaintained. I don't know that anyone has seen Massimo in years. Simply dropping them seems the easiest answer. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Request for Comments: ALTER [OBJECT] SET SCHEMA
I've took a look at the TODO item Allow objects to be moved to different schemas I've done some code so far which implements the syntax ALTER [OBJECT] name SET SCHEMA name where OBJECT currently is SEQUENCE TABLE FUNCTION DOMAIN TYPE Missing are (and i'm planning to add support for this): AGGREGATE OPERATOR OPERATOR CLASS CONVERSION You can find a preliminary patch attached to this posting and i'm looking for comments, critics and perhaps some proposals for improvements / necessary changes i didn't consider yet. One issue that comes to my mind is what to do when dealing with tables that have assigned triggers and sequences (serials). Do we want to move them as well or leave them in the source namespace? TIA -- Bernd pgsql_alter_object_set_schema.patch Description: Binary data ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] The Contrib Roundup (long)
Josh Berkus josh@agliodbs.com writes: I will point out that all three GPL modules are currently unmaintained. I don't know that anyone has seen Massimo in years. Simply dropping them seems the easiest answer. The original authors of the backend code haven't been seen on this list in a long time, either ;-). That doesn't make either the backend or these contrib modules unmaintained. userlock in particular is not practical to drop without a replacement, because people are definitely using it. A quick grep for General Public License finds these files: contrib/dbmirror/clean_pending.pl contrib/miscutil/README.misc_utils contrib/miscutil/misc_utils.c contrib/miscutil/misc_utils.sql.in contrib/string/README.string_io contrib/string/string_io.c contrib/string/string_io.sql.in contrib/tools/find-sources contrib/tsearch/dict/porter_english.dct contrib/userlock/README.user_locks contrib/userlock/user_locks.c contrib/userlock/user_locks.sql.in I think the dbmirror one is just a mistake, since the README has a BSD-type license, but we'd need to get Steven Singer to confirm that. The tsearch one is more of a problem, but Oleg and Teodor have been wanting to obsolete tsearch anyway, so dropping it would work. That leaves us with four modules to be looked at ... and yeah, they do all seem to be Massimo's. Anyone want to try to contact him? 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] Request for Comments: ALTER [OBJECT] SET SCHEMA
On Wed, Jun 08, 2005 at 08:25:12PM +0200, Bernd Helmle wrote: One issue that comes to my mind is what to do when dealing with tables that have assigned triggers and sequences (serials). Do we want to move them as well or leave them in the source namespace? I'd think it's important that the ALTER TABLE leaves things just like what you'd end up with if you created the table in the new schema in the first place. i.e., indexes, triggers, sequences should be moved too. One issue to check is what happens if you move the table and trigger but the function remains in the original namespace. Is this a problem if the new namespace is not in the search path? -- Alvaro Herrera (alvherre[a]surnet.cl) This is a foot just waiting to be shot(Andrew Dunstan) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Request for Comments: ALTER [OBJECT] SET SCHEMA
Bernd Helmle [EMAIL PROTECTED] writes: You can find a preliminary patch attached to this posting and i'm looking for comments, critics and perhaps some proposals for improvements / necessary changes i didn't consider yet. The code seems fairly schizoid about whether the operation is an alter namespace or a rename. Please be consistent. I'd say it is *not* a rename, but I suppose you could make an argument the other way ... The locking you are doing is inconsistent with the rest of the backend. We generally don't hold locks on catalogs longer than necessary. Applying const to pointers that point to things that are not const, as in + void + ApplyTypeNamespace( Oid typeOid, + const Relation rel, seems to me to be horrible style, even if the compiler lets you do it. It's too easy to misread it as a promise not to alter the pointed-to object. (In general I dislike consts on parameters, as that seems to me to be conflating interface and implementation --- it's certainly no business of a caller's whether your routine modifies the parameter internally. Of course this is C's fault not yours, but one has to work with the language one has.) regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] The Contrib Roundup (long)
On Wed, Jun 08, 2005 at 11:13:01AM -0700, Josh Berkus wrote: People: No, it means the distributors are illegally distributing software they don't have permission to distribute. The GPL doesn't make everything else GPL right away, that's a myth. I'm not talking out of my hat here. I don't expect you to talk inside your hat either. Anyway, I realized that our license does allow this to happen without any sort of problem; but I don't see what's so bad about it. The person who receives a GPL'd Postgres can get a BSD Postgres just as easily, should the need arise. The opinion I gave earlier, quoted above, is correct for other licenses, e.g. any commercial license. Open source detractors say to everyone who listen to them that including GPL code in their packages automatically make them also GPL'ed, which is false. -- Alvaro Herrera (alvherre[a]surnet.cl) You knock on that door or the sun will be shining on places inside you that the sun doesn't usually shine (en Death: The High Cost of Living) ---(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] The Contrib Roundup (long)
On Wed, 8 Jun 2005, Josh Berkus wrote: Peter, Packagers should simply build all contrib items. No extra options are needed. No, they shoudn't. 3 of the packages currently in /contrib are GPL. Building them makes all of PostgreSQL GPL. Then they should be removed ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] The Contrib Roundup (long)
On Wed, 8 Jun 2005, Peter Eisentraut wrote: Am Dienstag, 7. Juni 2005 19:53 schrieb Josh Berkus: I think it would also be helpful to users if we could create subdirectories to organize contrib into categories. This would help users and packagers find what they want. These directories would be: data_types/ functions/ utilities/ I think this is out of the question both because these categories are fuzzy and it would destroy the CVS history. Why would it destroy the history? Its easy enough to move the files to a subdirectory without losing any history ... hell, we did it when we moved JDBC/ODBC out of core, the history was maintained ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] autovacuum in backend?
Hello, Does it look like it is going to make it for 8.1? -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Account in postgresql database
Hi, I was searching for some information about the storage of the user data in postgresql. As far as I know there is one dictionary table for storeing all the users of any known database, right? As we'd like to provide a postgresql database service to our students we'd like to create one database for each user. This user should be able to create new accounts for other users but only for his/her database. Any comments or solutions are welcome. Regards, Yann - Human knowledge belongs to the world. The answer is open source ! - ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] The Contrib Roundup (long)
Marc G. Fournier [EMAIL PROTECTED] writes: On Wed, 8 Jun 2005, Peter Eisentraut wrote: I think this is out of the question both because these categories are fuzzy and it would destroy the CVS history. Why would it destroy the history? Its easy enough to move the files to a subdirectory without losing any history ... hell, we did it when we moved JDBC/ODBC out of core, the history was maintained ... I don't think you can just move the files --- that will break future builds of the back branches (unless you intend to make the rearrangement retroactive). I agree with Peter's point anyway: the main value of classifying these things is for documentation, and just structuring the top-level README that way would be sufficient. Physically changing the hierarchy is just much more work than it's worth. 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] The Contrib Roundup (long)
On Wed, Jun 08, 2005 at 04:21:46PM -0300, Marc G. Fournier wrote: On Wed, 8 Jun 2005, Peter Eisentraut wrote: Am Dienstag, 7. Juni 2005 19:53 schrieb Josh Berkus: I think it would also be helpful to users if we could create subdirectories to organize contrib into categories. This would help users and packagers find what they want. These directories would be: data_types/ functions/ utilities/ I think this is out of the question both because these categories are fuzzy and it would destroy the CVS history. Why would it destroy the history? Its easy enough to move the files to a subdirectory without losing any history ... hell, we did it when we moved JDBC/ODBC out of core, the history was maintained ... Can't do that, because if you do the files will disappear in (say) 7.4 releases, and we don't want that, do we? -- Alvaro Herrera (alvherre[a]surnet.cl) No reniegues de lo que alguna vez creíste ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] autovacuum in backend?
Joshua D. Drake wrote: Does it look like it is going to make it for 8.1? I certainly hope so. However, I don't have much time to put towards it between now and July 1. Also, I will need significant help from someone to get past some of the issues that I'm not really capable of. I am trying to get my previous integration patch updated to apply against HEAD but it will probably be a week or two before I find enough time to get that working well. Then hopefully someone will step up to help me improve the patch so that it's acceptable. Any takers? BTW if someone else wants to take this on please do, I will not be offended. Matt ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] The Contrib Roundup (long)
On Wed, 8 Jun 2005, Alvaro Herrera wrote: On Wed, Jun 08, 2005 at 04:21:46PM -0300, Marc G. Fournier wrote: On Wed, 8 Jun 2005, Peter Eisentraut wrote: Am Dienstag, 7. Juni 2005 19:53 schrieb Josh Berkus: I think it would also be helpful to users if we could create subdirectories to organize contrib into categories. This would help users and packagers find what they want. These directories would be: data_types/ functions/ utilities/ I think this is out of the question both because these categories are fuzzy and it would destroy the CVS history. Why would it destroy the history? Its easy enough to move the files to a subdirectory without losing any history ... hell, we did it when we moved JDBC/ODBC out of core, the history was maintained ... Can't do that, because if you do the files will disappear in (say) 7.4 releases, and we don't want that, do we? Hrmmm, good point that I hadn't thought of ... unless, of course, we back-patch the build changes ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] The Contrib Roundup (long)
On Tue, 07 Jun 2005 14:53:32 -0300, Josh Berkus wrote: [Discussion snipped] xml and xml2: both by John Gray ([EMAIL PROTECTED]). John, why do we have two of these? Otherwise, data_types/. contrib/xml2 is a lot better than /xml. When I submitted the new code, Bruce felt that /xml should be kept for compatibility in case there were people using it (the API changed completely). Personally, I'd be very happy for /xml to go - it's not nearly as good as /xml2 (/xml2 has some serious production users as far as I can tell- anyone who's ever asked me about building /xml has been pointed to /xml2). There's no maintenance effort for /xml, but I'm still working on /xml2. Hope that clears things up a bit! Regards John ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] The Contrib Roundup (long)
On Wed, Jun 08, 2005 at 06:50:06PM -0300 I heard the voice of Marc G. Fournier, and lo! it spake thus: On Wed, 8 Jun 2005, Alvaro Herrera wrote: On Wed, Jun 08, 2005 at 04:21:46PM -0300, Marc G. Fournier wrote: Why would it destroy the history? Its easy enough to move the files to a subdirectory without losing any history ... hell, we did it when we moved JDBC/ODBC out of core, the history was maintained ... Can't do that, because if you do the files will disappear in (say) 7.4 releases, and we don't want that, do we? Hrmmm, good point that I hadn't thought of ... unless, of course, we back-patch the build changes ... That's why you COPY the files in the repo, cvs rm the old locations (so they still exist on older tags/branches), and do some surgery on the new locations to remove the old tags (though you can't remove branches last I checked, without more serious magic; you could go in and cvs rm on the branches I guess, which is better than nothing, though more work) so they don't start showing up on old release co's. It's nasty, but it works. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] regexp_replace
Atsushi Ogawa said: How about changing the function name of each usage? regexp_replace:replace first regexp_replace_all:replace all regexp_ic_replace: replace first and case insensitive regexp_ic_replace_all: replace all and case insensitive That's just horrible. The number of function names will double with each supported flag (e.g. I'd like to see extended regexes supported). surely somthing like foo_replace (source text, pattern text, replacement text, flags text) returns text would fit the bill. OK, it reflects my Perl prejudices, but that looks more natural to me. You could overload it so that the flags default to none (which would be case sensitive, replace the first instance only, among other things). cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] The Contrib Roundup (long)
On Wed, Jun 08, 2005 at 05:54:08PM -0500, Matthew D. Fuller wrote: That's why you COPY the files in the repo, cvs rm the old locations (so they still exist on older tags/branches), and do some surgery on Hmm, while we are at the subject of playing with our CVS server, could we fix some other things? * cvsweb could display the correct $PostgreSQL$ tags ... right now it's only getting what's changed at each commit (i.e. it's always one version behind) (Additionaly it'd be nice to know what on earth does one have to set so that a CVSup-acquired repository behaves the same with local checkouts.) * the cvsweb could display tabs as 4 spaces, just like the code expects. This is mostly a minor annoyance. I had other gripes but I forget them right now :-( -- Alvaro Herrera (alvherre[a]surnet.cl) El realista sabe lo que quiere; el idealista quiere lo que sabe (Anónimo) ---(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] The Contrib Roundup (long)
On Wed, 8 Jun 2005, Matthew D. Fuller wrote: On Wed, Jun 08, 2005 at 06:50:06PM -0300 I heard the voice of Marc G. Fournier, and lo! it spake thus: On Wed, 8 Jun 2005, Alvaro Herrera wrote: On Wed, Jun 08, 2005 at 04:21:46PM -0300, Marc G. Fournier wrote: Why would it destroy the history? Its easy enough to move the files to a subdirectory without losing any history ... hell, we did it when we moved JDBC/ODBC out of core, the history was maintained ... Can't do that, because if you do the files will disappear in (say) 7.4 releases, and we don't want that, do we? Hrmmm, good point that I hadn't thought of ... unless, of course, we back-patch the build changes ... That's why you COPY the files in the repo, cvs rm the old locations (so they still exist on older tags/branches), and do some surgery on the new locations to remove the old tags (though you can't remove branches last I checked, without more serious magic; you could go in and cvs rm on the branches I guess, which is better than nothing, though more work) so they don't start showing up on old release co's. Actually, simplier yet would be to just 'cvs add' everything in th enew place, and cvs remove it on HEAD in the old ... the 'cvs add' log entry should state something like 'moved from ...' Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] The Contrib Roundup (long)
Marc G. Fournier [EMAIL PROTECTED] writes: On Wed, 8 Jun 2005, Matthew D. Fuller wrote: That's why you COPY the files in the repo, cvs rm the old locations (so they still exist on older tags/branches), and do some surgery on the new locations to remove the old tags (though you can't remove branches last I checked, without more serious magic; you could go in and cvs rm on the branches I guess, which is better than nothing, though more work) so they don't start showing up on old release co's. Actually, simplier yet would be to just 'cvs add' everything in th enew place, and cvs remove it on HEAD in the old ... the 'cvs add' log entry should state something like 'moved from ...' Yeah ... at that point you've more or less erased the history from the new files anyway, no? Might as well just cut it over. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] regexp_replace
Robert Treat wrote: On Tuesday 07 June 2005 10:57, David Fetter wrote: On Tue, Jun 07, 2005 at 10:27:28PM +0900, Atsushi Ogawa wrote: My idea is opposite. I think that the regexp_replace() should make replace all a default. Because the replace() of pgsql replaces all string, and regexp_replace() of oracle10g is also similar. I respectfully disagree. Although Oracle does things this way, no other regular expression search and replace does. Historically, you can find that Oracle does it this way is not a reason why we would do it. Text editors, programming languages, etc., etc. do replace the first by default and replace globally only when told to. You don't think it will be confusing to have a function called replace which replaces all occurrences and a function called regex_replace which only replaces the first occurance? There's something to be said for consitancy within pgsql itself. Huh? I am confused. Why if both support regex, why does regex_replace only do the first one? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 7: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] regexp_replace
On Tuesday 07 June 2005 10:57, David Fetter wrote:
On Tue, Jun 07, 2005 at 10:27:28PM +0900, Atsushi Ogawa wrote:
My idea is opposite. I think that the regexp_replace() should make
replace all a default. Because the replace() of pgsql replaces all
string, and regexp_replace() of oracle10g is also similar.
I respectfully disagree. Although Oracle does things this way, no
other regular expression search and replace does. Historically, you
can find that Oracle does it this way is not a reason why we would
do it. Text editors, programming languages, etc., etc. do replace
the first by default and replace globally only when told to.
You don't think it will be confusing to have a function called replace which
replaces all occurrences and a function called regex_replace which only
replaces the first occurance? There's something to be said for consitancy
within pgsql itself.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] The Contrib Roundup (long)
Tom Lane wrote: That's been the intention for a very long time: everything in the core tarball should be under the same license. Someone's got to do the legwork of contacting the module authors involved to see if they're willing to relicense ... and so far it just hasn't gotten to the top of the to-do queue. I've volunteered to do this in the past, and the response was that it is something that only members of core are in a position to do this. That is perfectly reasonable, but that was quite some time ago -- it would be nice to see some movement on this... I think shipping a pure-BSD 8.1 is a reasonable goal. -Neil ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] regexp_replace
Andrew Dunstan wrote: Atsushi Ogawa said: How about changing the function name of each usage? regexp_replace:replace first regexp_replace_all:replace all regexp_ic_replace: replace first and case insensitive regexp_ic_replace_all: replace all and case insensitive That's just horrible. The number of function names will double with each supported flag (e.g. I'd like to see extended regexes supported). surely somthing like foo_replace (source text, pattern text, replacement text, flags text) returns text would fit the bill. OK, it reflects my Perl prejudices, but that looks more natural to me. You could overload it so that the flags default to none (which would be case sensitive, replace the first instance only, among other things). Can we have the flags be a list of words, e.g. all, ignorecase. How do we handle this type of problem in other cases? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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] [PATCHES] regexp_replace
On 08/06/2005 21:57:29, Bruce Momjian wrote: Andrew Dunstan wrote: Atsushi Ogawa said: How about changing the function name of each usage? regexp_replace:replace first regexp_replace_all:replace all regexp_ic_replace: replace first and case insensitive regexp_ic_replace_all: replace all and case insensitive That's just horrible. The number of function names will double with each supported flag (e.g. I'd like to see extended regexes supported). surely somthing like foo_replace (source text, pattern text, replacement text, flags text) returns text would fit the bill. OK, it reflects my Perl prejudices, but that looks more natural to me. You could overload it so that the flags default to none (which would be case sensitive, replace the first instance only, among other things). Can we have the flags be a list of words, e.g. all, ignorecase. How do we handle this type of problem in other cases? How about an array? Cumbersome, perhaps, but it makes more sense to me than delimiting with commas or using single characters. -- Tom ---(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] I am up-to-date
Done. --- Simon Riggs wrote: On Mon, 2005-06-06 at 22:09 -0400, Bruce Momjian wrote: After months of being behind, I have gone through my entire mailbox and addressed all the patches held over from 8.0beta. I have loaded up the patch queue and will apply them in a day or two. http://momjian.postgresql.org/cgi-bin/pgpatches Some of the patches lack documentation which I will add, and some have multiple versions in the queue because I need the descriptions from earlier versions. I believe that the Bgwriter behaviour patch from 1 Jan is no longer valid against cvstip, since it has been superceded by other patches. We're safe to remove it from the patch queue. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] linuxtag 2005
aAndreas Pflug wrote: Abhijit Menon-Sen wrote: Are any PostgreSQL hackers planning to be at Linuxtag in Karlsruhe? I'll be at the booth. Sorry, I will not be there this year. The past two years that I attended were great and I encourage others to attend. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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/faq
Re: [HACKERS] autovacuum in backend?
I will post tomorrow on a plan for this. --- Matthew T. O'Connor wrote: Joshua D. Drake wrote: Does it look like it is going to make it for 8.1? I certainly hope so. However, I don't have much time to put towards it between now and July 1. Also, I will need significant help from someone to get past some of the issues that I'm not really capable of. I am trying to get my previous integration patch updated to apply against HEAD but it will probably be a week or two before I find enough time to get that working well. Then hopefully someone will step up to help me improve the patch so that it's acceptable. Any takers? BTW if someone else wants to take this on please do, I will not be offended. Matt ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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] pg_config --configure ...
How are ppl using this? I'm trying to use it to re-configure, having tried both tcsh and bash, and neither seem to 'work': # ./configure `pg_config --configure` configure: error: invalid variable name: '--with-libraries So, is there another way I can use the output from pg_config to pass to configure? Thanks ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] Request for Comments: ALTER [OBJECT] SET SCHEMA
One issue that comes to my mind is what to do when dealing with tables that have assigned triggers and sequences (serials). Do we want to move them as well or leave them in the source namespace? They should all be moved. Remember nasties like indexes should be moved as well as toast tables. Chris ---(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] pg_config --configure ...
I usually just look at config.log, and copy and paste...but I am guessing you are trying to automate this. Looks like pg_config adds '' around each option when specifying --configure (i.e. '--with-libraries'), at least on my system (Linux, PG803). You can try to get rid of the ''. This seems to work on my system: ./configure `pg_config --configure | tr ' ` I'm not a shell guru by any means, so there might be a better way... --- Marc G. Fournier [EMAIL PROTECTED] wrote: How are ppl using this? I'm trying to use it to re-configure, having tried both tcsh and bash, and neither seem to 'work': # ./configure `pg_config --configure` configure: error: invalid variable name: '--with-libraries So, is there another way I can use the output from pg_config to pass to configure? Thanks ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) --brett __ Discover Yahoo! Use Yahoo! to plan a weekend, have fun online and more. Check it out! http://discover.yahoo.com/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] adding new pages bulky way
Tom Lane [EMAIL PROTECTED] writes In other words, if FSM is wrong you will overwrite valid data? No thanks ... this is guaranteed to fail under simple concurrent usage, let alone any more interesting scenarios like FSM being actually out of date. You are welcome ;-). The FSM race/corruption is a trouble. Maybe we could put it in TODO list for better solutions since we can see the performance benefits are there. Regards, Qingqing ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_config --configure ...
On Wed, 8 Jun 2005, Brett Schwarz wrote: I usually just look at config.log, and copy and paste...but I am guessing you are trying to automate this. Looks like pg_config adds '' around each option when specifying --configure (i.e. '--with-libraries'), at least on my system (Linux, PG803). You can try to get rid of the ''. This seems to work on my system: ./configure `pg_config --configure | tr ' ` I'm not a shell guru by any means, so there might be a better way... Thought of that too, still blows up: pgsql74# ./configure `pg_config --configure | tr ' ` configure: WARNING: you should use --build, --host, --target configure: error: unrecognized option: -rpath=/usr/lib:/usr/local/lib Try `./configure --help' for more information. Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] unsafe use of hash_search(... HASH_ENTER ...)
Tom Lane [EMAIL PROTECTED] writes This is not an issue except if the system might actually try to recover; which is not the case in the postmaster snippet you mention. Yeah, you are right. I scratched elog/ereport(FATAL/PANIC), only found this one might be a suspect: In _hash_expandtable(): if (!_hash_try_getlock(rel, start_nblkno, HASH_EXCLUSIVE)) elog(PANIC, could not get lock on supposedly new bucket); Or maybe elog(PANIC) is a false alarm here? Regards, Qingqing ---(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] pg_config --configure ...
On Thu, Jun 09, 2005 at 12:26:06AM -0300, Marc G. Fournier wrote: pgsql74# ./configure `pg_config --configure | tr ' ` configure: WARNING: you should use --build, --host, --target configure: error: unrecognized option: -rpath=/usr/lib:/usr/local/lib Try `./configure --help' for more information. Have you tried eval or xargs? eval ./configure `pg_config --configure` pg_config --configure | xargs ./configure Both work for me in simple tests; I haven't given much thought to what might make them fail, though -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Account in postgresql database
Yann, As we'd like to provide a postgresql database service to our students we'd like to create one database for each user. This user should be able to create new accounts for other users but only for his/her database. That's on the TODO list. As far as I know, nobody is currently working on it. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] The Contrib Roundup (long)
Neil, I've volunteered to do this in the past, and the response was that it is something that only members of core are in a position to do this. That is perfectly reasonable, but that was quite some time ago -- it would be nice to see some movement on this... I thought I *was* moving on this. Frankly, until Marc posted I wasn't aware that it was *possible* to have differently-licensed stuff except in /contrib. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] autovacuum in backend?
On Wed, Jun 08, 2005 at 10:25:18PM -0400, Bruce Momjian wrote: I will post tomorrow on a plan for this. If you need developer time, I'm available to work on this as it seems higher priority to me that shared dependencies. -- Alvaro Herrera (alvherre[a]surnet.cl) Hay que recordar que la existencia en el cosmos, y particularmente la elaboración de civilizaciones dentre de él no son, por desgracia, nada idílicas (Ijon Tichy) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_config --configure ...
Marc G. Fournier wrote: On Wed, 8 Jun 2005, Brett Schwarz wrote: ./configure `pg_config --configure | tr ' ` Thought of that too, still blows up: How about ./configure `pg_config --configure|sed s/\'//g` Cheers Mark ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] interval-day AdjustIntervalForTypmod?
I've been making a bit of progress on adding a day field to the
Interval struct (thanks to the help of this list and the find folks
on IRC). Selects and basic math seem to be working, and the code is
passing more regression tests than it was before.
I'm running into a bit of a problem with storing the data in
relations. For example:
test=# select '1 year 13 mons 2 days 26:03'::interval;
interval
---
2 years 1 mon 2 days 26:03:00
(1 row)
test=# create table interval_tbl (f1 interval);
CREATE TABLE
test=# insert into interval_tbl (f1) values ('1 year 13 mons 2 days
26:03'::interval);
INSERT 0 1
test=# select * from interval_tbl;
f1
-
2 days 26:03:00
(1 row)
It appears that the data isn't being stored properly. I think I need
to make adjustments to AdjustIntervalForTypmod() in timestamp.c, but
I could very easily be wrong. I'm unfamiliar with what this code is
supposed to do and typmods in general. I've searched the mailing
lists for hints but haven't found anything that has appeared
particularly helpful. Would someone be able to give me a bit of
background on typmod (and possibly related information) or suggest
where I might find more information?
Thanks for any assistance.
Michael Glaesemann
grzm myrealbox com
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] unsafe use of hash_search(... HASH_ENTER ...)
Qingqing Zhou [EMAIL PROTECTED] writes: Yeah, you are right. I scratched elog/ereport(FATAL/PANIC), only found this one might be a suspect: In _hash_expandtable(): if (!_hash_try_getlock(rel, start_nblkno, HASH_EXCLUSIVE)) elog(PANIC, could not get lock on supposedly new bucket); Or maybe elog(PANIC) is a false alarm here? [ eyes code... ] I think the reason it wants to PANIC is because it's already hacked up the hash metapage in shared buffers, and it needs to prevent that update from getting written out. A CRIT_SECTION would probably be a better answer --- thanks for spotting that. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] interval-day AdjustIntervalForTypmod?
Michael Glaesemann [EMAIL PROTECTED] writes: I've been making a bit of progress on adding a day field to the Interval struct (thanks to the help of this list and the find folks on IRC). Selects and basic math seem to be working, and the code is passing more regression tests than it was before. I'm running into a bit of a problem with storing the data in relations. For example: Hm, have you adjusted the size (typlen) shown for interval in pg_type? (This is of course an initdb-forcing change.) 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] pg_config --configure ...
Marc G. Fournier wrote: # ./configure `pg_config --configure` configure: error: invalid variable name: '--with-libraries The intended mode of usage is eval ./configure `pg_config --configure` -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
* Tom Lane ([EMAIL PROTECTED]) wrote: It's essential IMHO that we provide pg_shadow and pg_group as reasonably backward-compatible views on the new pg_roles catalog. It's not at all negotiable that CREATE USER and CREATE GROUP have to still work in a sane fashion --- to say otherwise is to say that we aren't going to load pg_dumpall scripts from older PG versions, and that is a Non Starter. Right, makes sense, I had just busted them while getting the initial code written. I've now gone back and cleaned up the main parser quite a bit with regard to create/alter/drop/etc user/role. My latest work is available here: http://kenobi.snowman.net/~sfrost/pg_role/latest-role_20050609.1.patch.gz Also the .h files in the same directory (pg_auth_members.h, pg_authid.h) which need to be put into src/include/catalog/. It patches and compiles cleanly against latest CVS (at least, latest as of a few hours ago). I've also updated and flushed out a bit the set of milestones/todo items. My latest version of that can be found here: http://kenobi.snowman.net/~sfrost/pg_role/role_milestones * Means completed in the patch, ? means I'm not sure if it's something that should be done or not. No marker means it needs to be done and hasn't been yet. In general I feel it's starting to get close to meeting all the expectations that I had for it. The more critical things, imv, are the ACL changes for multi-level role resolution (for owners and others) and the per-backend role-member cacheing and fixing the other parsers (ecpg, etc, shouldn't be too hard now that I've got it figured out for the main parser, or at least think I do). Unfortunately, it's starting to get close to July 1st and my availablity is rather sporadic in terms of when I can spend time on this. I'd certainly be willing to work with others (I'm generally pretty responsive to email) to get this finished off and polished up. I do hope to spend some more time on it over the next two weeks and may be able to finish it by July 1st myself but I can't really be 100% sure on that. Thanks, Stephen signature.asc Description: Digital signature
