Re: [HACKERS] Win32 port patches submitted
Bruce Momjian kirjutas P, 26.01.2003 kell 05:07: Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: I don't see a strong reason not to stick with good old configure; make; make install. You're already requiring various Unix-like tools, so you might as well require the full shell environment. Indeed. I think the goal here is to have a port that *runs* in native Windows; but I see no reason not to require Cygwin for *building* it. Agreed. I don't mind Cygwin if we don't have licensing problems with distributing a Win32 binary that used Cygwin to build. I do have a problem with MKS toolkit, which is a commerical purchase. I would like to avoid reliance on that, though Jan said he needed their bash. IIRC mingw tools had win-native (cygwin-less) bash at http://sourceforge.net/projects/mingw/ -- Hannu Krosing [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: [HACKERS] Win32 port patches submitted
Hannu Krosing wrote: Bruce Momjian kirjutas P, 26.01.2003 kell 05:07: Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: I don't see a strong reason not to stick with good old configure; make; make install. You're already requiring various Unix-like tools, so you might as well require the full shell environment. Indeed. I think the goal here is to have a port that *runs* in native Windows; but I see no reason not to require Cygwin for *building* it. Agreed. I don't mind Cygwin if we don't have licensing problems with distributing a Win32 binary that used Cygwin to build. I do have a problem with MKS toolkit, which is a commerical purchase. I would like to avoid reliance on that, though Jan said he needed their bash. IIRC mingw tools had win-native (cygwin-less) bash at http://sourceforge.net/projects/mingw/ Have been watching this ongoing conversation and am in two frames of mind about: + There are a lot of people on Win32 that are using MS Visual C or Visual Studio + There are a few fairly well established Win32 programming IDE's that are compatible with cygwin/mingw32 The advantages to having the Win32 port be natively compatible with Visual Studio is that it already is (no toolset-porting work needed there), but the disadvantage is that not just any Win32 user-with-an-interest can download it any try it out. So... that kind of excludes it somewhat (Universities/colleges might have a problem too). The advantages of having the Win32 port be natively compatible with gcc/cygwin/something is that once it's converted to that toolchain, it might be a lot less maintenance on us, as that's the toolset we use for the Unix builds. As a thought, the open source Dev-C++ IDE (Win32 and Linux) works with gcc/cygwin/mingw32 and is pretty popular. Just checked it's homepage on SourceForge (http://sourceforge.net/projects/dev-cpp/) and it's download figures are pretty large. Since March 2002 (less than 1 year ago), it's been downloaded about 120,000,000 times. Wow. 120 Million downloads in less than 1 year. That's a pretty popular IDE (16th most popular project on SourceForge) Anyway, as a thought, my vote would be to make the Win32 port work in with our toolchain or very similar (cygwin/mingw32/etc) if possible, so we don't have to rely on people having Visual C. In developing countries too, it's going to be much easier for people to get a hold of things like Dev-C++ into the future as well. Hope this provides a useful set of thoughts. :-) Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(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] [SQL] Function for adding Money type
On Friday 24 January 2003 19:17, Josh Berkus wrote:
The MONEY type is depreciated, and should have been removed from the
Postgres source but was missed as an oversight. Use NUMERIC instead.
Note that not all of us agree. I had to change all of our fields from MONEY
to NUMERIC recently because of the lack of support for MONEY but I would
prefer to see it improved instead. Now that we have changed we find that we
need to create a new table for balances driven by a trigger because
calculating balances just went up in cost with that change. The reason is
simply that MONEY used nothing but integer arithmetic and NUMERIC has to do a
lot more processing in code.
This year, my team is planning on improving the MONEY type. Of course, we can
always make it a user defined type if PostgreSQL doesn't want it. We will at
least put it into contrib. However, if people think that it is useful and
want to leave it in the main tree that's good too. What we want to do is a)
switch to a 64 bit integer from a 32 bit integer in order to hold amounts of
any reasonabe size and b) allow it to be cast to and from more types.
Perhaps we can also add the ability to specify the number of decimal places
on output but I am not sure if that would affect the primary benefit of using
it, speed.
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | 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] [CYGWIN] Have a PG 7.3.1 Windows (cygwin) easy installer... now
I thought I sent off an email about how to do it, OK here goes:
Create a working minimal cygwin with postgres install.
Delete unwanted utilities and files.
Test if you can start, stop, initdb, and query Postgres.
Use the attached pgsql.iss script to make the install.
Notes:
My version of the console program may be different than what is up on
winmaster. I sent all my changes to Igor, but I have never been able to
compile what he sends back. I'm not sure what compiler he is using, I am
building mine with gcc and MSVC.
The registry entries are very important, make sure you don't mess with
them too much.
You asked how I managed the run as service issue. I handled it by
ignoring it. I do not setup the run as service option because, IMHO, it
is too hard to ensure that the setup works without any problems. I
modified the console program to take care of the issues of running
PostgreSQL under cygwin, including cygipc. If I were to add run as a
service I would write a service program that wrapped the cygwin and
cygipc details in much the same way as the console program does.
Further thoughts about run as service. My install is aimed at Windows
power users, not back office guys. PostgreSQL with cygwin is not ready
for the back office, the biggest problems are the limit of concurrent
connections and performance. I don't trust cygwin as a reliable service,
so adding the option run as a service may just encourage them to do
so. I think that would do more harm than not having the option. When
PostgreSQL has a native Windows version, I'll add it. Until then, I
think of it more as a desktop version for small offices and
developers. The server version currently only runs on UNIX
Justin Clift wrote:
mlw wrote:
Sorry, I think there was a misunderstanding. What were you looking for?
Sorry Mark, I just thought you were busy.
Was wondering if you were going to make a project of it somewhere, so
we can get things together and have a really decent release for
Windows when 7.4 comes out. :)
I used inno setup as well. If you want I can send my install script.
That would be really cool. :)
How did you handle the user and Log on as a service aspects of it?
:)
I thought I was being very forth coming.
Yep, you 100% have a really good attitude, that's why I thought you
were busy.
:)
I even help out on the Windows PG console window.
Took a look at it, and the three buttons seem permanently greyed out
in the download from the WinMaster project. Wasn't sure if it was a
configuration issue on my part, or if the code hadn't been fleshed out
yet.
Interested in making a project on GBorg or something for the complete
Windows installer as a place to work out of?
:-)
Regards and best wishes,
Justin Clift
;PostgreSQL for Windows by Mohawk Software
;Copyright (C) 2002-2003 Mark L. Woodward
;
;This file is free software; you can redistribute it and/or
;modify it under the terms of the GNU General Public
;License as published by the Free Software Foundation; either
;version 2 of the License, or (at your option) any later version.
;
;This file is distributed in the hope that it will be useful,
;but WITHOUT ANY WARRANTY; without even the implied warranty of
;MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
;Library General Public License for more details.
;
;You should have received a copy of the GNU General Public
;License along with this file; if not, write to the Free
;Software Foundation, Inc., 59 Temple Place - Suite 330, Boston,
;MA 02111-1307, USA
;
;If you want support or to commercially license this file, the author
;can be reached at [EMAIL PROTECTED]
[Setup]
AppName=PostgreSQL
AppVerName=PostgreSQL 7.3 for Windows
AppPublisher=Mohawk Software
AppPublisherURL=http://www.mohawksoft.com
AppSupportURL=http://www.mohawksoft.com
AppUpdatesURL=http://www.mohawksoft.com
DefaultDirName={sd}\PostgreSQL
DisableStartupPrompt=yes
DefaultGroupName=PostgreSQL
AllowNoIcons=yes
SourceDir=e:\pginstall\source
OutputBaseFilename=pgsetup
OutputDir=e:\pginstall\PostgreSQL
[Registry]
Root: HKLM; Subkey: SOFTWARE\Cygnus Solutions; Flags: uninsdeletekeyifempty
Root: HKLM; Subkey: SOFTWARE\Cygnus Solutions\Cygwin; Flags: uninsdeletekeyifempty
Root: HKLM; Subkey: SOFTWARE\Cygnus Solutions\Cygwin\mounts v2; Flags:
uninsdeletekeyifempty
Root: HKLM; Subkey: SOFTWARE\Cygnus Solutions\Cygwin\mounts v2; ValueType: String;
ValueName: cygdrive prefix; ValueData: /disks; Flags: uninsdeletekeyifempty
Root: HKLM; Subkey: SOFTWARE\Cygnus Solutions\Cygwin\mounts v2; ValueType: dword;
ValueName: cygdrive flags; ValueData: 34; Flags: uninsdeletekeyifempty
Root: HKLM; Subkey: SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/; ValueType: String;
ValueName: native; ValueData: {app}; Flags: uninsdeletekeyifempty
Root: HKLM; Subkey: SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/; ValueType: dword;
ValueName: flags; ValueData: $0A;
[HACKERS] postgresql.org
Should it be saying, Temporarily Unavailable? Regards, -- Greg Copeland [EMAIL PROTECTED] Copeland Computer Consulting ---(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] [SQL] Function for adding Money type
On Sun, 2003-01-26 at 13:53, D'Arcy J.M. Cain wrote: This year, my team is planning on improving the MONEY type. Of course, we can always make it a user defined type if PostgreSQL doesn't want it. We will at least put it into contrib. However, if people think that it is useful and want to leave it in the main tree that's good too. What we want to do is a) switch to a 64 bit integer from a 32 bit integer in order to hold amounts of any reasonabe size and b) allow it to be cast to and from more types. Perhaps we can also add the ability to specify the number of decimal places on output but I am not sure if that would affect the primary benefit of using it, speed. A money type needs to specify what currency is held. The current one changes the currency with the locale, which makes nonsense of existing data. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C Wash me thoroughly from mine iniquity, and cleanse me from my sin. For I acknowledge my transgressions; and my sin is ever before me. Against thee, thee only, have I sinned, and done this evil in thy sight... Psalms 51:2-4 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [CYGWIN] Have a PG 7.3.1 Windows (cygwin) easy installer... now what to do with it?
-Original Message- From: Justin Clift [mailto:[EMAIL PROTECTED]] Sent: 26 January 2003 03:12 To: PostgreSQL Hackers Mailing List; PostgreSQL Cygwin Mailing List Subject: [CYGWIN] Have a PG 7.3.1 Windows (cygwin) easy installer... now what to do with it? Anyway, spent the last two days making a brand new PostgreSQL 7.3.1 Proof of Concept for Windows Alpha 1 easy-installer (11,161KB) using a product called Inno Setup (very nice) and have a pretty good result. Hi Justin, Does it use the Microsoft Installer service so we can provide a merge module for embedded installations in other products as we do for psqlODBC? If not, I for one will probably end up redoing it all anyway :-( Regards, Dave. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for objections: put back OIDs in CREATE TABLE AS/SELECT
Ross, you make some powerful arguments here. Probably the most significant was the idea that you need a unique identifier for every row, and it should be of a consistent type, which primary key is not. We clearly need a GUC parameter to turn on/off oids. But it seems we will always need the ability to return something like OID to the user if the user wants it. What it seems we need is a 64-bit oid someday. As an aside, as Tom already said, the 7.3.X patch is just to make CREATE TABLE and CREATE TABLE AS behave the same for OIDs. It does not effect our defaults for future releases, though this little change in 7.3.0 did show use that some folks are using OID and did miss them. --- Ross J. Reedstrom wrote: On Thu, Jan 23, 2003 at 10:03:28AM -0500, Tom Lane wrote: Curt Sampson [EMAIL PROTECTED] writes: I object. I personally think we should be moving towards not using OIDs as the default behaviour, inasmuch as we can, for several reasons: All these objections are global in nature, not specific to CREATE TABLE AS. The argument that persuaded me to do something here is that CREATE TABLE AS should not be different from CREATE TABLE's default behavior. I have no problem with moving towards lack-of-OIDs as the default behavior for both statements, in the long run, if we can get past the compatibility issues. But I don't think OIDs in user tables are costing us anything much, so I'm not prepared to take any big compatibility hit to change the default ... Agreed as to taking the compatability hit in the 7.3 branch (you _were_ talking about changing 7.3, weren't you?) But I think Curt and D'Arcy have a point: what OIDs are costing the DBAs and PostgreSQL developing community is the pain of having an 'almost' solution in place. OIDs have always been the unwanted child in PostgreSQL: the 'pure relational' people don't want them, and the Object people are misled into thinking we've got a _real_ object id. On the relational side, they've stood in for proper use of primary keys (as D'Arcy points out), partly because it's so _easy_ to misuse them that way: the wire protocol returns the OID for free in some cases, and the interface libraries make it easy to get at. So the immediate case, changing the default (in 7.3) to match the CREATE TABLE case makes sense. However, we need to wean developers off using OIDs. I've been working with Diedrich Vorberg on a thin python object relational mapping interface (his Object Relational Membrane - ORM) and this was a central problem: you _need_ a unique id for an object, and the oid seemed so natural ... So in the longer term, we need to provide a replacement. Arguably, the primary key for a table is the right replacement, but we don't _require_ a pkey, so what to do in cases where this isn't one? Also, the pkey can be _any_ column(s), of _any_ type, which could be inconvenient for returning as the result of an insert, for example (imagine a text field as pkey, with a _huge_ block of text just written into it ...) Ross ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 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] Request for qualified column names
-- Dave Cramer [EMAIL PROTECTED] Cramer Consulting This is useful for some O/R tools. The JDBC spec has a getTableName method for each column in a result set. One issue which will come up is what to do with aggregate, and computed values. For now, we could return null So for a select a, b, a+b as sum from c returns c.a, c.b, ?table?.sum Dave ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Sorting Chinese data in Postgresql 7.3.1
Tatsuo, I have been trying to get the sorting of Chinese data in Postgresql 7.3.1 to work without much success. Here is what I did. I rebuilt the executables with ./configure -enable-multibyte=ENC_CN on a RedHat Linux 8.0 Pentium 2 system. The build was successful. I created a test database cluster and a database instance using the -E EUC_CN option. The database ran OK: I could successfully save and retrieve Chinese(GB2312) from some test database tables. However, when I tried to select data from a table with Chinese (GB2312) data with an order by clause, the outcome indicate that the order by instruction had no effect. Do you know if sorting Chinese data works in Postgresql 7.3.1? If yes, how would I get it to work? If no, what can be done? I am willing to help to get this work if there is not someone already working on it. That might be a Chinese locale problem. Try re-initdb with --no-locale option to disable the locale support. Unfortunately there's no way to build PostgreSQL 7.3 or later without locale support except specify the option at initdb time. -- Tatsuo Ishii ---(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] Request for qualified column names
Dave Cramer [EMAIL PROTECTED] writes: So for a select a, b, a+b as sum from c returns c.a, c.b, ?table?.sum This might be something to consider as part of the planned protocol overhaul. We cannot simply change the returned column names --- at least not without breaking a lot of application code. But if we return table name (and schema name too!) as separate fields of the 'T' message, and make them accessible through new PQfoo accessor functions, then no existing applications would break. But there are more than a few definitional issues to be settled before you'll convince me this idea is fully baked. Some things that come to mind immediately: What happens with views? Given create view v as select col as vcol from tab; select vcol from v; are you expecting to get back v.vcol? Or tab.col? What happens with FROM-clause aliases? Supposing tab really has a column col, what do you expect to see from select * from tab AS a(t1), tab AS b(t2) WHERE ... You could make a case for either tab.col, tab.col or a.t1, b.t2 (in the latter case, you can't realistically return a schema name). But you will probably break existing code if you do the former, since currently the output columns are labeled t1, t2. What happens with join aliases (similar issues to above)? Do you think select col as foo from tab should return tab.foo, or just foo? I'd lean to the latter; tab.foo seems awfully misleading. Or maybe you're wanting it to ignore the AS and return tab.col? Don't think that will fly. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for objections: put back OIDs in CREATE TABLE
On Sun, 26 Jan 2003, Bruce Momjian wrote: Ross, you make some powerful arguments here. Probably the most significant was the idea that you need a unique identifier for every row, and it should be of a consistent type, which primary key is not. I don't see why you need a unqiue identifier per row, nor do I see why, if you are going to have one, it needs to be the same type across all tables. Having this may be very desirable, and even necessary, for many or all object-to-relational mapping frameworks, but that is certainly not the only thing that postgres is used for. And I still maintain that if something does need something like of OIDs, it should be declared explicitly in the database schema (as you have to do in other DBMSes) and not use a hidden feature. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
Bruce, I've finished digging for stuff that seems to be appropriate to back-patch for 7.2.4. Do you have time to generate the release notes and brand the release? Attached are the CVS commit messages for all the changes in that branch since 7.2.3. regards, tom lane 2003-01-26 18:16 tgl * src/backend/commands/user.c (REL7_2_STABLE): Back-patch fixes to detoast pg_group.grolist. 2003-01-26 18:09 tgl * src/backend/access/heap/heapam.c (REL7_2_STABLE): Back-patch fixes to ensure t_ctid always has correct value (prevents some instances of 'No one parent tuple' VACUUM error, and perhaps worse things). 2003-01-26 17:33 tgl * src/: backend/utils/adt/datetime.c, test/regress/expected/timestamp.out, test/regress/expected/timestamptz.out (REL7_2_STABLE): Back-patch fix for alphabetization mistakes in datetime token tables. 2003-01-21 14:51 tgl * src/backend/access/transam/xlog.c (REL7_2_STABLE): Back-patch fix to ensure pg_clog updates are not only written but sync'ed before we consider the checkpoint to be done. 2003-01-21 14:41 tgl * src/backend/utils/adt/geo_ops.c (REL7_2_STABLE): Back-patch fixes for integer overflows in circle_poly(), path_encode(), and path_add() --- from Neil Conway. Also, repair recently-detected errors in lseg_eq(), lseg_ne(), lseg_center(). 2003-01-21 14:38 tgl * src/backend/commands/vacuum.c (REL7_2_STABLE): Back-patch fix for VACUUM being confused by SELECT FOR UPDATE of tuple that was previously outdated by a transaction that later aborted. Also, prevent VACUUM from being called inside function. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Windows Build System
Are there no already-written converters from Makefile to VC project files? --- Curtis Faith wrote: I (Curtis Faith) previously wrote: The Visual C++ Workspaces and Projects files are actually text files that have a defined format. I don't think the format is published but it looks pretty easy to figure out. Hannu Krosing replied: will probably change between releases Even if the format changes, the environment always has a converter that updates the project and workspace files to the new format. In other words, Visual C++ 6.0 reads 5.0 projects, 7.0 reads 6.0, etc. The format is mostly a bunch of options specifications (which wouldn't get touched) followed by a set of named groups of source files. Even if the overall format changes, it will be much more likely to change in the specifications rather than the way lists of source file formats are specified. A conversion tool, call it BuildWindowsProjectFile, would only need to: 1) Read in the template file (containing all the options specifications and Visual C++ speficic stuff, debug and release target options, libraries to link in, etc.) This part might change with new versions of the IDE and would be manually created by someone with Visual C++ experience. 2) Read in the postgreSQL group/directory map, or alternately just mirror the groups with the directories. 3) Output the files from the PostgreSQL directories in the appropriate grouping according to the project format into the appropriate space in the template. An excerpt of the format follows: # Begin Group Access # Begin Group Common # PROP Default_Filter cpp;c;cxx # Begin Source File SOURCE=.\access\common\heaptuple.c # End Source File # Begin Source File SOURCE=.access\common\indextuple.c # End Source File ... other files in access\common go here # End Group # Begin Group Index # PROP Default_Filter cpp;c;cxx # Begin Source File SOURCE=.\access\index\genam.c # End Source File # Begin Source File SOURCE=.access\index\indexam.c # End Source File ... other files in access\index go here # End Group # End Group As you can see, this is a really simple format, and the direct folder/group mapping to PostgreSQL directory is pretty natural and probably the way to go. Using the approach I outline, it should be possible to have the Unix make system automatically run the BuildWindowsProjectFile tool whenever any makefile changes so the Windows projects would stay up to date without additional work for Unix developers. Hannu Krosing also wrote: (also I dont think you can easily compile C source on a C# compiler) ;/ I don't think it makes much sense target a compiler that won't compile the source, therefore, if what you say is true, we shouldn't bother with targeting C#. - Curtis ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: [HACKERS] Sorting Chinese data in Postgresql 7.3.1
I tried initdb -E EUC_CN --no-locale and tested order by with the same Chinese data, I got the same result: the order by clause does not have any effect. The locale on my Redhat Linux 8.0 is en_US.UTF-8. By the way, the manual page for initdb does not show an option --no-locale. That's a bug with the man page. Try initdb --help to find the option. Could you point me to the source codes where I can pin down this? No idea at this point. What about the results of following SQL? SELECT 'chinese char1'::text 'chinese char2'::text; Do you get same result for any Chinese (EUC_CN) characters? -- Tatsuo Ishii ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [CYGWIN] Have a PG 7.3.1 Windows (cygwin) easy installer... now
Dave Page wrote: snip Hi Justin, Does it use the Microsoft Installer service so we can provide a merge module for embedded installations in other products as we do for psqlODBC? If not, I for one will probably end up redoing it all anyway :-( Hi Dave, It's an installation setup.exe type of thing, created using a product called Inno Setup. Spent about 20 minutes last night on an email to Mark (mlw) yesterday after analysing his Inno Setup script (he's got some good ideas in there), but Mozilla died when I hit send. Arrgh. It would be cool if we had a project on GBorg for it, so we can create and co-ordinate the windows specific bits that will be desirable to have for 7.4 when it's released. We can use 7.3.1 for the moment and practise with that. There's probably no real reason that people can't use the 7.3.1 version for smaller stuff in the real world (personal workstation database for development, etc). The package here also has the ODBC drivers in it, but doesn't include pgAdmin, nor Igor's WinMaster. It was originally assembled with both of them, but WinMaster didn't seem to really add anything (the package auto-installs as a service), and with pgAdmin I was having trouble getting it to register HighlightBox.ocx and use it once installed. :( No real stress there, as I'm really sure the pgAdmin team and yourself will be able to give pointers on how to make that work properly. :) Mark's version uses his custom built CygConsole program, based on Igor's WinMaster, and sounds like it has more functionality, but it doesn't install as a service. The target for the package here is that PostgreSQL gets installed and runs in the background unless it's explicitely disabled or de-installed. The package here also has a bunch of shortcuts in it to the websites. Will chuck it up on the techdocs site somewhere in a few minutes as a temporary home until we get the GBorg project up and running. Anyone have a good idea for the name of the project? :-) Regards and best wishes, Justin Clift Regards, Dave. -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(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] Can we revisit the thought of PostgreSQL 7.2.4?
I think we have to accept the statement that in 7.2.X malicious SQL queries can cause database failure, and fixing one or two of the ten known problems doesn't change that fact. I don't have a problem with releasing 7.2.4 and including all the fixes, including security fixes, but I don't see the security fixes _as_ _a_ _reason_ to release a 7.2.4. So, do we have non-security fixes to warrant a 7.2.X? Gavin Sherry and I have just spent a week at the Linux.conf.au. The feedback we got from users was basically this: 1. We don't allow untrusted users unlimited SQL access 2. Upgrading PostgreSQL sucks 3. We want important corruption fixes 4. So, keep supporting older versions (7.2.x at least) So, basically I think it is a VERY good idea for us to keep releasing 7.2.x versions for a long time. BTW, I'll be posting a linux.conf.au postgres report soonish... Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] unquoted special constants
No actually, the docs. I need to know for the phpPgAdmin project... Chris -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED]] Sent: Sunday, 26 January 2003 10:03 AM To: Christopher Kings-Lynne Cc: Hackers Subject: Re: [HACKERS] unquoted special constants Looks like you got them all. I assume you got those from gram.y. -- - Christopher Kings-Lynne wrote: Hi, Is this the complete list of constants that must not be quoted? CURRENT_TIME CURRENT_TIMESTAMP CURRENT_DATE LOCAL_TIME LOCAL_TIMESTAMP CURRENT_USER SESSION_USER USER Anything else? (Aside from functions?) Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: [HACKERS] [BUGS] New hashed IN code ignores distinctiveness of subquery
[Moving - -hackers] On Mon, Jan 27, 2003 at 12:00:08AM -0500, Tom Lane wrote: Bradley Baetz [EMAIL PROTECTED] writes: However, its much faster (although not as fast as sticking the DISTINCT in there myself), but the actual rows coming from the sort is really odd - where is that number coming from? How can sorting 9 rows take 44476 anythings? We're back full circle to my original comment about rescans in mergejoin. The EXPLAIN ANALYZE instrumentation counts a re-fetch as another returned row. Hmm. OK, I poked through the code a bit more, and I think I now realise why we were talking across each other. I've attached a 'patch' which gets the mergejoin counts down to something reasonable. (The patch also includes a bit to fix the estimated row count for JOIN_IN, as discussed on -bugs) When calculating the cost for a join, if a path is a T_UniquePath, then the reduction in the number of rows to be examined isn't taken into account. This is why the mergejoin code was calulating the cost of merging two 5 tuple paths - the overestimation that you menioned earlier isn't as important here. For reference, bugs is a 5 row table, and there are 9 distinct values for product_id. Before(with the num_rows part of the patch, though) bbaetz=# explain analyze select count(*) FROM bugs where product_id IN (SELECT product_id FROM bugs); QUERY PLAN - Aggregate (cost=3494816.98..3494816.98 rows=1 width=8) (actual time=579.71..579.71 rows=1 loops=1) - Merge Join (cost=5169.41..3494691.43 rows=50218 width=8) (actual time=111.41..530.16 rows=5 loops=1) Merge Cond: (outer.product_id = inner.product_id) - Index Scan using bugs_product_id_idx on bugs (cost=0.00..1834.52 rows=5 width=4) (actual time=0.13..249.57 rows=5 loops=1) - Sort (cost=920.14..920.17 rows=9 width=4) (actual time=111.25..143.42 rows=44476 loops=1) Sort Key: public.bugs.product_id - HashAggregate (cost=920.00..920.00 rows=9 width=4) (actual time=111.17..111.18 rows=9 loops=1) - Seq Scan on bugs (cost=0.00..795.00 rows=5 width=4) (actual time=0.00..67.41 rows=5 loops=1) Total runtime: 579.84 msec (9 rows) After: bbaetz=# explain analyze select count(*) FROM bugs where product_id IN (SELECT product_id FROM bugs); QUERY PLAN - Aggregate (cost=8007.21..8007.21 rows=1 width=8) (actual time=578.16..578.16 rows=1 loops=1) - Merge Join (cost=5169.41..7881.67 rows=50218 width=8) (actual time=110.94..527.79 rows=5 loops=1) Merge Cond: (outer.product_id = inner.product_id) - Index Scan using bugs_product_id_idx on bugs (cost=0.00..1834.52 rows=5 width=4) (actual time=0.13..250.74 rows=5 loops=1) - Sort (cost=920.14..920.17 rows=9 width=4) (actual time=110.78..142.80 rows=44476 loops=1) Sort Key: public.bugs.product_id - HashAggregate (cost=920.00..920.00 rows=9 width=4) (actual time=110.70..110.71 rows=9 loops=1) - Seq Scan on bugs (cost=0.00..795.00 rows=5 width=4) (actual time=0.00..67.14 rows=5 loops=1) Total runtime: 578.30 msec (9 rows) The patch isn't correct as-is, because it only covers merge joins: bbaetz=# set enable_mergejoin=false; SET bbaetz=# explain analyze select count(*) FROM bugs where product_id IN (SELECT product_id FROM bugs); QUERY PLAN - Aggregate (cost=4281712.05..4281712.05 rows=1 width=8) (actual time=410.14..410.14 rows=1 loops=1) - Hash Join (cost=1091.00..4281586.50 rows=50218 width=8) (actual time=126.32..362.30 rows=5 loops=1) Hash Cond: (outer.product_id = inner.product_id) - Seq Scan on bugs (cost=0.00..795.00 rows=5 width=4) (actual time=0.04..66.81 rows=5 loops=1) - Hash (cost=795.00..795.00 rows=5 width=4) (actual time=126.08..126.08 rows=0 loops=1) - Seq Scan on bugs (cost=0.00..795.00 rows=5 width=4) (actual time=0.02..68.23 rows=5 loops=1) Total runtime: 410.25 msec (7 rows) I don't think that propogating my hack to everywhere which wants to know how many rows are returned is a good idea though - is there a more generic way to get the number of rows really returned by a path? regards, tom lane Bradley Index: src/backend/optimizer/path/costsize.c
Re: [HACKERS] Call for objections: put back OIDs in CREATE TABLE
Ross, you make some powerful arguments here. Probably the most
significant was the idea that you need a unique identifier for every
row, and it should be of a consistent type, which primary key is not.
I don't see why you need a unqiue identifier per row, nor do I see why,
if you are going to have one, it needs to be the same type across all
tables.
If i had table with multi col primary key like...
create table devices (
major int4,
minor int4,
primary key (major, minor)
);
... and do this:
insert into devices (major, minor values (224, find_free_minor_for(224))
should the database report something like
INSERT '{([\'224\', \'89\'])}' 1
which I could then parse in my client program and try to recover my
fresh brand new primary key from it? No thanks...
Anyways, I've got an idea: what about having option that INSERTs return
oid_status in form
major = '224' and minor = '10'
or
state = 'ca'
?
Then you could just throw this expression into a select query after where
;P And tables would never need row oids...
--
Antti Haapala
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [mail] Re: [HACKERS] Windows Build System
Theres a script at http://ptolemy.eecs.berkeley.edu/other/makevcgen which may work, I've not tried it, but someone may want to give it a spin. Combining it with the software at http://unxutils.sourceforge.net could give us a MS build environment which only relies on installation support programs rather than relying on the installation and use of the whole Cygwin environment for the build process. Al. - Original Message - From: Bruce Momjian [EMAIL PROTECTED] To: Curtis Faith [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, January 27, 2003 12:57 AM Subject: [mail] Re: [HACKERS] Windows Build System Are there no already-written converters from Makefile to VC project files? -- - Curtis Faith wrote: I (Curtis Faith) previously wrote: The Visual C++ Workspaces and Projects files are actually text files that have a defined format. I don't think the format is published but it looks pretty easy to figure out. Hannu Krosing replied: will probably change between releases Even if the format changes, the environment always has a converter that updates the project and workspace files to the new format. In other words, Visual C++ 6.0 reads 5.0 projects, 7.0 reads 6.0, etc. The format is mostly a bunch of options specifications (which wouldn't get touched) followed by a set of named groups of source files. Even if the overall format changes, it will be much more likely to change in the specifications rather than the way lists of source file formats are specified. A conversion tool, call it BuildWindowsProjectFile, would only need to: 1) Read in the template file (containing all the options specifications and Visual C++ speficic stuff, debug and release target options, libraries to link in, etc.) This part might change with new versions of the IDE and would be manually created by someone with Visual C++ experience. 2) Read in the postgreSQL group/directory map, or alternately just mirror the groups with the directories. 3) Output the files from the PostgreSQL directories in the appropriate grouping according to the project format into the appropriate space in the template. An excerpt of the format follows: # Begin Group Access # Begin Group Common # PROP Default_Filter cpp;c;cxx # Begin Source File SOURCE=.\access\common\heaptuple.c # End Source File # Begin Source File SOURCE=.access\common\indextuple.c # End Source File ... other files in access\common go here # End Group # Begin Group Index # PROP Default_Filter cpp;c;cxx # Begin Source File SOURCE=.\access\index\genam.c # End Source File # Begin Source File SOURCE=.access\index\indexam.c # End Source File ... other files in access\index go here # End Group # End Group As you can see, this is a really simple format, and the direct folder/group mapping to PostgreSQL directory is pretty natural and probably the way to go. Using the approach I outline, it should be possible to have the Unix make system automatically run the BuildWindowsProjectFile tool whenever any makefile changes so the Windows projects would stay up to date without additional work for Unix developers. Hannu Krosing also wrote: (also I dont think you can easily compile C source on a C# compiler) ;/ I don't think it makes much sense target a compiler that won't compile the source, therefore, if what you say is true, we shouldn't bother with targeting C#. - Curtis ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
