Re: [PATCHES] Implementing RESET CONNECTION ...
On Mon, 2005-01-03 at 20:27 -0500, Tom Lane wrote: > I'm inclined to think that we'd have to add a protocol message that > reports RESET CONNECTION to really answer objections of this type. > That seems to bring the thing into the category of "stuff that forces > a protocol version bump" :-( > > Perhaps RESET CONNECTION should be a protocol-level operation instead > of a SQL command? That would prevent user-level code from causing it > without the driver knowing. I still don't see a big difference between DEALLOCATE and RESET -- both can break the JDBC driver. I'm not sure if we need prevent bad usage of PG tools (JDBC in this case). The DEALLOCATE/RESET usage is under user's full control and everything can be described in docs. I think each PG command returns some status. For example in libpq it's possible check by PQcmdStatus(). I think JDBC can checks this status (by own PQcmdStatus() implementation) and if PG returns string "CONNECTION- RESETED" it can deallocate internal stuff. This solution doesn't require touch the protocol. Karel -- Karel Zak <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Another Plpgsql trigger example - summary table
Bruce Momjian wrote: Wow, yea, that is long. Not sure where that should go. hmmm, yep - I could shorten it by removing : - the COPY, ANALYZE (and maybe some of the INDEX) statements - the queries and EXPLAINS at the end However, this means that it is not clear what the point of the exercise is (or how to use the summary table at all for that matter). I guess the issue is that I am doing a mini introduction to data warehousing in the example, which makes it long (time passes while thinks about options): 1) Write a (slightly) less mini introduction into data warehousing as a section/chapter in its own right, and include the the summary table + trigger as an example therein. 2) Perhaps leave the trigger + plpgsql function as a plpgsql example, and refer to it in the (new) data warehouse section/chapter. Comments? (BTW, These both look like 8.1 doc changes) regards Mark ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] [HACKERS] Bgwriter behavior
On Mon, 2005-01-03 at 19:14 -0500, Bruce Momjian wrote: > Simon Riggs wrote: > > Here's my bgwriter instrumentation patch, which gives info that could > > allow the bgwriter settings to be tuned. > > Uh, what does this do exactly? Add additional logging output? > Produces output like this... DEBUG:ARC T1target= 45 B1len= 4954 T1len= 40 T2len= 4960 B2len= 46 DEBUG:ARC total = 98% B1hit= 0% T1hit= 0% T2hit= 98% B2hit= 0% DEBUG:ARC buffer dirty misses= 22% (wasted=0); cleaned= 4494 when you have debug_shared_buffers (= n) set and you have server messages DEBUG1 available. The last line of log output has been replaced by this version. -- Best Regards, Simon Riggs ---(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: [PATCHES] Implementing RESET CONNECTION ...
I completely agree with Karel. I think it is a bad idea to change the protocol for such a minor feature - i tend to call it overkill. I want to add one point to this discussion: There is not just JDBC - other connection pools or clients might want different behaviour (which can from my point of view only lead to a complete reset). If the JDBC driver prefers different behaviour (maybe for prepared statements) we should discuss further options for RESET. Now there is: RESET CONNECTION (cleaning entire connection), RESET ALL (cleaning GUCS only) and RESET some_guc. Maybe we want RESET LISTENER, RESET PREPARED, RESET CURSORS. Personally I think this is not a good idea. Regards, Hans Karel Zak wrote: On Mon, 2005-01-03 at 20:27 -0500, Tom Lane wrote: I'm inclined to think that we'd have to add a protocol message that reports RESET CONNECTION to really answer objections of this type. That seems to bring the thing into the category of "stuff that forces a protocol version bump" :-( Perhaps RESET CONNECTION should be a protocol-level operation instead of a SQL command? That would prevent user-level code from causing it without the driver knowing. I still don't see a big difference between DEALLOCATE and RESET -- both can break the JDBC driver. I'm not sure if we need prevent bad usage of PG tools (JDBC in this case). The DEALLOCATE/RESET usage is under user's full control and everything can be described in docs. I think each PG command returns some status. For example in libpq it's possible check by PQcmdStatus(). I think JDBC can checks this status (by own PQcmdStatus() implementation) and if PG returns string "CONNECTION- RESETED" it can deallocate internal stuff. This solution doesn't require touch the protocol. Karel -- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/660/816 40 77 www.cybertec.at, www.postgresql.at ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Implementing RESET CONNECTION ...
On Tue, 4 Jan 2005, [ISO-8859-1] Hans-Jürgen Schönig wrote: > I completely agree with Karel. I think it is a bad idea to change the > protocol for such a minor feature - i tend to call it overkill. I agree. I don't think it's imperative to prevent or detect this condition. The only real caller of this should be the driver itself. If the end user does call this and breaks things I wouldn't consider it our problem. Making this available at the protocol level only would certainly solve that, but it's not really compelling to make a protocol level jump. > I want to add one point to this discussion: There is not just JDBC - > other connection pools or clients might want different behaviour (which > can from my point of view only lead to a complete reset). Right, I am speaking from the JDBC driver perspective, but I think any higher level interface should desire to do statement pooling, which will have this problem. You have not stated what client interface you are targetting, but I believe anything written to a higher level than libpq will need to be aware of this. Perhaps -patches isn't the right place to solicit input for this. Kris Jurka ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] patch to add krb_server_hostname to postgresql.conf
> Todd Kover <[EMAIL PROTECTED]> writes: > > > The attached patch adds a directive to the config file, > > krb_server_hostname that allows the hostname that service tickets > > are obtained against to be different from the hostname of the db > > server. > > Why is this necessary? It's largely useful in combination with restricting the interfaces listened to via the listen_addresses directive in the config file. As the code works now you can only connect via kerberos with a service principal derived from the hostname of the box rather than any dns name associated with any of the box's interfaces. For example, if the server is named server0.example.com, but the db is bound to db.example.com via the listen_addresses directive, the pgsql server won't authenticate properly. Similarly, if server0.example.com is one interface and server1.example.com is another, and the hostname is server.example.com but doesn't correspond to any interfaces, connecting to neither will work. > If it is necessary, wouldn't something similar be needed at the > client end as well? No. The decision of which principal to obtain a service ticket for is based on what it connects to. In the first above example, if running: psql -h server0.example.com the client would obtain a service ticket for postgres/server0.example.com. If running: psql -h db.example.com it would obtain a service ticket for postgres/db.example.com, and without the directive I'm adding, it would fail to establish a connection because the server wouldn't be expecting that. Of course, adding the directive would make the first case fail and the second pass. This works fine for our environment since we're binding to db.example.com. (as an aside, it's actually a bit more complicated then this since the way the kerberos libraries are used, db.example.com is canonicalized, so if it were a CNAME for server0.example.com it would do the right thing, but we're using an A record). > I'd have thought that host information would be established by some > sort of system-wide configuration file, not by per-program options. Different applications can use different service principals. The use of the hostname in the principal name at all is an application-specific decision. The krb5 api encourages it to be a DNS hostname pretty strongly in the way it works, but it's not cast in stone. However, other kerberos clients will accept using any kerberos principal in the keytab but postgresql as shipped requires it to match the hostname. If you want that behavior instead, then change pg_krb5_server to NULL when calling krb5_recvauth in src/backend/libpq/auth.c and it won't require that the hostnames match. (but it's still necessary for something to match). The second patch (kovert-krb5-patch-newbehavior.txt) makes the default behavior to accept any principal in the keytab. This means that people using kerberos will continue to work, but they'll be slightly more broad in what they accept as a valid service principal (I suspect there's very few people in the world who care about this since it still needs to be something in the keytab). I left the implementation of krb_server_hostname so that someone can define this if they want. (and if they want to make it behave like versions of pgsql up until now, they'd need to set it to the hostname). The second patch's default case makes pgsql match the behavior of eklogind (kerberized rlogind that ships with MIT kerberos) and the gssapi/krb5-aware version of sshd and probably numerous other things. > Also, the available documentation says that PG_KRB_SRVNAM is a > service name, not a host name, so I feel like there's something wrong > with your description of what you're doing. indeed, there was something wrong with what I was doing. PG_KRB_SRVNAM defaults to 'postgres' rather than the hostname. This was fallout from when I was first developing the patch. The absence of the krb_server_hostname config flag should have left the default behavior in place, it wasn't. I just tested this patch against both cases on a dev box and it works as expected. both patches are against 8.0.0rc3. The first implements what I originally was doing without changing the default, the second changes the default to be more accepting and also implements the directive in case someone wants to go back to the old behavior. -Todd Index: doc/src/sgml/runtime.sgml === RCS file: postgresql-8.0.0rc3/doc/src/sgml/runtime.sgml,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- doc/src/sgml/runtime.sgml 26 Dec 2004 23:06:56 - 1.1.1.1 +++ doc/src/sgml/runtime.sgml 3 Jan 2005 23:18:44 - 1.2 @@ -952,6 +952,20 @@ + + krb_server_hostname (string) + + krb_server_hostname configuration parameter + + + +Sets the hostname that service tickets will be obtaine
Re: [PATCHES] Implementing RESET CONNECTION ...
Karel Zak wrote: I still don't see a big difference between DEALLOCATE and RESET -- both can break the JDBC driver. You have to go out of your way to break the driver via DEALLOCATE, explicitly finding a statement name that the driver is using. There's also a reasonably simple fix: make the protocol-level and PREPARE/DEALLOCATE namespaces separate. There's been some discussion about doing this in the past. In contrast RESET CONNECTION, by design, resets many things without needing to explicitly list them. The user could easily reset connection state that a driver is relying on without realizing it. I think each PG command returns some status. For example in libpq it's possible check by PQcmdStatus(). I think JDBC can checks this status (by own PQcmdStatus() implementation) and if PG returns string "CONNECTION- RESETED" it can deallocate internal stuff. This solution doesn't require touch the protocol. That could work. It's a bit ugly, though, as currently drivers don't need to parse command status strings (unless they want an insert OID) -O ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] Implementing RESET CONNECTION ...
Hans-Jürgen Schönig wrote: If the JDBC driver prefers different behaviour (maybe for prepared statements) we should discuss further options for RESET. Now there is: RESET CONNECTION (cleaning entire connection), RESET ALL (cleaning GUCS only) and RESET some_guc. Maybe we want RESET LISTENER, RESET PREPARED, RESET CURSORS. Personally I think this is not a good idea. It doesn't help, either, if user code can still issue RESET CONNECTION. (the scenario is user code, not the driver itself, originating the RESET..) -O ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] psql session log
Peter Eisentraut wrote: > [EMAIL PROTECTED] wrote: > > NOTE - the patch to the makefile is to keep it from constantly > > building psql.exe as the target "psql" all by itself is never created > > as the output executable on OS/2 and Windows is psql.exe. > > If this were a problem on Windows, we'd have more problems all over the > place, not only in psql's makefile. On Cygwin, I know there is no > problem, because of the peculiar way that the system calls map the file > names. Not sure what native Windows does. I tested this on MinGW and didn't have the rebuild problem either. gmake seems to know the .exe is implied. I wonder if this is an OS/2 gmake bug. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Final call for translation updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Tue, 4 Jan 2005, Peter Eisentraut wrote: With the 8.0 release around the corner, this is as good a time as ever to send in the last translation updates. If your files are not in CVS right now, I don't have them, so please send them again in this case. Turkish updates: http://postgresql.gunduz.org/translation/PostgreSQL-8.0/PgSQL-DilDosyalari/pg_ctl-tr.po http://postgresql.gunduz.org/translation/PostgreSQL-8.0/PgSQL-DilDosyalari/pg_resetxlog-tr.po http://postgresql.gunduz.org/translation/PostgreSQL-8.0/PgSQL-DilDosyalari/postgres-tr.po Regards, - -- Devrim GUNDUZ devrim~gunduz.orgdevrim.gunduz~linux.org.tr http://www.tdmsoft.com http://www.gunduz.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFB2vajtl86P3SPfQ4RAvToAKDW8Fpm8P+YIPM28oyWoD6byjF0ZQCfQjDw 3O8nLbcFkjPziO6GHwoJHqE= =aLNK -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Final call for translation updates
On Tue, 4 Jan 2005, Peter Eisentraut wrote: > With the 8.0 release around the corner, this is as good a time as ever > to send in the last translation updates. If your files are not in CVS > right now, I don't have them, so please send them again in this case. A batch of Russian translation updates is coming real soon now. I, with help from Oleg, am doing final polishing, spelling, and terminology fixes. I will send in the patches this Wed, Thu, maybe earlier. -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] patch to add krb_server_hostname to postgresql.conf
Todd Kover <[EMAIL PROTECTED]> writes: >> Why is this necessary? > It's largely useful in combination with restricting the interfaces > listened to via the listen_addresses directive in the config file. As > the code works now you can only connect via kerberos with a service > principal derived from the hostname of the box rather than any dns name > associated with any of the box's interfaces. Hmm. I guess I was confusing this with the --with-krb-srvnam configure directive, and expecting that it ought to convert that from a frozen-at-configure value into a run-time-configuration variable. What is the relationship of these two values, anyway? The documentation additions are pretty poor in both proposed patches; they do nothing to clear up any confusion. 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: [PATCHES] Implementing RESET CONNECTION ...
On Wed, 2005-01-05 at 01:33 +1300, Oliver Jowett wrote: > Karel Zak wrote: > > I think each PG command returns some status. For example in libpq it's > > possible check by PQcmdStatus(). I think JDBC can checks this status (by > > own PQcmdStatus() implementation) and if PG returns string "CONNECTION- > > RESETED" it can deallocate internal stuff. This solution doesn't require > > touch the protocol. > > That could work. It's a bit ugly, though, as currently drivers don't > need to parse command status strings (unless they want an insert OID) I think command status is common and nice feedback for client. I think it's more simple change something in JDBC than change protocol that is shared between more tools. We need some common way how detect on client what's happen on server -- a way that doesn't mean change protocol always when we add some feature/command to backend. The command status is possible use for this. Karel -- Karel Zak <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] pg_config MSVC makefile
Attached is a makefile I hacked up to build pg_config under MSVC - the
reason is that it's required (more or less) in order to build the latest
DBD::Pg code and I was testing that out under MSVC. Should be saved as
src/bin/pg_config/win32.mak if we're to be consistent. I haven't yet
done a patch to the upper level makefile to call it.
cheers
andrew
# Makefile for Microsoft Visual C++ 5.0 (or compat)
!IF "$(OS)" == "Windows_NT"
NULL=
!ELSE
NULL=nul
!ENDIF
CPP=cl.exe
!IFDEF DEBUG
OPT=/Od /Zi /MDd
LOPT=/DEBUG
DEBUGDEF=/D _DEBUG
OUTDIR=.\Debug
INTDIR=.\Debug
!ELSE
OPT=/O2 /MD
LOPT=
DEBUGDEF=/D NDEBUG
OUTDIR=.\Release
INTDIR=.\Release
!ENDIF
ALL : "..\..\port\pg_config_paths.h" "$(OUTDIR)\pg_config.exe"
CLEAN :
[EMAIL PROTECTED] "$(INTDIR)\pg_config.obj"
[EMAIL PROTECTED] "$(OUTDIR)\pg_config.exe"
[EMAIL PROTECTED] "$(INTDIR)\..\..\port\pg_config_paths.h"
"..\..\port\pg_config_paths.h": win32.mak
echo #define PGBINDIR "" >$@
echo #define PGSHAREDIR "" >>$@
echo #define SYSCONFDIR "" >>$@
echo #define INCLUDEDIR "" >>$@
echo #define PKGINCLUDEDIR "" >>$@
echo #define INCLUDEDIRSERVER "" >>$@
echo #define LIBDIR "" >>$@
echo #define PKGLIBDIR "" >>$@
echo #define LOCALEDIR "" >>$@
"$(OUTDIR)" :
if not exist "$(OUTDIR)/$(NULL)" mkdir "$(OUTDIR)"
CPP_PROJ=/nologo $(OPT) /W3 /GX /D "WIN32" $(DEBUGDEF) /D "_CONSOLE" /D\
"_MBCS" /Fp"$(INTDIR)\pg_config.pch" /YX /Fo"$(INTDIR)\\" /Fd"$(INTDIR)\\" /FD
/c \
/I ..\..\include /I ..\..\interfaces\libpq /I ..\..\include\port\win32 \
/D "HAVE_STRDUP" /D "FRONTEND" /D VAL_CONFIGURE="\"\""
CPP_OBJS=$(INTDIR)/
CPP_SBRS=.
LINK32=link.exe
LINK32_FLAGS=kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib\
advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib\
odbccp32.lib wsock32.lib /nologo /subsystem:console /incremental:no\
/pdb:"$(OUTDIR)\pg_config.pdb" /machine:I386 $(LOPT)
/out:"$(OUTDIR)\pg_config.exe"
LINK32_OBJS= \
"$(INTDIR)\pg_config.obj" \
"$(INTDIR)\pgstrcasecmp.obj" \
"$(OUTDIR)\path.obj" \
"$(INTDIR)\exec.obj" \
!IFDEF DEBUG
"..\..\interfaces\libpq\Debug\libpqddll.lib"
!ELSE
"..\..\interfaces\libpq\Release\libpqdll.lib"
!ENDIF
"$(OUTDIR)\pg_config.exe" : "$(OUTDIR)" $(DEF_FILE) $(LINK32_OBJS)
$(LINK32) @<<
$(LINK32_FLAGS) $(LINK32_OBJS)
<<
"$(OUTDIR)\path.obj" : "$(OUTDIR)" ..\..\port\path.c
$(CPP) @<<
$(CPP_PROJ) ..\..\port\path.c
<<
"$(INTDIR)\pgstrcasecmp.obj" : ..\..\port\pgstrcasecmp.c
$(CPP) @<<
$(CPP_PROJ) ..\..\port\pgstrcasecmp.c
<<
"$(INTDIR)\exec.obj" : ..\..\port\exec.c
$(CPP) @<<
$(CPP_PROJ) ..\..\port\exec.c
<<
.c{$(CPP_OBJS)}.obj::
$(CPP) @<<
$(CPP_PROJ) $<
<<
.cpp{$(CPP_OBJS)}.obj::
$(CPP) @<<
$(CPP_PROJ) $<
<<
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Implementing RESET CONNECTION ...
(cc'ing -hackers) Karel Zak wrote: I think command status is common and nice feedback for client. I think it's more simple change something in JDBC than change protocol that is shared between more tools. There is a bit of a queue of changes that would be nice to have but require a protocol version change. If we're going to change the protocol for any of those we might as well handle RESET CONNECTION cleanly too. We need some common way how detect on client what's happen on server -- a way that doesn't mean change protocol always when we add some feature/command to backend. The command status is possible use for this. Command status only works if commands are directly executed. If you can execute the command indirectly, e.g. via a PL, then you'll miss the notification. Making RESET a top-level-only command isn't unreasonable, but using command status won't work as a general approach for notifying clients. We have a mechanism for GUC changes that uses a separate message (ParameterStatus). Perhaps that should be generalized to report different sorts of connection-related changes. -O ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] psql session log
In <[EMAIL PROTECTED]>, on 01/04/05 at 09:49 AM, Bruce Momjian said: >Peter Eisentraut wrote: >> [EMAIL PROTECTED] wrote: >> > NOTE - the patch to the makefile is to keep it from constantly >> > building psql.exe as the target "psql" all by itself is never created >> > as the output executable on OS/2 and Windows is psql.exe. >> >> If this were a problem on Windows, we'd have more problems all over the >> place, not only in psql's makefile. On Cygwin, I know there is no >> problem, because of the peculiar way that the system calls map the file >> names. Not sure what native Windows does. >I tested this on MinGW and didn't have the rebuild problem either. gmake >seems to know the .exe is implied. I wonder if this is an OS/2 gmake >bug. Looks like it could be... I even added an explicit .SUFFIXES: .exe and it will still build the exe file when it is present from a make just done. what a PITA -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [pgsql-ru-general] [HACKERS] Final call for translation updates
On Tue, 4 Jan 2005, Serguei A. Mokhov wrote: On Tue, 4 Jan 2005, Peter Eisentraut wrote: With the 8.0 release around the corner, this is as good a time as ever to send in the last translation updates. If your files are not in CVS right now, I don't have them, so please send them again in this case. A batch of Russian translation updates is coming real soon now. I, with help from Oleg, am doing final polishing, spelling, and terminology fixes. I will send in the patches this Wed, Thu, maybe earlier. Serguei, I have translations (I didn't touch libpq, psql in work, other files seems complete) available from http://www.sai.msu.su/~megera/oddmuse/ Translation rules - http://www.sai.msu.su/~megera/oddmuse/index.cgi/Methodology Translation difficulties - http://www.sai.msu.su/~megera/oddmuse/index.cgi/Comments Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Session log for psql
There is a way do do it on OS/2 but it requires that you run psql.exe in a shell from the epm editor. That will allow you to feed input typed in the editor to stdin of psql and the editor will capture stdout and stderr from psql. Setting it up is convoluted at best... For people who want a simple session log I thought it would be easier to append -L mylog.log to the psql command line and it makes it easier to answer questions about someone's SQL adventures. Lorne In <[EMAIL PROTECTED]>, on 01/04/05 at 10:12 AM, Bruce Momjian said: >I thought we had a similar capability to log all psql output but I see we >do not. I just tried 'psql test | tee /tmp/log' and that didn't display >anything to my terminal so even on Unix it doesn't work. >I suppose on Unix people use 'script' but I don't imagine that exists on >Win32. >--- >[EMAIL PROTECTED] wrote: >> Here is a patch that allows psql to create a session log >> >> NOTE - the patch to the makefile is to keep it from constantly building >> psql.exe as the target "psql" all by itself is never created as the output >> executable on OS/2 and Windows is psql.exe. >> >> The patch provides for a new command line argument -L logfile-name that is >> used to turn on session logging with output to the specified file name. >> The output from the logging is always appended to an existing file. >> >> The session log records both the query text and the results from the >> queries. >> >> Lorne Sunley >> >> -- >> --- >> [EMAIL PROTECTED] >> --- >[ Type application/octet-stream treated as attachment, skipping... ] >> >> ---(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 -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
