Re: [HACKERS] Lisp as a procedural language?
On Oct 20, 2008, at 3:00 PM, Joshua Tolley wrote: One of the Java-as-a-procedural-language options uses RMI to get the server talking to a separate JVM, where the actual function processing gets done. Could a PL/Lisp work similarly (and would it be anything approaching a good idea...)? I think it could work, but it is hard to say how good an idea it would be without being more familiar with the implementation details on what it takes to create a complete procedural language. There might be some useful ideas from SLIME (http://common-lisp.net/project/slime/ ) which connects to many different Lisp implementations to provide a Lisp IDE in Emacs. BTW, this is Lisp's 50th birthday being celebrated today at OOPSLA. http://www.lisp50.org/ John DeSoi, Ph.D. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lisp as a procedural language?
On Oct 19, 2008, at 1:27 PM, Douglas McNaught wrote: SBCL is a big and very sophisticated program. It's designed to be a self-contained Lisp system and has (AFAIK) no concessions to "embeddability". It uses threads internally, and plays games with the memory map to make GC more efficient. Only a small part of it is written in C, and the rest is Lisp compiled directly to binary. It would almost certainly be a heroic project to make it coexist with a PostgreSQL backend process--like Java, but much worse. It's not likely that any of the "serious" Common Lisp systems would be easily embedded in Postgres. Probably the ideal implementation would be ECL: http://ecls.sourceforge.net/ It is designed to be a full Common Lisp implementation that can be easily embedded in other environments. It generates C source code so you could have the option of developing with Lisp and then generating C language functions for additional speed or source code security. Not open source, but I've played around a bit with integrating LispWorks to get Lisp a procedural language. I'd like to see Lisp as a procedural language, but I'm not very proficient with C. If anyone is interested in leading the way, I would be happy to help. John DeSoi, Ph.D. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plpgsql keywords are hidden reserved words
On Nov 5, 2007, at 10:20 AM, Tom Lane wrote: I don't see any fix for this that's reasonable to try to shoehorn into 8.3, but I think we really need to revisit the whole area of plpgsql variable substitution during 8.4. We could make this problem go away if variable substitution happened through a parser callback instead of before parsing. Is there any feasibility to the idea of allowing pl/pgsql variables and parameters to be prefixed with a special character like '$'? I'm constantly adding prefixes like 'v_' because of conflicts with table or column names. It would be nice to have something like "declare $myvar integer;" so it would be very easy to distinguish variable and parameter names from structure names or reserved words. John DeSoi, Ph.D. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Has anyone tried out the PL/pgSQL debugger?
Hi Korry, On Sep 6, 2007, at 10:23 AM, korry.douglas wrote: John, I started writing up the API documentation and then noticed that most of what I intended to write is already described in the pldbgapi.c module. Take a look at that module and let me know if you have any questions (you can e-mail me off-list if you like). I'll update the documentation in pldbgapi.c as needed. I just noticed that when digging around last night. It helped a lot with my understanding of how things work. I think that needs to go in the readme file or at least reference it from the readme file. I would still like to see a simple example using psql. I know you would not really use psql for this, but I think it would help a lot with getting started for folks that want to use the debugger. I did not spend lots of time on it, but even after reading pldbgapi.c I was not able to get simple session going (e.g. how to start a session and request the source for a procedure). Thanks, John John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Has anyone tried out the PL/pgSQL debugger?
Hi Dave, On Sep 5, 2007, at 3:54 AM, Dave Page wrote: That's odd - I cannot reproduce that on OS X using beta 4 (which has no important changes in the debugger over beta 3). Can you provide a simple test case? I get the same error with this: create or replace function debug_test(out t text, out i integer) returns record as $$ begin t := 'test 1'; i := 10; return; end; $$ language plpgsql; I did the following: 1. Right click the function and chose "Debug" from the "Debugging" submenu. 2. Clicked the OK button on the dialog. Best, John John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Has anyone tried out the PL/pgSQL debugger?
Hi Dave, On Sep 5, 2007, at 3:54 AM, Dave Page wrote: That's odd - I cannot reproduce that on OS X using beta 4 (which has no important changes in the debugger over beta 3). Can you provide a simple test case? I'll try to come up with a simple test case and send it sometime this evening. Possible hint: the function had no IN parameters, but many OUT parameters. John John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Has anyone tried out the PL/pgSQL debugger?
On Sep 4, 2007, at 8:55 PM, korry.douglas wrote: Sorry about that John, there's a fix for this problem (it's an 8.2 versus 8.3 issue) in the CVS repository. I thought I had rolled a new tarball after committing the fix but I guess not. You can pull the latest plugin_profiler.c from: Thanks Korry, that fixed it. Is there any documentation that describes how to use the SQL functions? Some are obvious enough, but a simple example showing a debugging session would be helpful. In some simple tests it seems to work OK with pgAdmin (1.8b3) on OS X. There appears to be a pgAdmin bug when you start a debug session on a function that has no parameters: ERROR: syntax error at or near ")" LINE 1: SELECT * FROM myschema.myfunction) ^ Thanks for doing this project -- looks great. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 1: 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] Has anyone tried out the PL/pgSQL debugger?
On Sep 4, 2007, at 1:01 PM, korry.douglas wrote: The core of the debugger has been in use for quite some time, but I had to strip out a lot of EDB-specific code and I'd like to see that the result (the open-source version at pgFoundry) holds up well on other platforms. Josh, any chance you could try it out on Solaris? I copied the latest from pgFoundry to my contrib folder (pg 8.2.1) and executed 'make; make install'. I get the following errors on OS X 10.4.10: plugin_profiler.c: In function 'tableExists': plugin_profiler.c:698: error: too few arguments to function 'stringToQualifiedNameList' plugin_profiler.c: In function 'dumpStatsXML': plugin_profiler.c:847: warning: format '%07ld' expects type 'long int', but argument 4 has type 'suseconds_t' plugin_profiler.c:850: warning: format '%07ld' expects type 'long int', but argument 4 has type 'suseconds_t' make: *** [plugin_profiler.o] Error 1 rm plugin_debugger.o targetinfo.o pldbgapi.o Makefile:63: warning: overriding commands for target `install' ../../src/makefiles/pgxs.mk:104: warning: ignoring old commands for target `install' Makefile:77: warning: overriding commands for target `installdirs' ../../src/makefiles/pgxs.mk:139: warning: ignoring old commands for target `installdirs' gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith - Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict- aliasing -DINCLUDE_PACKAGE_SUPPORT=0 -I../../src/pl/plpgsql/src -I. -I../../src/include -c -o plugin_profiler.o plugin_profiler.c plugin_profiler.c: In function 'tableExists': plugin_profiler.c:698: error: too few arguments to function 'stringToQualifiedNameList' plugin_profiler.c: In function 'dumpStatsXML': plugin_profiler.c:847: warning: format '%07ld' expects type 'long int', but argument 4 has type 'suseconds_t' plugin_profiler.c:850: warning: format '%07ld' expects type 'long int', but argument 4 has type 'suseconds_t' make: *** [plugin_profiler.o] Error 1 John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Per-function search_path => per-function GUC settings
On Sep 1, 2007, at 1:36 PM, Brendan Jurd wrote: So if we integrated the GUC settings into CREATE FUNCTION, we'd end up writing something like CREATE FUNCTION foo(int) RETURNS int AS $$ ... $$ LANGUAGE plpgsql STABLE STRICT SECURITY DEFINER RESET search_path SET regex_flavor = 'cinnamon'; That doesn't seem especially horrible. In what way do you feel it is inconsistent with existing syntax? I like this and would really like to see way to set everything using CREATE FUNCTION. Using ALTER only requires maintaining a separate copy of of function arguments which can be a hassle for large argument lists. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_get_tabledef
Hi Usama, On May 21, 2007, at 9:20 AM, Usama Munir wrote: i wanted to submit a patch for this, IFF the community wants this function. The rationale is obviously to help Application developers writing applications like pgAdmin. Currently this part of SQL needs to be constructed manually for postgres by the tools. I would like to have this functionality (yesterday :) -- I'm currently working on this for pgEdit. Let me know if you need help with review or testing. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 1: 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] Loading the PL/pgSQL debugger (and other plugins)
Hi Korry, On Jul 21, 2006, at 12:51 PM, korry wrote: Sorry to poke - but I'd like to get a patch submitted next week. Any more comments? Thanks. I'm unqualified to comment on the server side design, but I was wondering if there was consensus on how the client interface to the debugger would work. From previous threads I saw DBGP mentioned (http://xdebug.org/docs-dbgp.php), but I don't recall seeing any final commitment to it. Thanks, John John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] contrib promotion?
On Jul 14, 2006, at 12:32 PM, Joshua D. Drake wrote: Doesn't our inclusion of md5() pretty much blow that argument away? (Just asking). I don't think so because md5 is just a one way hash function. There is no method to decrypt anything :). John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [CORE] GPL Source and Copyright Questions
On Jun 23, 2006, at 3:10 AM, Dave Page wrote: Is there any real reason to continue to support Cygwin? We've always said it's not a first class port, and now we have the native port which is it seems somewhat pointless expending further effort on it. Are all the tools needed to compile from source on Win32 freely available? John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On May 18, 2006, at 12:24 PM, Jim C. Nasby wrote: Even better would be coming up with a compatability mode, a la what EnterpriseDB has done for Oracle. Right, you'll definitely need to hack the C source code to force PostgreSQL to accept invalid dates ;) http://sql-info.de/mysql/gotchas.html#1_14 John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On May 17, 2006, at 8:08 PM, Mark Woodward wrote: What is the best way to go about creating a "plug and play," PostgreSQL replacement for MySQL? I think the biggest problem getting PostgreSQL accepted is that so much code is available for MySQL. http://pgfoundry.org/projects/mysqlcompat/ John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Google SoC--Idea Request
Proposed item: Improve PL/PHP support, especially installation on non- Linux platforms. PL/PHP does not currently work on OS X (not sure about Windows, but I doubt it). Alvaro indicated he would be willing to provide direction on this with testing support from me. He also said there are several other possible PL/PHP issues that would warrant a SoC project. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Summer of Code Preparation
On Apr 5, 2006, at 5:04 PM, Marc G. Fournier wrote: Sure, although the important part is to find students. I'm not sure how we do that. Do we have any professors online? I'm not one, but I know some. If there is a link with details and perhaps a list of possible projects, I'll be happy to spread the word. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pgNixInstaller: Making PostgreSQL relocatable
On Mar 24, 2006, at 7:25 AM, Martijn van Oosterhout wrote: Anyway, looking at the manpage of otool it doesn't say that it just prints the raw name, so perhaps it's doing the same as ldd. To be sure you'd need to strings the binary to see what it says. Yes, strings shows the full path of prefix provided to configure. And I can tell you from experience it is not relocatable :). Here is a bug I recently filed for pgAdmin which discusses the use of install_name_tool to make the reference relative. Certainly it would be better if they could be compiled with relative references, but at least I found a solution without having to understand gcc. http://www.pgadmin.org/archives/pgadmin-support/2006-03/msg00053.php John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 1: 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] pgNixInstaller: Making PostgreSQL relocatable
On Mar 23, 2006, at 12:15 AM, Tom Lane wrote: OK ... it's supposed to work to shift the whole installation tree to a new root, ie, paths to places like the /share and /lib directories are determined relative to where the backend executable actually is. If this is not working on Solaris then for sure we want to know ... It is not relocatable on OS X. The full prefix path seems to be used instead. For example: [M:bin/postgresql/bin] % otool -L pg_ctl pg_ctl: /sw/bin/postgresql-8.1.2/lib/libpq.4.dylib (compatibility version 4.0.0, current version 4.1.0) /usr/lib/libssl.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7) /usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 369.1.5) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.2) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 92.0.0) It would be really nice to have relative references. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] character encoding in StartupMessage
On Feb 28, 2006, at 11:19 AM, Tom Lane wrote: In any case I don't think there's a huge problem if we say that database and user names had better be chosen from the round-trip-safe subset. What about the pg_hba.conf file? Is there a provision to specify the encoding or some other way to deal with non-ascii characters? Thanks, John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] character encoding in StartupMessage
On Feb 28, 2006, at 1:38 AM, Tom Lane wrote: I could not find anything in the Frontend/Backend protocol docs about character encoding in the StartupMessage. Assuming it is legal for a database or user name to have unicode characters, how is this handled when nothing yet has been said about the client encoding? A similar badness is that if you issue CREATE DATABASE from a UTF8 database, the dbname will be stored as UTF8. Then, if you go to a LATIN1 database and create another it will be stored as LATIN1. Yeah, this has been discussed before. Database and user names both have this affliction. So are the database/user names in the startup message compared using the default encoding of the cluster or is just a straight byte comparison with no consideration of the encoding? Thanks, John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] character encoding in StartupMessage
I could not find anything in the Frontend/Backend protocol docs about character encoding in the StartupMessage. Assuming it is legal for a database or user name to have unicode characters, how is this handled when nothing yet has been said about the client encoding? Thanks, John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Contrib Schemas
Hi Josh, On Jan 13, 2006, at 2:34 PM, Josh Berkus wrote: I can't see a way to do this except individually, in which case the superuser might as well load the functions. We *have* to be restrictive about this because a C function can do anything, including overwriting whatever parts of the filesystem "postgres" has access to. Look over our patch releases for the last 2 years and you'll see a host of patches designed specifically to prevent regular users from gaining access to superuser priveleges. What you want isn't impossible, but it would be a lot of work and testing to engineer such a mechanism and keep PostgreSQL's "most secure" status. So far, everyone has found it easier to work around the issue, especially since for most sites backup/restore is done by the superuser anyway. I suspected it was out of the question for security reasons, but I wanted to bring it up to make sure I was not missing some alternative solution. I backup and restore all the time for hosted web sites running with PostgreSQL as a content management system. This is critical for doing site upgrades and you certainly can't depend on the super user in a hosted environment. Maybe the best solution here would be some web interface setup by the hoster to perform specific approved tasks like tsearch install. This is already the mechanism used to allow users to create their own databases. Thanks for taking the time to respond. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Contrib Schemas
On Jan 12, 2006, at 9:03 PM, Christopher Kings-Lynne wrote: Default schema really has to be public to help the newbies out there. All contribs should come with some sort of standard uninstall.sql script though. Speaking of contrib newbies and install/uninstall, I recently had the need to install tsearch2 in a shared hosting environment (where, of course, I don't have superuser access). Since there are C language functions, I could not install it. The hoster's solution was to install it in template1 which seems bad because (1) now everyone gets it whether they want it or not, (2) restoring the database is going to have permission problems. Would it be reasonable for there to be a way for the super user to grant access to load "approved" modules and/or C language functions? John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql & readline & win32
On Jan 2, 2006, at 4:00 AM, Magnus Hagander wrote: Me, I'm not fully happy with psql on win32. I want my tab completion! (which the gui tools don't do either, from what I can tell. At least pgadmin doesn't. Yet.) Mine has tab completion adapted from psql :). There are also commands for specific completion types, e.g. complete table, complete function, etc. I hope to have a beta out soon with 8.1 psql and updated tab completion for the new commands (roles, etc). John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Why don't we allow DNS names in pg_hba.conf?
On Jan 1, 2006, at 2:02 PM, Martijn van Oosterhout wrote: For the user in referred to thread: SSH tunnelling. I wonder if there's a way we can make that easier to setup... Making this easier and transparent would be nice, but I would still vote to allow DNS names in pg_hba.conf. SSH tunneling implies another level of software, user accounts, and permissions. It would be nice to handle the entire sphere of users and permissions from within PostgreSQL. For database access requirements, I would much rather allow DNS names in pg_hba.conf than provide SSH access. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 1: 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] Request for a "force interactive mode" flag (-I) for psql
On Oct 13, 2005, at 4:42 PM, Bruce Momjian wrote: I haven't seen any replies to this, so I guess you are left with either hacking psql yourself or getting Cygwin folks to fix it. Sorry. I have asked for this also. It would make it much easier to control psql from other applications. http://archives.postgresql.org/pgsql-hackers/2005-04/threads.php It seems pretty simple and non-invasive. I don't recall seeing the reasons against doing it. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] PostgreSQL from source using MinGW
On Sep 7, 2005, at 2:31 PM, Lee, Patricia S. wrote: However, I cannot get the make to work. Do I still need to install the GNU Make utility? Any suggestions? LEEP ~/sources/PostgreSQL/postgresql-8.0.3 $ configure --prefix=/c/PostgreSQL/8.0.3 Try adding --without-zlib to your configure. Sorry I don't recall what, if any, limitations that involves. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Sleep functions
On Aug 22, 2005, at 12:40 AM, Michael Fuhr wrote: To others who've written their own sleep() function: what are you using it for? I need it for API and user interface testing. I want to be sure things behave correctly when a long running query is interrupted. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] Continue transactions after errors in psql
On Apr 26, 2005, at 10:35 AM, Tom Lane wrote: Once you've got such an infrastructure, it makes sense to allow an interactive mode that automatically puts such things around each statement. But I can't really see the argument for using such a behavior in a script. Scripts are too stupid. Would it be possible to have a command line switch and/or a psql variable to control "interactive"? If I recall correctly, the setting depends on tty and there are possible interactive uses of psql outside of a terminal session. With so many things depending on this, it would be nice to be able to override the default. Thanks, John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Some download statistics
Hi Magnus, On Feb 24, 2005, at 11:35 AM, Magnus Hagander wrote: I did some simple pivoting in Excel and split it into categories win32, source, sig (MD5 or PGP signatures), RPMs, split (the split tarballs), pgadmin and ODBC. Other stuff was so little that I cut it. Assuming this is from a HTTP log, I'm just curious if you took into account that many Windows users have "download managers" that make repeated requests to get a single file. You see this in the log with a 206 (partial content) HTTP response code. So you might have anywhere from 10 to 20 hits in the log to download a single file. This makes it a pain to get accurate download statistics. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] sigint psql
Hi Magnus, On Feb 21, 2005, at 3:00 PM, Magnus Hagander wrote: There is no way so signal *psql*, as in the client side process. The signal emulation only runs in the server. But is there some equivalent of pressing ctrl-C to make psql stop what it is doing? For example, through the pipe stream I may execute a \i command and the user wants to stop before the file is processed. What mechanism is used to do this on win32? I thought it could be accomplished on Unix with kill -2, hence my original question. But maybe I'm looking in the wrong place. Thanks, John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] sigint psql
On Feb 21, 2005, at 3:00 PM, Magnus Hagander wrote: There is no way so signal *psql*, as in the client side process. The signal emulation only runs in the server. You can do the same thing in the server using pg_ctl kill, but that won't work on client processes. Thanks to everyone for the feedback and suggestions. Since I need this to work on win32, I guess I'll just abort the stream and reconnect. The main issue with this is trying to restore any state associated with the connection (e.g. search_path). John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] sigint psql
I'm communicating with psql via a pipe stream. This works pretty well, but one problem I have is trying to cancel an operation. If I send a sigint, psql dies. In looking at the source I gather this is because it assumes I'm in non-interactive mode (pset.notty is true). I was wondering if there was some way to work around this short of recompiling the source. I need to do the same thing on Windows. Thanks for any suggestions, John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] postgresql documentation for developers
On Feb 3, 2005, at 2:39 PM, Pavan Kumar Chowdary P wrote: I am pavan working in database systems lab in Indian Institute of science. As my M.E project I am trying to add new join type to postgresql. I am searching on net for documentation for developers which will describe the software architecture of postgres and tell what each structure of postgres contains and what info the functions expect as input etc.. which will be useful in hacking the postgresql code. Is there any documentation of above type available? If so please give the details. Try starting here: http://developer.postgresql.org and http://developer.postgresql.org/readtext.php?src/FAQ/ FAQ_DEV.html+Developers-FAQ John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] psql 8.0 final not working on NT 4.0sp6
Hi Magnus, On Jan 18, 2005, at 1:34 PM, Magnus Hagander wrote: 1) Declare NT4 without IE4 unsupported. This is by far the easiest :P What we'd do later is add a check to the MSI installer to inform the user about this. Seems a bit gross to say that NT4 is supported, but only if you happen to have a really old version of IE (or you happened to install it and choose the right option somewhere along your way to a later IE version). If I read the MS page correctly, having IE 4 installed does not guarantee things will work. You must have chosen the option to install Windows Desktop Update. I would not be surprised if I did this -- I hate the Windows explorer interfaces that tries to make everything look like a web page :). 2) Revert to the pre-8.0 behaviour with the files. This is IMHO a very bad idea, because that was not well-behaved on *current* Windows platforms. Is it not possible to add a version check and just use the old method with Windows NT? What is this function call used to get other than the user's home directory? 3) Change to using SHGetFolderPath() linked from shfolder.dll (note that this function exists in two different dlls. We'd need the one in shfolder.dll to have any effect). And then point people who don't have shfolder.dll to the Microsoft download site for this file (it's redistributable, but only in an unmodified self-extracting file, so we can't easily embed it in the installer. can be done, but not as easy as one would like). It will be required on most systems running 95, 98 and NT4 (without it we'll be broken on 95 and 98, which work today). The file is included on current windows versions by default. This is probably the nicest idea, but I'm not sure how much work we want to throw into the NT4 support. Considering MS has stopped supporting it even to their pay-through-the-nose-for-support customers by now. (and we *do* work on NT4 as long as the user has installed IE4) I certainly understand not wanting to spend a bunch of time on NT support. But everything seemed fine through 8.0.0-rc1, so I would hate to see it go away over this one issue. I did not realize that 95/98 worked at all. I don't think anyone really wants to setup a server on 95, 98, or even NT4, but it would be really nice if psql would work. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(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] psql 8.0 final not working on NT 4.0sp6
Hi Magnus, On Jan 18, 2005, at 10:50 AM, Magnus Hagander wrote: I'm running 'psql.exe -- version' and I'm getting this dialog: psql.exe - Entry Point Not Found: The procedure entry point SHGetSpecialFolderPathA could not be located in the dynamic link library SHELL32.DLL. Do you have the IE4 Desktop Update installed? I think so. System Properties for my computer shows NT 4.00.1381 IE 5 5.50.4308.2900 If this is not what you are asking, let me know where to look. I'm also curious as to why the version of psql I compile is about 7K bytes smaller than what the installer gives me. SSL suport possibly? Use pg_config from the installer to find the exact commandline used for that. If that's not it, then different version of mingw gcc probably. That's it -- thanks. If I'm posting to the wrong list for this, please let me know. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] psql 8.0 final not working on NT 4.0sp6
On Jan 18, 2005, at 11:05 AM, Magnus Hagander wrote: Hmm. That would seem to have it. Can you check the version on your SHELL32.DLL? The MSDN docs for the version in question (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ shellc c/platform/shell/reference/functions/shgetspecialfolderpath.asp) claims it needs either Win2k or The IE 4.0 Desktop Update. Which resolves to shell32.dll version 4.71 or later. WINNT\System32\Shell32.dll is version 4.00, so that appears to be the problem. According to this: http://support.microsoft.com/kb/q165695/ Windows Desktop update was included with IE 4, but not with IE 5 or later. Further, if you want to install Windows Desktop Update you have to first remove IE 5 or later. And finally it says that Windows Desktop Update can only be installed using the IE 4 setup, but this is no longer available from Microsoft. What a mess. hackers-win32 is prboably slightly more on-topic OK, will do for next time. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] psql 8.0 final not working on NT 4.0sp6
I'm running 'psql.exe -- version' and I'm getting this dialog: psql.exe - Entry Point Not Found: The procedure entry point SHGetSpecialFolderPathA could not be located in the dynamic link library SHELL32.DLL. I got this for both the version I compiled and psql from the pgInstaller (both operations done on Windows XP). I suppose that the compiler and/or installer could be doing something different for Windows NT? The last version I tested on NT 4 was 8.0.0rc-1 which works OK. I'm also curious as to why the version of psql I compile is about 7K bytes smaller than what the installer gives me. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(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] pgEdit public beta for Macintosh and Windows
The first public beta for pgEdit is now available (see product description below). If you would like to participate in the beta program, evaluate the software and send some feedback to me (e.g. criticism, bug reports, feature requests). The first responders will receive a 30 day trial registration key to remove demonstration mode restrictions. A limited number of registration keys will be distributed, so respond soon if you would like to receive a registration key. If you don't respond right away, quality feedback is another way to get a registration key :). Thanks for your help! John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL = pgEdit is a high performance SQL editor and development environment designed specifically for PostgreSQL relational databases. pgEdit features include: * SQL Syntax coloring specifically designed for PostgreSQL PostgreSQL represents function bodies as single quoted strings which most editors render with a single color. pgEdit promotes better usability and correctness by using SQL syntax coloring within the body of function strings. Keyword coloring is based directly on the source code of PostgreSQL. * SQL source code execution without saving the file or switching applications pgEdit can execute the SQL source code for (1) the entire buffer, (2) the highlighted region, (3) the current SQL containing the cursor, or (4) the current SQL line to the end of the file buffer. * Direct integration with psql, the PostgreSQL interactive terminal In addition to SQL, almost all psql commands are supported. This provides a powerful facility for examining, designing, and managing databases. * Extensive and customizable editing facilities pgEdit is a full featured text editor with hundreds of commands available. A friendly interface is included to provide online documentation and customize the key bindings for any command. Menu shortcuts can also be customized. pgEdit supports traditional Macintosh and Windows editing features, as well as Emacs-style key bindings. * Integrated documentation Help in pgEdit is provided with context sensitive links to the online documentation displayed in your preferred web browser. The PostgreSQL documentation is also included with direct links to important sections provided in the pgEditHelp menu. The documentation for the SQL command nearest to the cursor can be retrieved by pressing a user configurable key sequence. * Cross platform and easy to install pgEdit is a native application for both Macintosh and Windows. It does not use Java or require installation of external libraries. You have the option of using the version of psql included with pgEdit or a different version installed anywhere on your hard drive. ---(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] looking for pgEdit beta testers
Hi, I'm working on a new product for PostgreSQL (description below) and I'm looking for 5 to 10 Mac users who might be interested in beta testing. The first release will be for Mac OS X 10.2 or later. A Windows version will follow, most likely in November. Drop me an email if you can spare a little time to take a look and provide some feedback. Thanks! John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL = pgEdit is a high performance SQL editor and development environment designed specifically for PostgreSQL relational databases. It supports Emacs style editing with Macintosh and Windows compatibility modes. SQL scripts can be executed directly from the editor without saving. pgEdit features include: * SQL Syntax coloring specifically designed for PostgreSQL PostgreSQL represents function bodies as single quoted strings which most editors render with a single color. pgEdit promotes better usability and correctness by using SQL syntax coloring within the body of function strings. Keyword coloring is based directly on the source code of PostgreSQL. * SQL source code execution without saving the file or switching applications pgEdit can execute the SQL source code for (1) the entire buffer, (2) the highlighted region, (3) the current SQL containing the cursor, or (4) the current SQL line to the end of the file buffer. * Direct integration with psql, the PostgreSQL interactive terminal In addition to SQL, almost all psql commands are supported. This provides a powerful facility for examining, designing, and managing databases. * Extensive and customizable editing facilities pgEdit is based on a Emacs-like text editor with hundreds of commands available. A friendly interface is included to provide online documentation and customize the key bindings for any command. Familiarity with Emacs is not required; pgEdit provides the option emulate traditional Macintosh and Windows editing styles. * Integrated documentation Help in pgEdit is provided with context sensitive links to the online documentation displayed in your preferred web browser. The PostgreSQL documentation is also included with direct links to important sections provided in the pgEditHelp menu. The documentation for the SQL command nearest to the cursor can be retrieved by pressing a user configurable key sequence. * Cross platform and easy to install pgEdit is a native application for both Macintosh and Windows. It does not use Java or require installation of external libraries. You have the option of using the version of psql included with pgEdit or a different version installed anywhere on your hard drive. ---(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] row description for domain in 7.4
On Friday, June 27, 2003, at 02:00 AM, Tom Lane wrote: We've only had domains for one release cycle, so it seems to me that there's not a lot of track record to justify a "this is how we've always done it" position for domain-related behaviors. Especially when the odds seem good that few people are really using domains. I was not aware it was such a new feature. So you are right, it probably won't have much impact. Is there any way to use the CREATE TYPE feature without having to write C functions? (I'm assuming here the row description would have to be the OID of the created type.) What I want to do is store text but know that the column is a specific text format so that it can be parsed properly by the front end. Thanks, John DeSoi, Ph.D. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] row description for domain in 7.4
On Thursday, June 26, 2003, at 11:22 PM, Tom Lane wrote: By my count you're in the minority --- there was no one lobbying for reporting domain OIDs in the previous threads, and at least two people strongly in favor of not doing so. While I don't have a strong opinion about it myself, I don't have the interest to make the behavior configurable, unless you can get some more votes for your position. If I understand the change correctly, won't this break existing clients that use the previous behavior (even if they don't use the 3.0 protocol)? Since few people are using 7.4, I don't expect I'll get any more votes unless things start breaking down the road (when it will be too late to change anything). No hard feelings about it, but I'm really surprised existing behavior will be broken when the technical reasons for changing it were so weak. Did I mis-analyze the situation in the previous email? Is it not just one query to the database to get the base type compared to a lot more effort to get the domain? Thanks, John DeSoi, Ph.D. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] row description for domain in 7.4
Tom, Thanks for helping me find the previous discussion. 2) Better support for domains. Currently the jdbc driver is broken with regards to domains (although no one has reported this yet). The driver will treat a datatype that is a domain as an unknown/unsupported datatype. It would be great if the T response included the 'base' datatype for a domain attribute so that the driver would know what parsing routines to call to convert to/from the text representation the backend expects. To me this seems completely wrong. The whole point of getting the domain is so that I can know how I should parse the result coming from the server. If I use a text domain, I can't distinguish the domain column from any other text column and perform some other kind of processing on the data. If it remains as is, then the front end has to look up every column on every request to see if that column corresponds to some domain. It could possibly be cached to some degree, but it seems like dropping/adding columns could result in the same a table oid, column number pair having the same base type but a different domain. As implemented previously, the front end only has to make one request, one time, to determine the base type of the domain OID. - base type OID instead of user type OID. Might break some clients dealing with special types. ODBC users won't notice. - a postgresql.conf option to tell the backend to use base type OID or user type OID. Would catch most cases. - a connection specific setting to tell the backend to use base type OID or user type OID. For concurrent ODBC and weird clients use. - base type additionally in the RowDescription message. Obviously, this would break the 7.3 protocol. My vote would be to restore the previous behavior and add connection-specific setting for clients that need it. I don't think a postgresql.conf option (alone) is viable because users might want to use different kinds of front ends for the same server. Best, John DeSoi, Ph.D. ---(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] row description for domain in 7.4
On Wednesday, June 25, 2003, at 10:42 PM, Tom Lane wrote: No, 7.4 intentional change. If you want to argue that this was a bad idea, it's not too late ... but see the archived discussions about it. Hi Tom, Can you give me a pointer on where to find the archived discussions? I have tried all the reasonable keywords I can think of in the archive search, but I can't seem to find anything. Thanks, John DeSoi, Ph.D. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] row description for domain in 7.4
I created a domain with text as the data_type. When I get the row description message from the backend for a column using this domain, the type OID provided is for text (25) rather than the OID of the domain I created. I could have sworn I tested this in 7.3.x and the OID was for my domain. 7.4 bug or something I need to work out on my own? Thanks, John DeSoi, Ph.D. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] 3.0 fe/be protocol bug?
On Wednesday, May 28, 2003, at 07:56 PM, Tom Lane wrote: 44 0013 0002 0005 3137303632 D mesg len 2col col1 len5 oid 17602 len col2 here? Looks fine to me. -1 length means a NULL. Duh. I had a test for -1, but I was reading the length as an unsigned integer. I'd have to wait a while for 4 billion bytes :). BTW, very nice job on the 3.0 protocol. Very clean and pretty straightforward to implement. Thanks for your help, John DeSoi, Ph.D. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] 3.0 fe/be protocol bug?
I'm working on a new client with the 3.0 protocol. I'm having a problem with the data DataRow message from this select: select oid, datconfig from pg_database There seems to be a problem with text[] type for datconfig. The hex dump (from tcpflow) for 1 data row message is: 44 0013 0002 0005 3137303632 D mesg len 2col col1 len5 oid 17602 len col2 here? After the next DataRow message starts. I'm using "PostgreSQL 7.4devel on powerpc-apple-darwin6.6, compiled by GCC gcc (GCC) 3.1 20020420 (prerelease)" downloaded from cvs this past weekend. Thanks, John DeSoi, Ph.D. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
