Add.

diff --git a/doc/TODO.detail/prepare b/doc/TODO.detail/prepare
index 12734ca4fc52743b3cf50467b2bd22038fd52be5..50f2b32f36e649e5741f04f7dd9d4dbff37bf654 100644 (file)
--- a/doc/TODO.detail/prepare
+++ b/doc/TODO.detail/prepare
@@ -171,3 +171,205 @@ advertising :-)
 
 
 
+From [email protected] Mon Nov  6 03:27:32 2000
+Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
+   by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id DAA28404
+   for ; Mon, 6 Nov 2000 03:27:32 -0500 (EST)
+Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
+   by mail.postgresql.org (8.11.1/8.11.1) with SMTP id eA68Pos51966;
+   Mon, 6 Nov 2000 03:25:50 -0500 (EST)
+   (envelope-from [email protected])
+Received: from ara.zf.jcu.cz (ara.zf.jcu.cz [160.217.161.4])
+   by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id eA68Fes50414
+   for ; Mon, 6 Nov 2000 03:15:40 -0500 (EST)
+   (envelope-from [email protected])
+Received: from localhost (zakkr@localhost)
+   by ara.zf.jcu.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id JAA20862;
+   Mon, 6 Nov 2000 09:15:04 +0100
+Date: Mon, 6 Nov 2000 09:15:04 +0100 (CET)
+From: Karel Zak 
+To: Christof Petig 
+cc: Zeugswetter Andreas SB ,
+        The Hermit Hacker , [email protected]
+Subject: Re: AW: [HACKERS] Re: [GENERAL] Query caching
+In-Reply-To: <[email protected]>
+Message-ID: 
+MIME-Version: 1.0
+Content-Type: TEXT/PLAIN; charset=US-ASCII
+Precedence: bulk
+Sender: [email protected]
+Status: OR
+
+
+On Fri, 3 Nov 2000, Christof Petig wrote:
+
+> Karel Zak wrote:
+> 
+> > On Thu, 2 Nov 2000, Zeugswetter Andreas SB wrote:
+> >
+> > >
+> > > > Well I can re-write and resubmit this patch. Add it as a
+> > > > compile time option
+> > > > is not bad idea. Second possibility is distribute it as patch
+> > > > in the contrib
+> > > > tree. And if it until not good tested not dirty with this main tree...
+> > > >
+> > > >  Ok, I next week prepare it...
+> > >
+> > > One thing that worries me though is, that it extends the sql language,
+> > > and there has been no discussion about the chosen syntax.
+> > >
+> > > Imho the standard embedded SQL syntax (prepare ...) could be a
+> > > starting point.
+> >
+> >  Yes, you are right... my PREPARE/EXECUTE is not too much ready to SQL92,
+> > I some old letter I speculate about "SAVE/EXECUTE PLAN" instead
+> > PREPARE/EXECUTE. But don't forget, it will *experimental* patch... we can
+> > change it in future ..etc.
+> >
+> >                                         Karel
+> 
+> [Sorry, I didn't look into your patch, yet.]
+
+ Please, read my old query cache and PREPARE/EXECUTE description...
+
+> What about parameters? Normally you can prepare a statement and execute it
+
+ We have in PG parameters, see SPI, but now it's used inside backend only
+and not exist statement that allows to use this feature in be<->fe.
+
+> using different parameters. AFAIK postgres' frontend-backend protocol is not
+> designed to take parameters for statements (e.g. like result presents
+> results). A very long road to go.
+> By the way, I'm somewhat interested in getting this feature in. Perhaps it
+> should be part of a protocol redesign (e.g. binary parameters/results).
+> Handling endianness is one aspect, floats are harder (but float->ascii->float
+> sometimes fails as well).
+
+        PREPARE  AS 
+                [ USING type, ... typeN ]
+                [ NOSHARE | SHARE | GLOBAL ]
+
+        EXECUTE 
+                [ INTO [ TEMPORARY | TEMP ] [ TABLE ] new_table ]
+                [ USING val, ... valN ]
+                       [ NOSHARE | SHARE | GLOBAL ]
+
+        DEALLOCATE PREPARE
+                [  [ NOSHARE | SHARE | GLOBAL ]]
+                [ ALL | ALL INTERNAL ]
+
+
+An example:
+
+
+PREPARE chris_query AS SELECT * FROM pg_class WHERE relname = $1 USING text;
+
+EXECUTE chris_query USING 'pg_shadow';
+
+
+   Or mean you something other?
+                   Karel
+
+
+
+
+
+
+From [email protected] Thu Nov  9 03:32:10 2000
+Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
+   by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id DAA09953
+   for ; Thu, 9 Nov 2000 03:32:09 -0500 (EST)
+Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
+   by mail.postgresql.org (8.11.1/8.11.1) with SMTP id eA98RSs11426;
+   Thu, 9 Nov 2000 03:27:28 -0500 (EST)
+   (envelope-from [email protected])
+Received: from ara.zf.jcu.cz (ara.zf.jcu.cz [160.217.161.4])
+   by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id eA98OPs11045;
+   Thu, 9 Nov 2000 03:24:25 -0500 (EST)
+   (envelope-from [email protected])
+Received: from localhost (zakkr@localhost)
+   by ara.zf.jcu.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id JAA08951;
+   Thu, 9 Nov 2000 09:23:41 +0100
+Date: Thu, 9 Nov 2000 09:23:41 +0100 (CET)
+From: Karel Zak 
+To: Christof Petig 
+cc: PostgreSQL Hackers ,
+        Michael Meskes ,
+        Zeugswetter Andreas SB ,
+        The Hermit Hacker 
+Subject: Re: AW: [HACKERS] Re: [GENERAL] Query caching
+In-Reply-To: <[email protected]>
+Message-ID: 
+MIME-Version: 1.0
+Content-Type: TEXT/PLAIN; charset=US-ASCII
+Precedence: bulk
+Sender: [email protected]
+Status: OR
+
+
+On Wed, 8 Nov 2000, Christof Petig wrote:
+
+> Karel Zak wrote:
+> 
+> > > What about parameters? Normally you can prepare a statement and execute it
+> >
+> >  We have in PG parameters, see SPI, but now it's used inside backend only
+> > and not exist statement that allows to use this feature in be<->fe.
+> 
+> Sad. Since ecpg would certainly benefit from this.
+> 
+> > > using different parameters. AFAIK postgres' frontend-backend protocol is not
+> > > designed to take parameters for statements (e.g. like result presents
+> > > results). A very long road to go.
+> > > By the way, I'm somewhat interested in getting this feature in. Perhaps it
+> > > should be part of a protocol redesign (e.g. binary parameters/results).
+> > > Handling endianness is one aspect, floats are harder (but float->ascii->float
+> > > sometimes fails as well).
+> >
+> >         PREPARE  AS 
+> >                 [ USING type, ... typeN ]
+> >                 [ NOSHARE | SHARE | GLOBAL ]
+> >
+> >         EXECUTE 
+> >                 [ INTO [ TEMPORARY | TEMP ] [ TABLE ] new_table ]
+> >                 [ USING val, ... valN ]
+> >                        [ NOSHARE | SHARE | GLOBAL ]
+> >
+> >         DEALLOCATE PREPARE
+> >                 [  [ NOSHARE | SHARE | GLOBAL ]]
+> >                 [ ALL | ALL INTERNAL ]
+> >
+> > An example:
+> >
+> > PREPARE chris_query AS SELECT * FROM pg_class WHERE relname = $1 USING text;
+> 
+> I would prefer '?' as a parameter name, since this is in the embedded sql standard
+> (do you have a copy of the 94 draft? I can mail mine to you?)
+
+ This not depend on query cache. The '$n' is PostgreSQL query parametr
+keyword and is defined in standard parser. The PREPARE statement not parsing
+query it's job for standard parser.
+
+> Also the standard says a whole lot about guessing the parameter's type.
+> 
+> Also I vote for  ?::type or type(?) or sql's cast(...) (don't know it's syntax)
+> instead of abusing the using keyword.
+
+The postgresql executor expect types of parametrs in separate input (array).
+I not sure how much expensive/executable is survey it from query.
+
+> > EXECUTE chris_query USING 'pg_shadow';
+> 
+> Great idea of yours to implement this! Since I was thinking about implementing a
+> more decent schema for ecpg but had no mind to touch the backend and be-fe
+> protocol (yet).
+> It would be desirable to do an 'execute immediate using', since using input
+> parameters would take a lot of code away from ecpg.
+
+By the way, PREPARE/EXECUTE is face only. More interesting in this period is
+query-cache-kernel. SQL92 is really a little unlike my PREPARE/EXECUTE.
+
+                       Karel
+
+

diff --git a/doc/src/FAQ/FAQ_MSWIN.html b/doc/src/FAQ/FAQ_MSWIN.html
new file mode 100644 (file)
index 0000000..4678625
--- /dev/null
+++ b/doc/src/FAQ/FAQ_MSWIN.html
@@ -0,0 +1,109 @@
+
+
+
+   
+  
+   
+  
+  Porting PostgreSQL to Windows 2000 procedures
+
+
+*  You can get the most recent version of this from
+http://people.freebsd.org/~kevlo/postgres/portNT.html.
+
+*  Problem reports can be sent to [email protected].
+
+
+Porting PostgreSQL to Windows 2000 installation procedures
+
+Thanks to Daniel Horak, 
+JasonTishler ,Joost Kraaijeveld
+and Pete Formanfor
+their helps.
+Without them, I cannot port Postgres to Windows 2000 successfully.
+
+
+  Install the lastest verion(1.1.5) of Cygwin
+
+            1.
+Click on the "Install Cygwin now" link on the 
+http://sources.redhat.com/cygwinwebpage.
+                
+This downloads setup.exe to your system.
+            2.
+Run setup and answer all of the questions. Please choose a mirror sitefor
+your download.
+
+  Install Charles Wilson's Cygwin32 IPC package
+
+            1.
+Download the precompiled binary 
+http://www.neuro.gatech.edu/users/cwilson/cygutils/V1.1/cygipc/cygipc-1.07-1.tar.gzin"/" directory.
+
+            2.
+tar zxvf cygipc-1.07-1.tar.gz
+
+  Install PostgreSQL 7.0.3
+
+            1.
+Download PostgreSQL 7.0.3 
+sourcecode in /usr/src.
+            2.
+tar zxvf postgresql-7.0.3.tar.gz
+            3.
+mkdir -p /usr/local/pgsql/{bin,include,lib,data}
+            4.
+cd /usr/src/postgresql-7.0.3/src/win32
+            5.
+cp endian.h /usr/include
+                
+cp tcp.h /usr/include/netinet
+              6. Apply 
+Jason Tishler's
+patches  in /usr/src/postgresql-7.0.3, then run 'patch -p1 <patch.diff'.
+
+                  Note that
+which causes patch    to reject all hunks.
+              7. cd /usr/src/postgresql-7.0.3/src,
+then run './configure'
+             8. make; make install
+             9. cp/usr/local/pgsql/lib/pq.dll
+/usr/local/pgsql/bin
+           10. Usingany editor to create .bashrc
+in / directory as belows:
+                 
+PATH=$PATH:/usr/local/pgsql/bin:/usr/local/bin
+                 
+PGDATA=/usr/local/pgsql/data
+                 
+PGLIB=/usr/local/pgsql/lib
+                 
+LD_LIBRARY_PATH=/usr/local/pgsql/lib:/usr/local/lib
+                 
+export LD_LIBRARY_PATH PATH PGDATA PGLIB
+           11. source/.bashrc, then run 'initdb'
+
+                
+Note that the owner of the DB system have to be different from root/administrator
+
+           12. Editthe file /usr/local/pgsql/data/pg_hba.conf,
+such as:
+                
+host        all    
+163.17.11.109   255.255.255.0   trust
+           13. ipc-daemon&
+           14. postmaster-i&
+           15. Run' psql -h host_name template1'.
+It's easy, huh :-)
+ 
+ 
+
+
+Last updated: 01/05/2001    Author:
+KevinLo
+
+
+