Re: [HACKERS] A fairly obvious optimization?
> The select(min) and select(max) took as long as the table scan to find > the count. It seems logical if a btree type index is available (such > as pk_cnx_ds_sis_bill_detl_tb) where the most significant bit of the > index is the column requested, it should be little more than a seek > first or seek last in the btree. Obviously, it won't work with a hashed > index (which is neither here nor there). In the meantime you can use: select extr_stu_id from cnx_ds_sis_bill_detl_tb order by 1 desc limit 1; -- max select extr_stu_id from cnx_ds_sis_bill_detl_tb order by 1 asc limit 1; -- min I guess that is the reason why nobody felt really motivated to implement this optimization. Besides these statements are more powerful, since they can fetch other columns from this min/max row. The down side is, that this syntax varies across db vendors, but most (all?) have a corresponding feature nowadays. select first 1 select top 1 ... This is actually becoming a FAQ :-) Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] A fairly obvious optimization?
On Wed, 2002-05-15 at 23:23, Dann Corbit wrote: > The select(min) and select(max) took as long as the table scan to find > the count. It seems logical if a btree type index is available (such > as pk_cnx_ds_sis_bill_detl_tb) where the most significant bit of the > index is the column requested, it should be little more than a seek > first or seek last in the btree. Obviously, it won't work with a hashed > index (which is neither here nor there). The problem is postgres' extensibility -there is no hard-wired connection between max() and b-tree indexes - you can define an aggregate max() that returns something completely diffrent, say the longest string length or the "best" optimisation techniqe which may or may not be able to use an index. Hannu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Money type
I know that the money type is supposed to be deprecated but I think that there is still some benefit to it. It is small and fast. There are some problems and I would like to address them. The output has a dollar sign attached. This is NA centric and we said years ago that we were going to drop it. I think that that is enough warning. Unless someone has a problem with that I will just go in and get rid of it. Also somewhat NA centric is the two decimal places. This was originally meant to be locale driven but that is a problem for other reasons. What about defaulting it to two decimal places but allowing it to be redefined at table creation time? How hard would it be to make it accept an optional precision? It doesn't cast to other types. If it simply cast to float that would allow it to be more flexible. Do I need to add a float return function for that to work? Limited precision. This can be fixed by going to a 64 bit integer for the underlying type. Are we at a point where we can do that yet? I am afraid that there are still systems that don't have a native 64 bit type. This is not as critical as the other items I think. As the original author of the type I naturally have some bias but I still think that it is a good type for all the reasons we thought it was a good idea before. There is a definite advantage to being able to do integer arithmetic right on the CPU in large financial applications. -- D'Arcy J.M. Cain| Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Money type
On Thu, May 16, 2002 at 06:11:43AM -0400, D'Arcy J.M. Cain wrote: > I know that the money type is supposed to be deprecated but I think that Right. > there is still some benefit to it. It is small and fast. There are some > problems and I would like to address them. > > The output has a dollar sign attached. This is NA centric and we said years > ago that we were going to drop it. I think that that is enough warning. > Unless someone has a problem with that I will just go in and get rid of it. > > Also somewhat NA centric is the two decimal places. This was originally > meant to be locale driven but that is a problem for other reasons. What > about defaulting it to two decimal places but allowing it to be redefined at > table creation time? How hard would it be to make it accept an optional > precision? > > It doesn't cast to other types. If it simply cast to float that would allow > it to be more flexible. Do I need to add a float return function for that to > work? > > Limited precision. This can be fixed by going to a 64 bit integer for the > underlying type. Are we at a point where we can do that yet? I am afraid > that there are still systems that don't have a native 64 bit type. This is > not as critical as the other items I think. I think right is use numeric and to_char() for currency symbol and common and locales correct number formatting. IMHO it's better than use dagerous float and hard coded currency symbol. For example in my country (and a lot of others) is the current money datetype total useless. We have currency symbol after number, etc. Sorry but _IMHO_ is better a less good supported types than more bad datetypes. Karel -- Karel Zak <[EMAIL PROTECTED]> http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] WIN32 native ... lets start?!?
Hi all, I followed the various threads regarding this for some time now. My current situation is: I'm working at a company which does industrial automation, and does it's own custom products. We try to be cross-platform, but it's a windoze world, as far as most measurement devices or PLCs are concerned. We also employ databases for various tasks (including simple ones as holding configuration data, but also hammering production data into it at a rate of several hundred records/sec.) Well, we would *love* to use PostgreSQL in most our projects and products, (and we do already use it in some), because it has proven to be very reliable and quite fast. So, I'm faced with using PostgreSQL on windows also (you can't always put a Linux box besides). We do this using cygwin, but it's a bit painful ;-) (although it works!). Thinking about the hreads I read, it seems there are 2 obstacles to native PG on W: 1.) no fork, 2.) no SYSV IPC Ok, 1.) is an issue, but there's a fork() in MinGW, so it's 'just' going to be a bit slow on new connections to the DB, right?? But this could be sorted out once we *have* a native WIN32 build. The second one's a bit harder, but... I'm currently trying to find time to do a minimal implementation of SYSV IPC on WIN32 calls, just enough to get PG up (doesn't need msg*() for example, right?). As far as I understand it, we would not need to have IPC items around *after* all backends and postmaster have gone away, or? Then there's no need for a 'daemon' process like in cygwin. So, my route would be to get it to run *somehow* without paying attention to speed and not to change much of the existing code, THEN see how we could get rid of fork() on windows. What do you guys think? Anyone up to join efforts? (I'll start the IPC thingy anyway, as an exercise, and see where I'll end). Greetings, Joerg P.s.: thanks for a great database system!! -- Leading SW developer - S.E.A GmbH Mail: [EMAIL PROTECTED] WWW: http://www.sea-gmbh.com ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] WIN32 native ... lets start?!?
Actually, take a look at the thread starting at: http://archives.postgresql.org/pgsql-hackers/2002-05/msg00665.php Right now, IMHO, the big show stopper is passing global variables to the child processes in Windows ... the above thread talks about a method of pulling together the global variables *cleanly* that Tom seems to feel wouldn't add much in the way of long term maintenance headaches ... *and*, as I understand it, would provide us with a means to use threading in future developments if deemed appropriate ... >From what I read by those 'in the know' about Windows programming, if we could centralize the global variables somewhat, using CreateProcess in Windows shouldn't be a big deal, eliminiating the whole fork() headache ... On Thu, 16 May 2002, Joerg Hessdoerfer wrote: > Hi all, > > I followed the various threads regarding this for some time now. My current > situation is: > > I'm working at a company which does industrial automation, and does it's own > custom products. We try to be cross-platform, but it's a windoze world, as > far as most measurement devices or PLCs are concerned. We also employ > databases for various tasks (including simple ones as holding configuration > data, but also hammering production data into it at a rate of several hundred > records/sec.) > Well, we would *love* to use PostgreSQL in most our projects and products, > (and we do already use it in some), because it has proven to be very reliable > and quite fast. > > So, I'm faced with using PostgreSQL on windows also (you can't always put a > Linux box besides). We do this using cygwin, but it's a bit painful ;-) > (although it works!). > > Thinking about the hreads I read, it seems there are 2 obstacles to native PG > on W: > > 1.) no fork, > 2.) no SYSV IPC > > Ok, 1.) is an issue, but there's a fork() in MinGW, so it's 'just' going to > be a bit slow on new connections to the DB, right?? But this could be sorted > out once we *have* a native WIN32 build. > > The second one's a bit harder, but... I'm currently trying to find time to do > a minimal implementation of SYSV IPC on WIN32 calls, just enough to get PG up > (doesn't need msg*() for example, right?). > As far as I understand it, we would not need to have IPC items around *after* > all backends and postmaster have gone away, or? Then there's no need for a > 'daemon' process like in cygwin. > > So, my route would be to get it to run *somehow* without paying attention to > speed and not to change much of the existing code, THEN see how we could get > rid of fork() on windows. > > What do you guys think? Anyone up to join efforts? (I'll start the IPC thingy > anyway, as an exercise, and see where I'll end). > > Greetings, > Joerg > > P.s.: thanks for a great database system!! > -- > Leading SW developer - S.E.A GmbH > Mail: [EMAIL PROTECTED] > WWW: http://www.sea-gmbh.com > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] WIN32 native ... lets start?!?
On Thu, 2002-05-16 at 13:47, Joerg Hessdoerfer wrote: > So, my route would be to get it to run *somehow* without paying attention to > speed and not to change much of the existing code, THEN see how we could get > rid of fork() on windows. Getting it to compile and then "somehow" run on MinGW seems a good first step on road to full native Win32 PG. -- Hannu ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Kerberos principal to dbuser mapping
> > > Is there any existing way of making queries from > > > postmaster (other than setting up a client > > > connection from it)? > > > > There is no existing way, and none will be added in > > the future either. > > There are good system-reliability reasons for > > keeping the postmaster > > away from the database. > > Ok, but it seems wasteful to build primitive database > functionality in parallell to the real database. This issue affects mutual SSL authentication and PKIX in addition to Kerberos. See a followup post for details Bottom line: we should identify and document a canonical solution. P.S., in the case of PKIX, there's a well-defined interface and there's no conceptual problem with maintaining the database via the regular client interface. Bootstrapping the system may be another matter. Bear ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Money type
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes: > Also somewhat NA centric is the two decimal places. This was originally > meant to be locale driven but that is a problem for other reasons. What > about defaulting it to two decimal places but allowing it to be redefined at > table creation time? How hard would it be to make it accept an optional > precision? Possible, but in 32 bits you don't really have room to offer more precision. Another objection is that (AFAIK) there's no way to handle precision specs without wiring them into quite a number of places in the parser, format_type, etc. I'd object to doing that for a nonstandard type like money. > Limited precision. This can be fixed by going to a 64 bit integer for the > underlying type. Are we at a point where we can do that yet? I am afraid > that there are still systems that don't have a native 64 bit type. You could possibly use the same sort of hacks as are in the int8 support --- type int8 is still functional on int64-less platforms, it just has the same range as int4. I guess this would be no loss of functionality compared to where money is now. > As the original author of the type I naturally have some bias but I still > think that it is a good type for all the reasons we thought it was a good > idea before. There is a definite advantage to being able to do integer > arithmetic right on the CPU in large financial applications. I'd rather see the effort invested in making type 'numeric' faster. Even with a 64-bit width, money would still be subject to silent overflow, which I find uncool for financial applications... regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Updated CREATE FUNCTION syntax
As per earlier vague hint, I'm bringing the CREATE FUNCTION syntax in line with SQL99. Everything is fully backward compatible. Here is the new synopsis: CREATE [OR REPLACE] FUNCTION name (args) RETURNS type option [ option... ] [WITH (...)]; where option is any of these in any order: AS string [,string] LANGUAGE name IMMUTABLE STABLE VOLATILE CALLED ON NULL INPUT-- SQL spelling of not "strict" RETURNS NULL ON NULL INPUT -- SQL spelling of "strict" STRICT [EXTERNAL] SECURITY DEFINER -- SQL spelling of "setuid" [EXTERNAL] SECURITY INVOKER -- SQL spelling of not "setuid" IMPLICIT CAST (The SECURITY options are noops right now, but I'm planning to implement them next.) The WITH (...) options are still there, but sort of less encouraged, I guess. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Kerberos principal to dbuser mapping
Daniel writes: > way to solve this is to use a translation method from > principal to database users, i. e. a table. > As the number of users of the database grows, using a > preprocessed flat file to manage this becomes more and > more of a problem. At that point one usually begins to > look for the functionality of a database, and one is > certainly close at hand :). The server cannot access the database before you're authenticated to do so, plus if the authentication setup is contained in the database and you mess it up, how do you get back in? These are the two reasons why the information is kept in flat files. One might come up with ways to edit these files from within the SQL environment, which indeed is a frequently requested feature, but for solving the problem at hand, namely the Kerberos principal to PostgreSQL user mapping, use a flat file. You can probably use most of the ident.conf code. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] WIN32 native ... lets start?!?
> On Thu, 2002-05-16 at 13:47, Joerg Hessdoerfer wrote: > > So, my route would be to get it to run *somehow* without paying > > attention to speed and not to change much of the existing code, > > THEN see how we could get rid of fork() on windows. > What is the biggest problem here? The Shmem/IPC stuff, or the fork() stuff? I'm think that we could do a fork() implementation in usermode by copying the memory allocations. How fast that would be regarding the context switches, i don't know, but i'm willing to experiment some to see how feesible this is... Anyone tried this before? Magnus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Queries using rules show no rows modified?
Tom Lane <[EMAIL PROTECTED]> writes:
> Michael seems to feel that the tuple count should be nonzero if any
> of the replacement operations did anything at all. This does not
> make a lot of sense at the command tag level ("UPDATE 4" might not
> mean that 4 tuples were updated) but if you look at the definition
> of PQcmdTuples ("returns the number of rows affected by the SQL
> command") it's not so unreasonable. And I can see the point of
> wanting to know whether anything happened.
Close.
It's not so much that I want to know exactly what happened, it's that
I want to know that if PostgreSQL says nothing happened, then I can be
sure that nothing happened, rather than being told that nothing
happened when something happened, and vice versa.
In fact, my suggestion---which might suffer from issues that I am not
aware of, perhaps the ones that led to the patch in the first
place---would be that, given ambiguity, have the system return
something that would cause PQcmdTuples to return an empty string (I'm
assuing this would be a result string with no numbers attached at
all).
It is documented, after all, as being the return value when the system
cannot determine an otherwise correct number, and all of the code I
looked at would, I believe, cope gracefully with it, returning what
I'm guessing (except in the Perl case, where I'm sure) is a sentinel
value indicating, "it worked, but I have no idea how many tuples were
involved".
But I'm not wedded to that---I just don't want to get an answer back
that might lead me off into the woods.
As for the issue of whether the tag is the same or not, I am utterly
pragmatic---I don't use it, and don't really have a way to get to it
from the interfaces I use, so I think the best option is probably
something where the rules to describe it are straightforward to
minimize confusion and support issues. And it should be documented
appropriately.
I mean, even when this is resolved, we should probably be putting
something in the documentation that says that PQcmdTuples can really
only really be depended upon as a tri-state value: 0 ("nothing
happened"), >0 ("something happened"), empty string ("heck if I
know").
Mike.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] WIN32 native ... lets start?!?
On Thursday 16 May 2002 22:10, you wrote: [...] > > What is the biggest problem here? > The Shmem/IPC stuff, or the fork() stuff? > I'm think that we could do a fork() implementation in usermode by copying > the memory allocations. How fast that would be regarding the context > switches, i don't know, but i'm willing to experiment some to see how > feesible this is... > > Anyone tried this before? > > Magnus > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster The problem is not the fork() call itself, this has been done (MinGW and cygwin I know of, possibly others) but the speed of fork() on windows, it's creepingly slow (due to usermode copy, I assume ;-). IPC needs to be done, I'm just about to start... Greetings, Joerg -- Leading SW developer - S.E.A GmbH Mail: [EMAIL PROTECTED] WWW: http://www.sea-gmbh.com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Updated CREATE FUNCTION syntax
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Eisentraut > Sent: Thursday, May 16, 2002 1:22 PM > To: PostgreSQL Development > Subject: [HACKERS] Updated CREATE FUNCTION syntax > > > As per earlier vague hint, I'm bringing the CREATE FUNCTION syntax in line > with SQL99. Everything is fully backward compatible. Here is the new > synopsis: > > CREATE [OR REPLACE] FUNCTION name (args) RETURNS type > option [ option... ] [WITH (...)]; > > where option is any of these in any order: > > AS string [,string] > LANGUAGE name > IMMUTABLE > STABLE > VOLATILE > CALLED ON NULL INPUT -- SQL spelling of not "strict" > RETURNS NULL ON NULL INPUT-- SQL spelling of "strict" > STRICT > [EXTERNAL] SECURITY DEFINER -- SQL spelling of "setuid" > [EXTERNAL] SECURITY INVOKER -- SQL spelling of not "setuid" > IMPLICIT CAST > > (The SECURITY options are noops right now, but I'm planning to implement > them next.) > > The WITH (...) options are still there, but sort of less encouraged, I > guess. Is there any standardized way of handling the single-quotes within function definition? Rather than doubling them up (which can make for very messy code when your scripting language uses single quotes!), allowing another symbol to be used, with that symbol be declared in the CREATE FUNCTION line? Interbase uses a system like this: you can set the delimiter to anything you want and use that instead of '. - J. Joel BURTON | [EMAIL PROTECTED] | joelburton.com | aim: wjoelburton Knowledge Management & Technology Consultant ---(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] resetting stats on the fly
Hi All, I can't see that there's any way to reset the stats collector without HUPing the postmaster? Is there? Should there be? Chris ---(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] [GENERAL] Re : Solaris Performance - 64 bit puzzle
On Tue, Apr 30, 2002 at 03:28:13PM -0400, Tom Lane wrote: > Do you need to profile it? It seemed that the 32-bit behavior for > many-equal-keys was so bad that it'd be easy to tell whether it's > fixed, just by rough overall timing of a test case... Sorry for taking yet again so long. Fitting in little tests of this sort of thing can be a bit of a bear -- there's always about 50 other things to do. Anyway, I've performed some simple timed tests that, I think, confirm that the 64 bit library on Solaris is not so bad. version - PostgreSQL 7.2.1 on sparc-sun-solaris2.7, compiled by GCC 3.0.3 bin$ file postmaster postmaster: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped The config file is the default I _think_ I've captured the case that was problematic. As I understood it, qsort was having trouble when hit with many equal keys. I created this table: CREATE TABLE table1 (_date_stamp timestamp default current_timestamp, foo text); The table has no index. It has 512 records; field "foo" has only four distinct values. No matter whether I compiled with the system qsort or the qsort from FreeBSD, I got roughly equivalent results running psql under time. I know that's hardly an ideal test, but as Tom suggested, the 32-bit case seemed to be so astonishingly bad that it should have been enough. I ran the test repeatedly, and the results seem pretty consistent. Here are some typical results: system lib: src$ time psql -p 12000 -o /dev/null -c "select * from table1 order ^by foo" test1 real29m23.822s user2m10.241s sys 0m7.432s FreeBSD lib: postgresql-7.2.1$ time psql -p 12000 -o /dev/null -c "select * from table1 order by foo" test1 real29m38.880s user2m10.571s sys 0m8.032s This example suggests the FreeBSD library is slightly worse in the 64-bit case. That's consistently the case, but the difference is not so great that I'd put any stock in it. I do not know whether there might be any trouble using the FreeBSD library in a 64-bit configuration. I'd say, if you're going to use a 64-bit postmaster, use the Solaris libraries. Hope this is helpful, A -- Andrew Sullivan 87 Mowat Avenue Liberty RMS Toronto, Ontario Canada <[EMAIL PROTECTED]> M6K 3E3 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Updated CREATE FUNCTION syntax
Joel Burton wrote: > > > As per earlier vague hint, I'm bringing the CREATE FUNCTION syntax in line > > with SQL99. Everything is fully backward compatible. Here is the new > > synopsis: > > > > CREATE [OR REPLACE] FUNCTION name (args) RETURNS type > > option [ option... ] [WITH (...)]; > > > > where option is any of these in any order: > > > > AS string [,string] > > LANGUAGE name > > IMMUTABLE > > STABLE > > VOLATILE > > CALLED ON NULL INPUT -- SQL spelling of not "strict" > > RETURNS NULL ON NULL INPUT-- SQL spelling of "strict" > > STRICT > > [EXTERNAL] SECURITY DEFINER -- SQL spelling of "setuid" > > [EXTERNAL] SECURITY INVOKER -- SQL spelling of not "setuid" > > IMPLICIT CAST > > > > (The SECURITY options are noops right now, but I'm planning to implement > > them next.) > > > > The WITH (...) options are still there, but sort of less encouraged, I > > guess. > > Is there any standardized way of handling the single-quotes within function > definition? Rather than doubling them up (which can make for very messy code > when your scripting language uses single quotes!), allowing another symbol > to be used, with that symbol be declared in the CREATE FUNCTION line? > Interbase uses a system like this: you can set the delimiter to anything you > want and use that instead of '. That would be great! The quoting makes pl/pgsql a major pain. It, and dependency tracking. Of course, with PL/SQL, Oracle doesn't even require a delimiter: CREATE PROCEDURE foo(x INTEGER) AS ... END; Somehow they manage to get that past their parser, even if the procedure has "Compilation Errors". It would be sweet... Mike Mascari [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] libpgtcl - backend version information patch
I've attached a patch for libpgtcl which adds access to backend version
numbers.
This is via a new command:
pg_version ?? ??
Using readonly variables rather than a command was my first choice but I
decided that it was inappropiate for the library to start assigning global
variable(s) when that's really the applications job and the command interface
is consistent with the rest of the interface.
Obviously, backend version numbers are specific to a particular connection. So
I've created a new data structure, to keep the information as a distinct unit,
and added an instance of the new structure to the Pg_ConnectionId type. The
version information is retrieved from the given connection on first use of
pg_version and cached in the new data structure for subsequent accesses.
In addition to filling the named variables in the callers scope with version
numbers/strings the command returns the complete string as returned by
version(). It's not possible to turn this return off at the moment but I don't
see it as a problem since normal methods of stopping unwanted values returned
from procedures can be applied in the application if required.
Perhaps the most significant change is that I've increased the package's
version number from 1.3 to 1.4. This will adversly effect anyone using an
application that requires a specific version of the package where their
postgres installation is updated but their application has not been. I can't
imagine there are many applications out there using the package management
features of TCL though.
I envisage this patch applied to 7.3 tip and to 7.2 for the 7.2.2 release
mentioned a couple of days ago. The only problem with doing this for 7.2 that I
can see is where people doing the 'package -exact require Pgtcl 1.x' thing, and
how many of those are there? Even PgAccess doesn't use that.
Note for commiter et al,, this patch also includes one change made in 7.3devel
and not 7.2.1. That is where a test of the return value from a Tcl_SetVar call
has been corrected from a test against TCL_OK to NULL. This is correct and
should be applied to the 7.2 branch in my view, however, I do not know if this
has already been applied there so something to watch out for.
--
Nigel J. Andrews
Director
---
Logictree Systems Limited
Computer Consultants
Index: src/interfaces/libpgtcl/pgtcl.c
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpgtcl/pgtcl.c,v
retrieving revision 1.24
diff -c -r1.24 pgtcl.c
*** src/interfaces/libpgtcl/pgtcl.c 2001/10/25 05:50:12 1.24
--- src/interfaces/libpgtcl/pgtcl.c 2002/05/16 22:07:12
***
*** 152,158
Pg_listen,
(ClientData) NULL, (Tcl_CmdDeleteProc *)
NULL);
! Tcl_PkgProvide(interp, "Pgtcl", "1.3");
return TCL_OK;
}
--- 152,163
Pg_listen,
(ClientData) NULL, (Tcl_CmdDeleteProc *)
NULL);
! Tcl_CreateCommand(interp,
! "pg_version",
! Pg_version,
! (ClientData) NULL, (Tcl_CmdDeleteProc *)
NULL);
!
! Tcl_PkgProvide(interp, "Pgtcl", "1.4");
return TCL_OK;
}
Index: src/interfaces/libpgtcl/pgtclCmds.c
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpgtcl/pgtclCmds.c,v
retrieving revision 1.61
diff -c -r1.61 pgtclCmds.c
*** src/interfaces/libpgtcl/pgtclCmds.c 2002/03/04 02:41:49 1.61
--- src/interfaces/libpgtcl/pgtclCmds.c 2002/05/16 22:07:13
***
*** 423,428
--- 423,431
Tcl_UnregisterChannel(interp, connid->notifier_channel);
#endif
+ if (connid->version.string)
+ ckfree(connid->version.string);
+
return Tcl_UnregisterChannel(interp, conn_chan);
}
***
*** 1967,1971
--- 1970,2106
}
ckfree(caserelname);
+ return TCL_OK;
+ }
+
+ /**
+ Pg_version
+ get backend version numbers
+
+ syntax:
+ pg_version connection majorvar ?minorvar? ?patchvar?
+
+ the return result is either an error message or the full version string
+ returned from the backend with filled in major, minor and patch version
+ variables
+ **/
+
+ int
+ Pg_version(ClientData cData, Tcl_Interp *interp, int argc, char *argv[])
+ {
+ Pg_ConnectionId *connid;
+ PGconn *conn;
+ struct Pg_VersionNumber_s *version;
+
+ if (argc < 3 || argc > 5)
+ {
+ Tcl_AppendResult(interp, "Wrong # of arguments\n",
+"pg_version connection majorvar
[HACKERS] interfaces/ecpg/preproc reduce/reduce conflicts
Just noticed this a few minutes ago on build from cvs tip: make -C preproc all make[4]: Entering directory `/opt/src/pgsql/src/interfaces/ecpg/preproc' bison -y -d preproc.y conflicts: 2 reduce/reduce Joe ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] WIN32 native ... lets start?!?
Joerg Hessdoerfer <[EMAIL PROTECTED]> wrote: [snip] > The problem is not the fork() call itself, this has been done (MinGW > and cygwin I know of, possibly others) but the speed of fork() on > windows, it's creepingly slow (due to usermode copy, I assume ;-). > > IPC needs to be done, I'm just about to start... > I'm not so familiar with the win32 kernel mode stuff. But i've seen programs using .vxd (kernelmode, ring X ?) helpers for getting more privileges, maybe cross process ones. Well, i'll look into this sometime if it's possible to reduce the context switches by going vxd. There must be some way to read protection of the pages and map them as COW or RO in the new process to get rid of much of the copy, but then again, we're talking microsoft here :) I once did a .exe loader that used the MapViewOfFile (win32 mmap) of the .exe itself to accomplish shared loadable modules that worked on x86 linux and win32 without recompile (might be something like the XFree86 binary gfx card drivers). Good luck on the IPC work! Magnus -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Programmer/Networker [|] Magnus Naeslund -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] minor CVS regression
I'm seeing this with the current CVS code: [nconway:/home/nconway/pgsql]% initdb -D /data/pgsql/pgdata The files belonging to this database system will be owned by user "nconway". This user must also own the server process. /data/pgsql/bin/initdb: test: =: unary operator expected The database cluster will be initialized with locales: COLLATE: C CTYPE: MESSAGES: C MONETARY: C NUMERIC: C TIME: C Namely, the "unary operator expected" warning. BTW, does that "CTYPE:" element look correct? Just from a visual point of view, I'd expect it to have a value (e.g. C). Cheers, Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] interfaces/ecpg/preproc reduce/reduce conflicts
Joe Conway <[EMAIL PROTECTED]> writes: > Just noticed this a few minutes ago on build from cvs tip: > make -C preproc all > make[4]: Entering directory `/opt/src/pgsql/src/interfaces/ecpg/preproc' > bison -y -d preproc.y > conflicts: 2 reduce/reduce Yeah, the ECPG grammar has been broken for awhile. I'm expecting Michael to do something about it sooner or later ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] minor CVS regression
Neil Conway <[EMAIL PROTECTED]> writes: > I'm seeing this with the current CVS code: > [nconway:/home/nconway/pgsql]% initdb -D /data/pgsql/pgdata > The files belonging to this database system will be owned by user "nconway". > This user must also own the server process. > /data/pgsql/bin/initdb: test: =: unary operator expected > The database cluster will be initialized with locales: > COLLATE: C CTYPE: MESSAGES: C > MONETARY: C NUMERIC: C TIME: C > > Namely, the "unary operator expected" warning. Fixed. > BTW, does that "CTYPE:" element look correct? Just from a visual > point of view, I'd expect it to have a value (e.g. C). Apparently you are running with LC_CTYPE explicitly set to "". regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] WIN32 native ... lets start?!?
Maybe Vince could set up a Win32 porting project page, and since we now seem to have a few interested parties willing to code on a native Win32 version, they should have their own project page. This could make communication easier for them and make sure the project doesn't die... Chris > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Joerg > Hessdoerfer > Sent: Friday, 17 May 2002 4:36 AM > To: Magnus Naeslund(f) > Cc: [EMAIL PROTECTED] > Subject: Re: [HACKERS] WIN32 native ... lets start?!? > > > On Thursday 16 May 2002 22:10, you wrote: > [...] > > > > What is the biggest problem here? > > The Shmem/IPC stuff, or the fork() stuff? > > I'm think that we could do a fork() implementation in usermode > by copying > > the memory allocations. How fast that would be regarding the context > > switches, i don't know, but i'm willing to experiment some to see how > > feesible this is... > > > > Anyone tried this before? > > > > Magnus > > > > > > ---(end of broadcast)--- > > TIP 4: Don't 'kill -9' the postmaster > > The problem is not the fork() call itself, this has been done (MinGW and > cygwin I know of, possibly others) but the speed of fork() on > windows, it's > creepingly slow (due to usermode copy, I assume ;-). > > IPC needs to be done, I'm just about to start... > > Greetings, > Joerg > -- > Leading SW developer - S.E.A GmbH > Mail: [EMAIL PROTECTED] > WWW: http://www.sea-gmbh.com > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
