[HACKERS] Postgre SQL for Windows
Hello! Can anybody tell me the website from which I can download PostgreSQL for Windows95. With regards, Sourabh
Re: [HACKERS] Using Threads?
On Mon, 5 Feb 2001, Myron Scott wrote: I have put a new version of my multi-threaded postgresql experiment at http://www.sacadia.com/mtpg.html This one actually works. I have added a server based on omniORB, a CORBA 2.3 ORB from ATT. It is much smaller than TAO and uses the thread per connection model. I haven't added the java side of the JNI interface yet but the C++ side is there. It's still not stable but it is much better than [EMAIL PROTECTED] Sorry I haven't time to see and test your experiment, but I have a question. How you solve memory management? The current mmgr is based on global variable CurrentMemoryContext that is very often changed and used. Use you for this locks? If yes it is probably problematic point for perfomance. Karel
Re: [HACKERS] 7.1 beta 3 CHANGES FOR QNX
"Tom Lane" [EMAIL PROTECTED] writes: Well, my question still stands: why aren't the other four flex outputs also broken? They all use ECHO. I don't know why, but probably you are right. I only know that if ECHO was not redefined, when I compile with ecpg the output c file has all the original lines on the same row (without an LF). In any case, I'd prefer to see this fixed by not including termios.h rather than hacking up the .l files. Surely it doesn't need to be included everywhere, as src/include/port/qnx4.h is now causing to happen. In fact, it looks to me like qnx4.h probably includes and defines a lot more than it needs to; would you experiment with stripping it down? If You want I can experiment on qnx4.h. On Saturday I will post the risults. That strikes me as *horribly* dangerous. There is too much code whose behavior might change in unpleasant ways if Size becomes a signed type. Please explain what problems you are seeing that make you think this is a good idea. In 7.0.2 and 7.0.3 release I have errors about some parameters in TCP/IP functions. The compiler tells me that I have a long int where an int was expected. When I changed Size in int I compiled successfuly PGSQL. In 7.1 I changed immediatly the size type and all seems works. After your message I modified again Size type in size_t and recompiled 7.1 release. I compiled successfuly this version the only warnings are about elog lines in wich there are Size variables. The compiler tells me I have a long int where an unsigned was expected (only the format, there is a %u). However PGSQL works right. Andreas, the QNX port is largely your work IIRC. What do you think of these issues? Have you tried 7.1beta on QNX? I also would like to know what Andreas Kardos think. When, some month ago, I starded looking for POSTGRESQL and I had a lot of problems compiling 7.0.1 version (the major problem was what I have to do for the Size type?) I send some e-mails to Dr. Kardos and he tells me that his version working fine. After the first replay he didn't replay to me. Also other QNX users has the same problems I had and send me e-mails to know if I have compiled successfully PGSQl for QNX. Nobody has had a reply from Dr. Kardos. regards Maurizio Cauci - Original Message - From: "Tom Lane" [EMAIL PROTECTED] To: "Maurizio" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; "Bruce Momjian" [EMAIL PROTECTED]; "Kardos, Dr. Andreas" Sent: Tuesday, February 06, 2001 4:08 AM Subject: Re: [HACKERS] 7.1 beta 3 CHANGES FOR QNX "Maurizio" [EMAIL PROTECTED] writes: ECHO is defined in the following QNX gcc include files : termio.h termios.h If ECHO was not redefined in pgc.l you can't compile in embedded SQL C. Well, my question still stands: why aren't the other four flex outputs also broken? They all use ECHO. In any case, I'd prefer to see this fixed by not including termios.h rather than hacking up the .l files. Surely it doesn't need to be included everywhere, as src/include/port/qnx4.h is now causing to happen. In fact, it looks to me like qnx4.h probably includes and defines a lot more than it needs to; would you experiment with stripping it down? I am also checking for another problem. I have some errors if I compile pgsql without change the typedef Size in c.h. To succesfully compile pgsql I have changed typedef Size in int insteed size_t. That strikes me as *horribly* dangerous. There is too much code whose behavior might change in unpleasant ways if Size becomes a signed type. Please explain what problems you are seeing that make you think this is a good idea. Andreas, the QNX port is largely your work IIRC. What do you think of these issues? Have you tried 7.1beta on QNX? regards, tom lane
Re: [HACKERS] Postgre SQL for Windows
Quoting sourabh dixit [EMAIL PROTECTED]: Hello! Can anybody tell me the website from which I can download PostgreSQL for Windows95. I'm not sure if it will run under Win95, but I have it running fine under NT using Cygwin and WinIPC. While my linux box was down, I had to use it under NT to work on the JDBC driver. Peter -- Peter Mount [EMAIL PROTECTED] PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/ RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/
AW: [HACKERS] timestamp in pg_dump
I'd like to have pg_dump for 7.1 produce "timestamp with time zone" when dealing with timestamp type(s). That will prepare us for introducing a timestamp type without time zones, while allowing reasonable upgrades to 7.2. But the current timestamp does not store a timezone. timestamp with time zone is supposed to store and output the timezone that was inserted. The current timestamp has it messed up (sorry), since it does not store a timezone. It stores time in UTC and always converts output to the timezone derived from [PG]TZ. IMHO timestamp is currently closest to the ANSI timestamp without time zone. Especially if you always omit a timezone for input and ignore the timezone that is output. A reasonably easy upgrade is imho not possible :-( Andreas
[HACKERS] optimizer/planner ideas (repost)
Hello,
probably you remember my crazy idea involving using indexes
directly in scans (and resulting speedup).
The idea was given to me by experiences with M$SQL (it is
yes another M$ soft but its planner is probably better
than pg's - no flames please).
Because I studied M$ again I've got another ideas.
Every SQL query can be probably translated into joins without
need for "nested subquery" executor node.
In M$SQL7 each join has at least two properties: logical
and physical type. Physical types can be: {nested loop,
hash,merge} join and logical: {left,full,inner,semi-inner,anti-semi}.
It is the same in pgsql except for semi joins.
Inner semijoin scans its left input outputting all rows which
has its pair in right input but doesn't duplicate result when
there are duplicates at right.
The WHERE IN(select...), corelated EXISTS and ANY are
converted to it. This semijoin is simple to efectively implement
for all physical join types.
NOT IN, NOT EXISTS and ALL uses anti-semi-inner-join. The
join outputs lefts which can't be paired and don't duplicate
others. Again, simple implementation.
As I studied outputs from M$ planner, it uses those joins and
later tries to find optimal plan by combining ALL joins.
In pg we can't cross subplan node in optimizing (AFAIK). So
we can't swap relations in outer and inner plan even if it
would lead into mode effective plan.
The result is that in M$SQL7 almost all plans with [NOT]{IN,EXISTS}
I tried was much faster both in clean time of run and in number
of logical reads/scans.
Have anyone thought about it ?
regards, devik
[HACKERS] little bug in current CVS
Hi, after make clean, make failed with message: make[2]: Entering directory /home/postgres/cvs/pgsql/src/backend' prereqdir=`cd parser/ pwd` \ cd ../../src/include/parser/ rm -f parse.h \ ln -s $prereqdir/parse.h . ln: ./parser: File exists make[2]: *** [../../src/include/parser/parse.h] Error 1 Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Re: [HACKERS] Implementing an operator in C?
Am Sonntag, 4. Februar 2001 20:12 schrieben Sie:
Mario Weilguni [EMAIL PROTECTED] writes:
float8 num3 = numeric_float8(num1);
That won't work in the brave new world of 7.1 :-(. You need to do
something like
float8 num3 = DatumGetFloat8(DirectFunctionCall1(numeric_float8,
NumericGetDatum(num1)));
Ugly, I know ... but we have to be rigidly careful about converting
values to Datum and back in order to avoid portability problems.
A decent C compiler should've warned about type mismatches in your call,
BTW.
regards, tom lane
Thanks alot for the info, but the problem is elsewhere. Even a simple
function like
Datum
nef(PG_FUNCTION_ARGS)
{
Numeric num1 = PG_GETARG_NUMERIC(0);
PG_RETURN_BOOL(true);
}
will crash. The macro PG_GETARG_NUMERIC evaluates to:
((Numeric)pg_detoast_datum((struct varlena *) ((Pointer) ( (fcinfo-arg[0])))
and this pg_detoast_datum will lead to a crash (SIGSEGV). So I think I must
be doing something wrong here, isn't it?
Thanks!
Best regards,
Mario Weilguni
--
===
Mario Weilguni KPNQwest Austria GmbH
Senior Engineer Web Solutions Nikolaiplatz 4
tel: +43-316-8138248020 graz, austria
fax: +43-316-813824-26 http://www.kpnqwest.at
e-mail: [EMAIL PROTECTED]
===
[HACKERS] Re: [PATCHES] A Sparc/Linux patch (for 7.1), and a Linux rc.d/init.dscript....
On Sun, 4 Feb 2001, Peter Eisentraut wrote: Ryan Kirkpatrick writes: postgresql - This is a Linux distribution independent (or so I hope) init.d/rc.d script that makes use of pg_ctl. There is currently a few in ./contrib/linux of the pgsql source tree, but they are RedHat specific. This one is simple and self contained. Might be worth adding to the other scripts. I don't see how this can be more independent if it uses DAEMON=/home/postgres/bin/pg_ctl Ooops That is my mistake... Should have been /usr/local/pgsql/bin/pg_ctl. I have /usr/local/pgsql/ symlinked to /home (where there is more, faster disk space). I can submit a patch, or can some one just fix it? LOG="/usr/local/pgsql/server.log" What is wrong with that? There really is no standard on where to put the log file, so it is either here or /var/log. su - postgres sh -c "$DAEMON stop /dev/null" Hmm... What is wrong here, besides the ''? The '' can be replaced with '21 ' if that is more standard. an appropriate way to stop the server in a system shutdown situation. Uh... Isn't that the way you are supposed to stop it? pg_ctl stop? IMHO, rather than accumulating a bunch of versions that somebody liked better than the existing ones, why not provide actual scripts from actual distributions? Generic scripts will just lead to generic problems. Fine by me... I just put mine up as a suggestion, as the only other one in contrib was very RH specific. The one included with the debian package is very debian specific (and over complex in IMHO). I just submitted mine as a possible generic Linux version that should work with bash on most installation. If some one has a better idea, then by all means post it. Also, from the way I understand contrib, they are user submissions and are in no way assured to work on any other machine than the user's who submitted it. I take it as given anything in contrib might need a bit of editing to fit my needs. Anyway, just my response as one who has used Slackware, RedHat, and now Debian over the years, but who in no way claims to be an uber-Linux or Unix hacker or sysadmin. :) PS. I do play a part time Linux sysadmin in real though... --- | "For to me to live is Christ, and to die is gain."| |--- Philippians 1:21 (KJV) | --- | Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ | ---
Re: [HACKERS] ODBC Problem v7.1 beta4
Yes, I have the same problem... pgaccess also can't see any Views... "Steve Shaffer" [EMAIL PROTECTED] escreveu nas notícias de mensagem:[EMAIL PROTECTED] Developers, Pgsql v7.1 beta4 ODBC v6.50.00.00 RedHat v6.2 I upgraded from 7.03 to 7.1 beta4 yesterday see the following problem. After the upgrade, applications like Crystal Reports, MS Query, Brio, etc. now do not see the catalog of tables and fields in the database, login is through user postgres. SQL statements sent directly through the ODBC work correctly. The pgAdmin utility CAN see the catalog of all of the tables fields OK through the same login. I played with all of the options of the ODBC driver postgres security could not find a solution. Also, searched the site for any similar problems found no posts. Can anyone verify this problem? Any ideas? Thanks for the help, Steve Shaffer ([EMAIL PROTECTED])
[HACKERS] ADD CONSTRAINT ... FOREIGN KEY and custom data type.
For a project we are working on, I have created a custom postgresql data
type which is similar to MS SQL Server's uniqueidentifier data type. It uses
dynamic link library extension that calls the FreeDCE library to generate
GUIDs. Support for the data type and support functions is added to a
PostgreSQL database using the attached SQL script. The functions all seems
to work fine, including use of merge sorts and hash joins during SQL JOIN
statements when using the data type as part of a primary key. However
adding foreign key constraints sometimes causes a problem.
I never have a problem adding a foreign key to a parent table with a
multi-part key as long as the child table is empty. Adding data to the child
entity afterwards seems to properly enforce RI. However, if data exists in
the child entity, an RI check is performed on the existing data and this
check sometimes seems to break. As far as I can tell, the RI check in the
latter case seems to confuse the order the Key parts in either the Primary
Key or the Foreign Key. In the case of a multi-part key RI, it was
complaining that it couldn't perform a type conversion between the type of
two different key parts of the primary key.
So in a database with the following table definitions (OK I know it isn't
exactly great DB design to have 4 uniqueidentifiers in a PK, but please bear
with me) :
--
CREATE TABLE Mo_Cvg_Rptd (
Emp_Grp_ID uniqueidentifier NOT NULL,
Ben_Plan_ID uniqueidentifier NOT NULL,
Grp_Rate_ID uniqueidentifier NOT NULL,
Rate_Step_ID uniqueidentifier NOT NULL,
Cvg_Yr_Modate NOT NULL,
Rptg_Session_ID uniqueidentifier,
Mo_Cvg_Rptd_Sts_Cd int2,
Mo_Except_Sts_Cd int2,
Mo_Except_Desc varchar(150),
Mdfy_Dt DATETIME NOT NULL DEFAULT date('now'),
PRIMARY KEY (Emp_Grp_ID, Ben_Plan_ID, Grp_Rate_ID,
Rate_Step_ID, Cvg_Yr_Mo)
);
CREATE TABLE Prior_Mo_Prd_Adjmt (
Emp_Grp_ID uniqueidentifier NOT NULL,
Ben_Plan_ID uniqueidentifier NOT NULL,
Grp_Rate_ID uniqueidentifier NOT NULL,
Rate_Step_ID uniqueidentifier NOT NULL,
Cvg_Yr_Modate NOT NULL,
Prior_Prd_Adjmt_Amt int2,
Prior_Prd_Adjmt_Desc varchar(150),
Prior_Prd_Adjmt_Except_Sts_Cd int2,
Prior_Prd_Adjmt_Except_Desc varchar(150),
PRIMARY KEY (Emp_Grp_ID, Ben_Plan_ID, Grp_Rate_ID,
Rate_Step_ID, Cvg_Yr_Mo)
);
ALTER TABLE Prior_Mo_Prd_Adjmt
ADD CONSTRAINT FK_PriorMoPrdAdjmt_MoCvgRptd FOREIGN KEY(Emp_Grp_ID,
Ben_Plan_ID,
Grp_Rate_ID,
Rate_Step_ID,
Cvg_Yr_Mo)
REFERENCES Mo_Cvg_Rptd;
--
If I want to change a column in Prior_Mo_Prd_Adjmt (with the aid of Erwin),
I have to drop the table and recreate it with a script similar to the
following:
**
CREATE TABLE prior_mo_prd_adjmtL25D434 (emp_grp_id uniqueidentifier,
ben_plan_id uniqueidentifier, grp_rate_id
uniqueidentifier, rate_step_id uniqueidentifier,
cvg_yr_mo date, prior_prd_adjmt_amt int4, prior_prd_adjmt_desc
varchar(150), prior_prd_adjmt_except_sts_cd int2,
prior_prd_adjmt_except_desc varchar(150));
INSERT INTO prior_mo_prd_adjmtL25D434 (emp_grp_id, ben_plan_id,
grp_rate_id,
rate_step_id, cvg_yr_mo, prior_prd_adjmt_amt, prior_prd_adjmt_desc,
prior_prd_adjmt_except_sts_cd, prior_prd_adjmt_except_desc)
SELECT emp_grp_id, ben_plan_id, grp_rate_id,
rate_step_id, cvg_yr_mo, prior_prd_adjmt_amt, prior_prd_adjmt_desc,
prior_prd_adjmt_except_sts_cd, prior_prd_adjmt_except_desc
FROM prior_mo_prd_adjmt;
DROP TABLE prior_mo_prd_adjmt;
CREATE TABLE Prior_Mo_Prd_Adjmt (
Emp_Grp_ID uniqueidentifier NOT NULL,
Ben_Plan_ID uniqueidentifier NOT NULL,
Grp_Rate_ID uniqueidentifier NOT NULL,
Rate_Step_ID uniqueidentifier NOT NULL,
Cvg_Yr_Modate NOT NULL,
Prior_Prd_Adjmt_Amt numeric(9,2),
Prior_Prd_Adjmt_Desc varchar(150),
Prior_Prd_Adjmt_Except_Sts_Cd int2,
Prior_Prd_Adjmt_Except_Desc varchar(150),
PRIMARY KEY (Emp_Grp_ID, Ben_Plan_ID, Grp_Rate_ID,
Rate_Step_ID, Cvg_Yr_Mo)
);
CREATE UNIQUE INDEX IDX_Prior_Mo_Prd_Adjmt_PK ON Prior_Mo_Prd_Adjmt
(
Emp_Grp_ID,
Ben_Plan_ID,
Grp_Rate_ID,
Rate_Step_ID,
Cvg_Yr_Mo
);
ALTER TABLE Prior_Mo_Prd_Adjmt
ADD CONSTRAINT FK_PriorMoPrdAdjmt_MoCvgRptd FOREIGN KEY(Emp_Grp_ID,
Ben_Plan_ID,
[HACKERS] Re: TODO list: Allow Java server-side programming
PHP can run java code. It would be easiest, because php doesn't parse php pages, the Zend engine is linked to php to actually parse. Which would make Zend easy to add into Postgresql, (which already runs under apache, which is non-threaded). The only issue is the Zend license.. Of course, this may sound crazy and expensive, but you could throw some apache code in there, and allow any language that works under apache work under postgresql. Call me crazy, but that would allow people to run any parsed language inside of postgresql.
[HACKERS] optimizer/planner ideas
Hello,
probably you remember my crazy idea involving using indexes
directly in scans (and resulting speedup).
The idea was given to me by experiences with M$SQL (it is
yes another M$ soft but its planner is probably better
than pg's - no flames please).
Because I studied M$ again I've got another ideas.
Every SQL query can be probably translated into joins without
need for "nested subquery" executor node.
In M$SQL7 each join has at least two properties: logical
and physical type. Physical types can be: {nested loop,
hash,merge} join and logical: {left,full,inner,semi-inner,anti-semi}.
It is the same in pgsql except for semi joins.
Inner semijoin scans its left input outputting all rows which
has its pair in right input but doesn't duplicate result when
there are duplicates at right.
The WHERE IN(select...), corelated EXISTS and ANY are
converted to it. This semijoin is simple to efectively implement
for all physical join types.
NOT IN, NOT EXISTS and ALL uses anti-semi-inner-join. The
join outputs lefts which can't be paired and don't duplicate
others. Again, simple implementation.
As I studied outputs from M$ planner, it uses those joins and
later tries to find optimal plan by combining ALL joins.
In pg we can't cross subplan node in optimizing (AFAIK). So
we can't swap relations in outer and inner plan even if it
would lead into mode effective plan.
The result is that in M$SQL7 almost all plans with [NOT]{IN,EXISTS}
I tried was much faster both in clean time of run and in number
of logical reads/scans.
Have anyone thought about it ?
regards, devik
Re: [HACKERS] little bug in current CVS
On Tue, 6 Feb 2001, Tom Lane wrote: Oleg Bartunov [EMAIL PROTECTED] writes: make[2]: Entering directory /home/postgres/cvs/pgsql/src/backend' prereqdir=`cd parser/ pwd` \ cd ../../src/include/parser/ rm -f parse.h \ ln -s $prereqdir/parse.h . ln: ./parser: File exists make[2]: *** [../../src/include/parser/parse.h] Error 1 Hm. I bet your shell is failing to strip whitespace from the output of pwd, so that the ln command ends up looking like ln -s /home/postgres/cvs/pgsql/src/backend/parser /parse.h . Can you check that theory by inserting an 'echo'? you're right. shell is BASH_VERSION='2.04.0(1)-release' Makefile looks too complex: $(top_builddir)/src/include/parser/parse.h: $(srcdir)/parser/parse.h prereqdir=`cd $(dir $) pwd` \ cd $(dir $@) rm -f $(notdir $@) \ $(LN_S) $$prereqdir/$(notdir $) . We're already in src/backend directory, why not use ln -sf parser/parse.h . regards, tom lane Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Re: [HACKERS] little bug in current CVS
Oleg Bartunov writes: after make clean, make failed with message: make[2]: Entering directory /home/postgres/cvs/pgsql/src/backend' prereqdir=`cd parser/ pwd` \ cd ../../src/include/parser/ rm -f parse.h \ ln -s $prereqdir/parse.h . ln: ./parser: File exists make[2]: *** [../../src/include/parser/parse.h] Error 1 Try changing the second line to this prereqdir=`CDPATH=: ; cd parser/ pwd` \ -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Using Threads
On Tue, 6 Feb 2001, Myron Scott wrote: There are many many globals I had to work around including all the memory management stuff. I basically threw everything into and "environment" variable which I stored in a thread specific using thr_setspecific. Yes, it's good. I working on multi-thread application server (http://mape.jcu.cz) and I use for this project some things from PG (like mmgr), I planning use same solution. Performance is acually very good for what I am doing. I was able to batch commit transactions which cuts down on fsync calls, use prepared statements from my client using CORBA, and the various locking calls for the threads (cond_wait,mutex_lock, and sema_wait) seem pretty fast. I did some performance tests for inserts 20 clients, 900 inserts per client, 1 insert per transaction, 4 different tables. 7.0.2About10:52 average completion multi-threaded2:42 average completion 7.1beta3 1:13 average completion It is very very good for time for 7.1, already look forward to 7.2! :-) BTW, I not sure if you anytime in future will see threads in official PostgreSQL and if you spending time on relevant things (IMHO). Karel
Re: [HACKERS] Re: [PATCHES] A Sparc/Linux patch (for 7.1), and a Linuxrc.d/init.d script....
On Sun, 4 Feb 2001, Peter Eisentraut wrote: Ryan Kirkpatrick writes: postgresql - This is a Linux distribution independent (or so I hope) init.d/rc.d script that makes use of pg_ctl. There is currently a few in ./contrib/linux of the pgsql source tree, but they are RedHat specific. This one is simple and self contained. Might be worth adding to the other scripts. I don't see how this can be more independent if it uses DAEMON=/home/postgres/bin/pg_ctl Ooops That is my mistake... Should have been /usr/local/pgsql/bin/pg_ctl. I have /usr/local/pgsql/ symlinked to /home (where there is more, faster disk space). I can submit a patch, or can some one just fix it? Change made. LOG="/usr/local/pgsql/server.log" What is wrong with that? There really is no standard on where to put the log file, so it is either here or /var/log. su - postgres sh -c "$DAEMON stop /dev/null" Hmm... What is wrong here, besides the ''? The '' can be replaced with '21 ' if that is more standard. Change made. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[HACKERS] Include files for SPI are not installed
Certain include files are installed by src/include/Makefile and by
interfaces/libpq++/Makefile. However, they in turn include others that
are not installed, thus obviating the usefulness of the ones that are.
The missing files are these:
access/heapam.h
access/htup.h
access/relscan.h
access/rmgr.h
access/sdir.h
access/skey.h
access/strat.h
access/transam.h
access/tupdesc.h
access/tupmacs.h
access/xact.h
access/xlogdefs.h
access/xlog.h
access/xlogutils.h
catalog/pg_am.h
catalog/pg_attribute.h
catalog/pg_class.h
catalog/pg_language.h
catalog/pg_proc.h
catalog/pg_type.h
executor/execdefs.h
executor/execdesc.h
executor/executor.h
executor/hashjoin.h
executor/tuptable.h
nodes/execnodes.h
nodes/memnodes.h
nodes/nodes.h
nodes/params.h
nodes/parsenodes.h
nodes/pg_list.h
nodes/plannodes.h
nodes/primnodes.h
nodes/relation.h
pgconnection.h
pgdatabase.h
pgtransdb.h
rewrite/prs2lock.h
storage/block.h
storage/buffile.h
storage/buf.h
storage/bufmgr.h
storage/bufpage.h
storage/fd.h
storage/ipc.h
storage/item.h
storage/itemid.h
storage/itemptr.h
storage/lmgr.h
storage/lock.h
storage/off.h
storage/page.h
storage/relfilenode.h
storage/shmem.h
storage/spin.h
tcop/dest.h
tcop/pquery.h
tcop/tcopprot.h
tcop/utility.h
utils/builtins.h
utils/datetime.h
utils/datum.h
utils/fcache.h
utils/hsearch.h
utils/memutils.h
utils/nabstime.h
utils/numeric.h
utils/portal.h
utils/rel.h
utils/syscache.h
utils/timestamp.h
utils/tqual.h
The list can be regenerated with the attached script.
Example:
$ pg_includes /usr/local/pgsql/include
#!/bin/sh
PGINCLUDEDIR=$1
[ -z "$PGINCLUDEDIR" ] PGINCLUDEDIR=/usr/include/postgresql
find $PGINCLUDEDIR -name '*.h' |
sed "s|$PGINCLUDEDIR/||" /tmp/$$
lastlc=-1
lc=0
while [ $lc -ne $lastlc ]
do
lastlc=$lc
(
(
cd ~/mypackages/pg7.1/postgresql-7.1beta4/src/include
cat /tmp/$$ | xargs grep '#include' 2/dev/null
cd /usr/include/postgresql
cat /tmp/$$ | xargs grep '#include' 2/dev/null
) |
grep -v '' |
sed 's/^.*"\(.*\)".*$/\1/'
cat /tmp/$$
) |
sort -u /tmp/$$-1
mv /tmp/$$-1 /tmp/$$
lc=`wc -l /tmp/$$ | awk '{print $1}'`
done
(
cat /tmp/$$
find $PGINCLUDEDIR -name '*.h' |
sed "s|$PGINCLUDEDIR/||"
) | sort | uniq -u
rm /tmp/$$
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
"He hath not dealt with us after our sins; nor rewarded
us according to our iniquities. For as the heaven is
high above the earth, so great is his mercy toward
them that fear him. As far as the east is from the
west, so far hath he removed our transgressions from
us." Psalms 103:10-12
Re: [HACKERS] OID from insert has extra letter
On Mon, Feb 05, 2001 at 09:17:45PM -0500, Tom Lane wrote: Yes, on looking at it I see that someone broke PQoidStatus() in 7.0. If you want to fix your copy, the patch (line numbers are for current CVS) is Index: fe-exec.c === RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces/libpq/fe-exec.c,v retrieving revision 1.98 retrieving revision 1.100 diff -c -r1.98 -r1.100 *** fe-exec.c 2001/01/24 19:43:30 1.98 --- fe-exec.c 2001/02/06 02:02:27 1.100 *** *** 2035,2041 if (len 23) len = 23; strncpy(buf, res-cmdStatus + 7, len); ! buf[23] = '\0'; return buf; } --- 2035,2041 if (len 23) len = 23; strncpy(buf, res-cmdStatus + 7, len); ! buf[len] = '\0'; return buf; } Hmm, is there some undocumented feature of strncpy that I don't know about, where it modifies the passed length variable (which would be hard, since it's pass by value)? Otherwise, doesn't this patch just replace the constant '23' with the variable 'len', set to 23? Ross
[HACKERS] Re: [PATCHES] configure.in patch for readline and curses.
Rick Robino writes: psql starts up with readline support turned on by default. If readline/curses is broken, this may show up at runtime as a pq_recvbuf error and a core dump. psql isn't obvious about the relationship to readline, creating a mystery for first-timers. Since it is readline, and it is on by default, just maybe that first-timer might reconfigure turning "luxuries" off and psql will work. That looks like a rather unusual way to proceed. The alternative is them finding that obscure scrap of advice (not in doc/*) associating recvbuf errors with readline support. The other alternative is fixing the underlying problem. I had this problem on a very typically setup Solaris but did not look for a way to build w/o readline. Yes, we have had several reports that termcap and ncurses don't like each other on Solaris. I'm going to alter configure to check for only one of the two. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] OID from insert has extra letter
*** fe-exec.c 2001/01/24 19:43:30 1.98 --- fe-exec.c 2001/02/06 02:02:27 1.100 *** *** 2035,2041 if (len 23) len = 23; strncpy(buf, res-cmdStatus + 7, len); ! buf[23] = '\0'; return buf; } --- 2035,2041 if (len 23) len = 23; strncpy(buf, res-cmdStatus + 7, len); ! buf[len] = '\0'; return buf; } Hmm, is there some undocumented feature of strncpy that I don't know about, where it modifies the passed length variable (which would be hard, since it's pass by value)? Otherwise, doesn't this patch just replace the constant '23' with the variable 'len', set to 23? What if len 23? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] OID from insert has extra letter
On Tue, Feb 06, 2001 at 01:21:00PM -0500, Bruce Momjian wrote: What if len 23? mea culpa. Must go eat lunch. No sugar to brain. (and no, I didn't put the original error in :-) Ross
Re: [HACKERS] OID from insert has extra letter
On Tue, Feb 06, 2001 at 01:21:00PM -0500, Bruce Momjian wrote: *** fe-exec.c 2001/01/24 19:43:30 1.98 --- fe-exec.c 2001/02/06 02:02:27 1.100 *** *** 2035,2041 if (len 23) len = 23; strncpy(buf, res-cmdStatus + 7, len); ! buf[23] = '\0'; return buf; } --- 2035,2041 if (len 23) len = 23; strncpy(buf, res-cmdStatus + 7, len); ! buf[len] = '\0'; return buf; } Hmm, is there some undocumented feature of strncpy that I don't know about, where it modifies the passed length variable (which would be hard, since it's pass by value)? Otherwise, doesn't this patch just replace the constant '23' with the variable 'len', set to 23? What if len 23? If len 23, then strncpy will have terminated the destination already. Poking out buf[23] just compensates for a particular bit of brain damage in strncpy. Read the man page: The strncpy() function is similar [to strcpy], except that not more than n bytes of src are copied. Thus, if there is no null byte among the first n bytes of src, the result wil not be null-terminated. Thus, the original code is OK, except probably the literal "23" in place of what should be a meaningful symbolic constant, or (at least!) sizeof(buf) - 1. BTW, that static buffer in PGoidStatus is likely to upset threaded client code... ob-ed To null-terminate strings is an Abomination. /ob-ed Nathan Myers [EMAIL PROTECTED]
[HACKERS] Re: 25 March 2001 bug
On Tue, 6 Feb 2001, Guest User wrote: Apologies if this is the wrong place to send a question Please use, hackers (or other PG) list. More heads more know, more eyes more view :-) Do you know if there is a patch for this bug and if so where I might be able to find it? I think I'm using 7.0.3 too and I'm kind of stuck. I not sure, but it is probably fixed in 7.1 only without a backport patch... Comments? Karel
Re: [HACKERS] using the same connection?
On Tue, Feb 06, 2001 at 11:08:49AM -0500, Mathieu Dube wrote: Hi y'all, Is it a bad idea for an app to keep just a couple of connections to a database, put semaphore/mutex on them and reuse them all through the program? Of course I would check if their PQstatus isnt at CONNECTION_BAD and reconnect if they were... You would have to hold the lock from BEGIN until COMMIT. Otherwise, connection re-use is normal. Nathan Myers [EMAIL PROTECTED]
Re: [HACKERS] using the same connection?
Well actually this particular connection is just for selects... On Tue, 06 Feb 2001, you wrote: On Tue, Feb 06, 2001 at 11:08:49AM -0500, Mathieu Dube wrote: Hi y'all, Is it a bad idea for an app to keep just a couple of connections to a database, put semaphore/mutex on them and reuse them all through the program? Of course I would check if their PQstatus isnt at CONNECTION_BAD and reconnect if they were... You would have to hold the lock from BEGIN until COMMIT. Otherwise, connection re-use is normal. Nathan Myers [EMAIL PROTECTED] -- Mathieu Dube Mondo-Live www.flipr.com
Re: [HACKERS] Include files for SPI are not installed
Oliver Elphick wrote: Certain include files are installed by src/include/Makefile and by interfaces/libpq++/Makefile. However, they in turn include others that are not installed, thus obviating the usefulness of the ones that are. The missing files are these: [snip] The list can be regenerated with the attached script. Or use this one-liner (CWD=the include directory in the source dist): /lib/cpp -M -I. -I../backend executor/spi.h | \ xargs -n 1| \ grep \\W| \ grep -v ^/| \ grep -v spi.o | \ grep -v spi.h | \ sort (There are better ways of doing the regexps, I know). I use this in the RPM spec file to pull over the SPI headers, and have had to do so since 6.5.x days. Bruce, can we add a TODO item for make install to install _all_ necessary headers, including SPI ones? It is not at all necessary to have a source tree lying around to do SPI development (or at least it _shouldn't_ be necessary). A full source tree, configured and built, according to du, takes about 48MB of space (a pristine tree takes 36MB or so in comparison). The complete set of headers takes a little less than 1MB of space. (1MB of _headers_? Yow!) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Include files for SPI are not installed
Karel Zak wrote: On Tue, 6 Feb 2001, Oliver Elphick wrote: Certain include files are installed by src/include/Makefile and by interfaces/libpq++/Makefile. However, they in turn include others that are not installed, thus obviating the usefulness of the ones that are. In your module you can use arbitrary routines from PG not only SPI, for example you trigger needs work with some datetypes and for this needs include anything from include/utils/ ... It expect install *all* header files. Not is better download PG sources and use -I option for your gcc? No. Full tree takes at minimum 36MB -- even pulling the _entire_ src/include tree over is only 2MB. I expect header files on /usr/include/pgsql for client programming not for SPI. Why? I know of several people doing SPI work with no source tree installed. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
[HACKERS] Re: [PATCHES] A Sparc/Linux patch (for 7.1), and a Linux rc.d/init.d script....
su - postgres sh -c "$DAEMON stop /dev/null" Hmm... What is wrong here, besides the ''? The '' can be replaced with '21 ' if that is more standard. It won't do what you want. You want '/dev/null 21'. Change made. Hmmm, I don't see this change in cvsweb. Florent -- [EMAIL PROTECTED]
Re: [HACKERS] Re: [PATCHES] A Sparc/Linux patch (for 7.1), and a Linux rc.d/init.d script....
su - postgres sh -c "$DAEMON stop /dev/null" Hmm... What is wrong here, besides the ''? The '' can be replaced with '21 ' if that is more standard. It won't do what you want. You want '/dev/null 21'. Yes, I knew he wanted /dev/null 21. I just fixed it. Change made. Hmmm, I don't see this change in cvsweb. Thanks. Seems I overwrote it with his new version. Done now. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[HACKERS] psql: why not pset PROMPT[0-2] ?
(In psql:)
I need to modify the 2nd prompt. So i looked at the sources:
I leave the validity test (of the name of the option/param) to SetVariable !!
Here is the patch:
diff -c /internet/cvs/pgsql/src/bin/psql/command.c.~1~
/internet/cvs/pgsql/src/bin/psql/command.c
*** /internet/cvs/pgsql/src/bin/psql/command.c.~1~ Tue Feb 6 22:26:00 2001
--- /internet/cvs/pgsql/src/bin/psql/command.c Tue Feb 6 22:26:00 2001
***
*** 1745,1750
--- 1745,1760
}
+
+ /* toggle use of pager */
+ else if (strncmp(param, "PROMPT",6) == 0)
+ {
+ SetVariable(pset.vars, param, value); /* SetVariable takes care of whether
+param is actually valid !! */
+ }
+
+
+
+
else
{
psql_error("\\pset: unknown option: %s\n", param);
diff -c /internet/cvs/pgsql/src/bin/psql/tab-complete.c.~2~
/internet/cvs/pgsql/src/bin/psql/tab-complete.c
*** /internet/cvs/pgsql/src/bin/psql/tab-complete.c.~2~ Tue Feb 6 22:24:06 2001
--- /internet/cvs/pgsql/src/bin/psql/tab-complete.c Tue Feb 6 22:24:06 2001
***
*** 706,713
else if (strcmp(prev_wd, "\\pset") == 0)
{
char *my_list[] = {"format", "border", "expanded", "null",
"fieldsep",
! "tuples_only", "title", "tableattr", "pager",
! "recordsep", NULL};
COMPLETE_WITH_LIST(my_list);
}
--- 706,713
else if (strcmp(prev_wd, "\\pset") == 0)
{
char *my_list[] = {"format", "border", "expanded", "null",
"fieldsep",
!"tuples_only", "title", "tableattr", "pager",
!"PROMPT1","PROMPT2","PROMPT3","recordsep",
NULL};
COMPLETE_WITH_LIST(my_list);
}
Re: [HACKERS] psql: why not pset PROMPT[0-2] ?
Because pset sets parameters of the table output. Prompts have nothing to do with table output. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] a contrib function to query current locale values
Hi,
I've written a small function that should go into contrib for 7.1
As locale issues are quite tricky, being able to find out what locale
backend thinks it is in is a good thing ;)
from my README.getlocale:
getlocale('category')
-
return the locale setting of the backend
(see ' man setlocale for definitions)
If category is one of LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY,
LC_NUMERIC, LC_TIME the corresponding setting is returned.
[hannu@taru contrib]$ psql -c "select getlocale('LC_COLLATE')"
getlocale
---
en_US
(1 row)
for LC_ALL (and anything else) a string like the following is returned
[hannu@taru getlocale]$ psql -c "select getlocale('*')"
getlocale
LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=en_US;LC_MONETARY=en_US;LC_MESSAGES=C
(1 row)
IMHO some form of it should end up in the main distribution, probably by
7.2.
-
Hannu Krosing [EMAIL PROTECTED]
getlocale.tar.gz
Re: [HACKERS] OID from insert has extra letter
[EMAIL PROTECTED] (Nathan Myers) writes: Thus, the original code is OK, except probably the literal "23" in place of what should be a meaningful symbolic constant, or (at least!) sizeof(buf) - 1. No, the original code is NOT ok. Read the man page again. As the code stood, the only null that ever got written to the buffer was the one installed in buf[23]. The only reason it appeared to work at all was that buf would start out all zeroes --- but after one or more uses it's not all zeroes anymore. See the bug report that started the thread ... BTW, that static buffer in PGoidStatus is likely to upset threaded client code... Yeah, we know. The routine is deprecated now because of that. regards, tom lane
Re: [HACKERS] OID from insert has extra letter
On Tue, Feb 06, 2001 at 07:08:20PM -0500, Tom Lane wrote: [EMAIL PROTECTED] (Nathan Myers) writes: Thus, the original code is OK, except probably the literal "23" in place of what should be a meaningful symbolic constant, or (at least!) sizeof(buf) - 1. No, the original code is NOT ok. Read the man page again. As the code stood, the only null that ever got written to the buffer was the one installed in buf[23]. The only reason it appeared to work at all was that buf would start out all zeroes --- but after one or more uses it's not all zeroes anymore. See the bug report that started the thread ... Seems it's a non-portable behavior: The strncpy() function is similar, except that not more than n bytes of src are copied. Thus, if there is no null byte among the first n bytes of src, the result wil not be null-terminated. In the case where the length of src is less than that of n, the remainder of dest will be padded with nulls. I've already forgotten what platform the original bug report came from. Ross
Re: [HACKERS] Include files for SPI are not installed
Tom Lane wrote: I agree with Karel on this --- it's difficult to visualize doing useful SPI work without a source tree at hand, and it also seems unlikely that SPI authors would get along for long with *only* those header files needed to pull in spi.h. So I think it's pretty pointless to add just those header files. I'm waiting to see what Mike Mascari says about the issue, as he is doing SPI work from an RPM install (no source) and was the gadfly (in the best sense of the word) that got me putting the SPI headers in in the first place. Besides headers, what files are required? Makefile.global? Makefile.shlib? ??? What would make more sense is for the standard install to install only those headers needed for *client side* programming, and then to have an optional install target that installs the whole darn src/include tree. I can go for that. (Or in RPM terms, a client-devel RPM and a separate server-devel RPM that adds the rest of src/include.) Anything in between is guaranteed to be the wrong set of files. Ok, RPM users who do SPI work, sound off. Which would you like? I'll admit to liking the idea Tom has put forward, but I want more feedback. I would have a 'postgresql-devel' and a 'postgresql-devel-spi' -- to throw out a tentative name. I am loath to split the existing -devel subpackage into two packages with different names, throwing out the original, but I can do that as well, if that is the consensus. The contents of -devel would be the headers installed by 'make install' -- although I question why spi.h and some friends are installed in the first place, given the 'client-side' focus (but this _is_ what Tom just said -- I'm just being a little more specific). The contents of -devel-spi (or maybe just -spi) would be all the other headers (no duplicates) (again, expounding upon what Tom said already). Comments? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] OID from insert has extra letter
On Tue, Feb 06, 2001 at 06:17:46PM -0600, Ross J. Reedstrom wrote: Seems it's a non-portable behavior: The strncpy() function is similar, except that not more than n bytes of src are copied. Thus, if there is no null byte among the first n bytes of src, the result wil not be null-terminated. In the case where the length of src is less than that of n, the remainder of dest will be padded with nulls. I've already forgotten what platform the original bug report came from. Just checked, D'Arcy never told us. But it doesn't matter, the manpage lies. I just tested it with a tiny little program that copies two different constant strings into a buffer. Nothing get's padded with nulls, as Tom knew. Once again, experience trumps book knowledge. (Checking a couple random examples from my own code, I seem to have lucked out: I've a habit of zeroing my buffers myself) Ross
Re: [HACKERS] Duplicate OIDs in pg_attribute
Joe Mitchell [EMAIL PROTECTED] writes: I noticed that pg_attribute has rows with the same OID! Joe previously asked me about this off-list, and I replied thus: This appears to be due to the incredibly grotty coding used in AppendAttributeTuples in src/backend/catalog/index.c --- rather than building tuples in any of several sane fashions, it's using an unholy combination of memmove and heap_modifytuple to update a single tuple object into successive states that correspond to the rows it needs to add to the table. Unfortunately the OID assigned by the first heap_insert gets carried along to the subsequent states, so the later calls to heap_insert don't think they should assign new OIDs. Good catch, Joe! This bug has probably been there since the beginning of time. It's evidently got no serious consequences (since in reality, OID uniqueness is not assumed for this table), but it ought to be fixed. A quick-hack solution would be to zero out the tuple's OID before each heap_insert, but really AppendAttributeTuples should be rewritten to construct each tuple independently in the first place. A quick 'glimpse' shows no other uses of heap_modifytuple except to update an existing tuple, so evidently no one was foolish enough to copy this technique. I recommend putting this on the TODO for 7.2. We can't fix it now unless we want to force an initdb. regards, tom lane
Re: [HACKERS] Include files for SPI are not installed
I agree with Karel on this --- it's difficult to visualize doing useful SPI work without a source tree at hand, and it also seems unlikely that SPI authors would get along for long with *only* those header files needed to pull in spi.h. So I think it's pretty pointless to add just those header files. What would make more sense is for the standard install to install only those headers needed for *client side* programming, and then to have an optional install target that installs the whole darn src/include tree. (Or in RPM terms, a client-devel RPM and a separate server-devel RPM that adds the rest of src/include.) Anything in between is guaranteed to be the wrong set of files. Agreed. I hesitate to copy all those *.h files when few people use them. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] OID from insert has extra letter
"Ross J. Reedstrom" [EMAIL PROTECTED] writes: Seems it's a non-portable behavior: Not at all. The code is asking strncpy to copy n bytes, where n is known to be = strlen of the source string. Every spec-conforming implementation of strncpy will copy n bytes, no more, no less, and will *not* add a trailing null after them. The only reason the code appeared to work is that it was dealing with a static buffer that starts out all zeroes, so the trailing null was already in place. Until the buffer had been used for a longer OID, that is. regards, tom lane
Re: [HACKERS] Duplicate OIDs in pg_attribute
Good catch, Joe! This bug has probably been there since the beginning of time. It's evidently got no serious consequences (since in reality, OID uniqueness is not assumed for this table), but it ought to be fixed. A quick-hack solution would be to zero out the tuple's OID before each heap_insert, but really AppendAttributeTuples should be rewritten to construct each tuple independently in the first place. A quick 'glimpse' shows no other uses of heap_modifytuple except to update an existing tuple, so evidently no one was foolish enough to copy this technique. I recommend putting this on the TODO for 7.2. We can't fix it now unless we want to force an initdb. Added to TODO: * Prevent pg_attribute from having duplicate oids for indexes -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Include files for SPI are not installed
Lamar Owen [EMAIL PROTECTED] writes: Tom Lane wrote: What would make more sense is for the standard install to install only those headers needed for *client side* programming, and then to have an optional install target that installs the whole darn src/include tree. I can go for that. (Or in RPM terms, a client-devel RPM and a separate server-devel RPM that adds the rest of src/include.) Anything in between is guaranteed to be the wrong set of files. Ok, RPM users who do SPI work, sound off. Which would you like? I'll admit to liking the idea Tom has put forward, but I want more feedback. I would have a 'postgresql-devel' and a 'postgresql-devel-spi' -- to throw out a tentative name. I am loath to split the existing -devel subpackage into two packages with different names, throwing out the original, but I can do that as well, if that is the consensus. client-devel and server-devel are the right division IMHO. SPI is a subset of server-side development, but not all server-side code needs SPI. Consider user-written functions and datatypes. These guys do not need SPI (usually), but they do need access to header files that aren't installed now. The contents of -devel would be the headers installed by 'make install' -- although I question why spi.h and some friends are installed in the first place, given the 'client-side' focus (but this _is_ what Tom just said -- I'm just being a little more specific). My thought was that we'd remove spi.h from the minimal install, along with anything else that's not useful for client-side programming. Thus the standard install footprint would get smaller. I haven't looked to see exactly what the list of client-side headers should be, but if people like this idea I will do the legwork to make the list. regards, tom lane
Re: [HACKERS] Re: [BUGS] syslog logging setup broken?
The man page suggests that nohup is required to init postmaster, I know this isn't true but to implement an example init file and not match up with the man page seemed foolish. I guess nohup would stop postmaster doing something awfull if it doesn't handle HUP properly but I very much doubt that you guys fail to handle HUP. Good point. postmaster in 7.1 uses HUP signal to re-read postgresql.conf. It seems we should not use nohup to start postmaster. -- Tatsuo Ishii
[HACKERS] Auto-indexing
Is it a feasible idea that PostgreSQL could detect when an index would be handy, and create it itself, or at least log that a table is being queried but the indices are not appropriate? I suggest this as it's a feature of most windows databases, and MySQL does it. I think it would be a great timesaver as we have hundreds of different queries, and it's a real pain to have to EXPLAIN them all, etc. Is that possible? Feasible? Chris -- Christopher Kings-Lynne Family Health Network (ACN 089 639 243)
Re: [HACKERS] Auto-indexing
* Christopher Kings-Lynne [EMAIL PROTECTED] [010206 18:29] wrote: Is it a feasible idea that PostgreSQL could detect when an index would be handy, and create it itself, or at least log that a table is being queried but the indices are not appropriate? I suggest this as it's a feature of most windows databases, and MySQL does it. I think it would be a great timesaver as we have hundreds of different queries, and it's a real pain to have to EXPLAIN them all, etc. Is that possible? Feasible? Probably both, but if it's done there should be options to: .) disable it completely or by table/database or even threshold or disk free parameters (indicies can be large) .) log any auto-created databases to inform the DBA. .) if disabled optionally log when it would have created an index on the fly. (suggest an index) .) expire old and unused auto-created indecies. Generally Postgresql assumes the user knows what he's doing, but it couldn't hurt too much to provide an option to have it assist the user. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
[HACKERS] [GENERAL] Off-topic: usenet sources?
Reliable rumor has it that Deja.com (formerly Dejanews) is going out of business, possibly as early as this week, and pulling the plug completely (I worked there '97-'99). They've already laid off all but a small handful of the peak of ~125 employees. That was the premier source for technical archives, IMO. What a loss. Question: What's the next best site/tool for searching technical usenet archives?? Regards, Ed Loehr
