Re: [PATCHES] [HACKERS] Final call for translation updates
On Tue, 4 Jan 2005, Peter Eisentraut wrote: With the 8.0 release around the corner, this is as good a time as ever to send in the last translation updates. If your files are not in CVS right now, I don't have them, so please send them again in this case. How much time do we have? Unfortunately, I've been pretty busy for the last weeks, but I'll try to make an effort, at least now. So, what's the last day for sending translation updates? Thanks, Alin ---(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] Home dir changes have broken MSVC builds
Recent changes to interfaces/libpg/fe-connect.c have broken MSVC builds, which I am reliably informed are definitely still required - at least some uses of libpq.dll made with gcc apparently cause the resulting builds or applications to blow up. Can you get some more specifics on that? We know it was a fact with early betas because of the conflicting exports, but I was under the impression that these issues were all fixed by now. (not saying the MSVC build shouldn't work, just that the gcc should work too...) The trouble seems to come from these 2 lines: + #define _WIN32_IE 0x0400 + #include shlobj.h First, on MSVC, _WIN32_IE is already defined at that point. If you get around that then processing the include file causes errors. Interesting - mingw was supposed to use compatible headers, I thought :-) Can you tru moving the #define up to the top of the file and see if that fixes things? So it's pulled before *any* windows include file. (My msvc has completely stopped building fromt he commandline. Need to fix that, but it's not up right now) //Magnus ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] subqueries in check
On Fri, Jan 07, 2005 at 11:06:58PM -0600, Jaime Casanova wrote: Jaime, i was looking at the unsuported features in the RC4 docs and found this: F671| Enhanced integrity management| Subqueries in CHECK| intentionally omitted Why is it *intentionally omitted*? Is it to hard? or has some side-effects? Because it's too expensive to check. If you have a CHECK using a SELECT against a second table, you should re-verify the SELECT every time the second table suffers an UPDATE, INSERT or DELETE. The user can replace the CHECK with a foreign key or a trigger, so there is no loss of functionality. -- Alvaro Herrera ([EMAIL PROTECTED]) No single strategy is always right (Unless the boss says so) (Larry Wall) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [GENERAL] PostgreSQL 8.0.0 Release Candidate 4
Chris Mair wrote: The Playstation 2 hardware manuals confirm that the FPU has no support for NaN and +/-Inf. That explains the regression diffs. (EE Core User's Manual Version 5, p. 153) Well, it does not readily explain that 'infinity' is rejected as invalid input syntax. You should get an overflow or some large value, at least. The relevant code is in src/backend/utils/adt/float.c. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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: [pgsql-ru-general] [HACKERS] Final call for translation updates
Oleg Bartunov wrote: I just completed russian translation of .po files ( except ru.po for backend ). diff against rc3 is available from http://www.sai.msu.su/~megera/postgres/docs/ru.po-8.0.0.rc3.diff.gz This patch doesn't apply cleanly. Please send the individual PO files. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PORTS] PostgreSQL 8 for Win32 -- installation problem
Tom Lane wrote: Perhaps also the filename should be -jp not -ja? I agree with the complainant that the former is more standard. ja = Japanese (ISO 639 language code) jp = Japan (ISO 3166 country code) Since the installation pack is probably targeted at users speaking Japanese, much like the en installer targets users speaking English, ja seems to be correct. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [GENERAL] PostgreSQL 8.0.0 Release Candidate 4
On Sun, 2005-01-09 at 17:45, Peter Eisentraut wrote:
Well, it does not readily explain that 'infinity' is rejected as invalid
input syntax. You should get an overflow or some large value, at
least.
The relevant code is in src/backend/utils/adt/float.c.
You're right.
I had a look at the code.
It seems strtod() is to blame.
This sample program
#include stdio.h
#include stdlib.h
#include errno.h
int main()
{
char *endptr;
double val;
char *num = Infinity;
errno = 0;
val = strtod(num, endptr);
printf(input string is '%s'\n, num);
printf(strtod returned val = %lf\n, val);
printf(errno = %d\n, errno);
printf(endptr points to '%s'\n, endptr);
}
on the PlayStation 2 returns:
input string is 'Infinity'
strtod returned val = inf
errno = 0
endptr points to 'inity'
float.c's conversion routine cannot deal with a strtod that just eats
the 'Inf' part of 'Infinity', so the remaining 'inity' is causing the
syntax error (from line 522 in float.c).
Consistently, this works with the so compiled version of PG:
postgres=# select 'Inf'::float8;
float8
--
Infinity
(1 row)
Would it be worth treating this case apart in float.c, or should we just
blame the PlayStation's 2 Linux (quite old version 2.2.2) Gnu C library
to be broken?
I wonder how many implementations of strtod behave this way?
On a few other boxes of mine I've seen versions that accept 'Infinity'
as a whole or reject it as a whole
Bye, Chris.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] [GENERAL] PostgreSQL 8.0.0 Release Candidate 4
Chris Mair [EMAIL PROTECTED] writes: It seems strtod() is to blame. ... on the PlayStation 2 returns: input string is 'Infinity' strtod returned val = inf errno = 0 endptr points to 'inity' Would it be worth treating this case apart in float.c, or should we just blame the PlayStation's 2 Linux (quite old version 2.2.2) Gnu C library to be broken? I'd just say that that version of glibc is broken. I have not seen this behavior reported anywhere else. In any case, I think we can update the Playstation 2 entry for 8.0 ... regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Home dir changes have broken MSVC builds
Magnus Hagander wrote: Recent changes to interfaces/libpg/fe-connect.c have broken MSVC builds, which I am reliably informed are definitely still required - at least some uses of libpq.dll made with gcc apparently cause the resulting builds or applications to blow up. Can you get some more specifics on that? We know it was a fact with early betas because of the conflicting exports, but I was under the impression that these issues were all fixed by now. (not saying the MSVC build shouldn't work, just that the gcc should work too...) TJ (see addresses) can speak to this. The trouble seems to come from these 2 lines: + #define _WIN32_IE 0x0400 + #include shlobj.h First, on MSVC, _WIN32_IE is already defined at that point. If you get around that then processing the include file causes errors. Interesting - mingw was supposed to use compatible headers, I thought :-) Can you tru moving the #define up to the top of the file and see if that fixes things? So it's pulled before *any* windows include file. (My msvc has completely stopped building fromt he commandline. Need to fix that, but it's not up right now) I surrounded the #define with #ifndef ... #endif. If you agree that would be the first fix. But most errors remained (see my follow up email yesterday) The error appears to be on line that uses NEAR and complains about it ... I see that the MinGW windef.h defines NEAR as empty, while the MSVC windef.h defines it as near. Don't know if that makes a difference. cheers andrew ---(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] Home dir changes have broken MSVC builds
The trouble seems to come from these 2 lines: + #define _WIN32_IE 0x0400 + #include shlobj.h First, on MSVC, _WIN32_IE is already defined at that point. If you get around that then processing the include file causes errors. Interesting - mingw was supposed to use compatible headers, I thought :-) Can you tru moving the #define up to the top of the file and see if that fixes things? So it's pulled before *any* windows include file. (My msvc has completely stopped building fromt he commandline. Need to fix that, but it's not up right now) I surrounded the #define with #ifndef ... #endif. If you agree that would be the first fix. But most errors remained (see my follow up email yesterday) The error appears to be on line that uses NEAR and complains about it ... I see that the MinGW windef.h defines NEAR as empty, while the MSVC windef.h defines it as near. Don't know if that makes a difference. Some reading up on MSDN gives this: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore9 8/html/_core_removing_near_and_far_type_declarations.asp From what I can tell, NEAR is defined to near, which is then defined to blank in my windef.h (from the platform SDK included in VS2003) Could it be that we need to include windef.h explicitly, before we include this one? Worth a try. //Magnus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Home dir changes have broken MSVC builds
Magnus Hagander wrote: The error appears to be on line that uses NEAR and complains about it ... I see that the MinGW windef.h defines NEAR as empty, while the MSVC windef.h defines it as near. Don't know if that makes a difference. Some reading up on MSDN gives this: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore9 8/html/_core_removing_near_and_far_type_declarations.asp From what I can tell, NEAR is defined to near, which is then defined to blank in my windef.h (from the platform SDK included in VS2003) Could it be that we need to include windef.h explicitly, before we include this one? Worth a try. I tried but it didn't work. However, I made some progress with changing the section to look like this: #ifdef WIN32 #include win32.h #ifndef _WIN32_IE #define _WIN32_IE 0x0400 #endif #ifdef near #undef near #endif #define near #include shlobj.h #else Now the make produces this: Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. cd include if not exist pg_config.h copy pg_config.h.win32 pg_config.h cd .. cd interfaces\libpq nmake /f win32.mak Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. Building the Win32 static library... cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm1248.tmp getaddrinfo.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm1249.tmp pgstrcasecmp.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm124A.tmp thread.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm124B.tmp inet_aton.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm124C.tmp crypt.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm124D.tmp noblock.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm124E.tmp md5.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm124F.tmp ip.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm1250.tmp wchar.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm1251.tmp encnames.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm1252.tmp win32.c fe-auth.c fe-protocol2.c fe-protocol3.c fe-connect.c fe-exec.c fe-lobj.c fe-misc.c fe-print.c fe-secure.c pqexpbuffer.c pqsignal.c pthread-win32.c link.exe -lib @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm1253.tmp cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm1254.tmp libpqdll.c rc.exe /l 0x409 /fo.\Release\libpq.res libpq.rc link.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm1255.tmp libpqdll.def(3) : warning LNK4017: DESCRIPTION statement not supported for the target platform; ignored Creating library .\Release\libpqdll.lib and object .\Release\libpqdll.exp libpq.lib(fe-connect.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _pqGetHomeDirectory .\Release\libpq.dll : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'link.exe' : return code '0x460' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\BIN\nmake.exe' : return code '0x2' Stop. cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Home dir changes have broken MSVC builds
Andrew Dunstan [EMAIL PROTECTED] writes: Creating library .\Release\libpqdll.lib and object .\Release\libpqdll.exp libpq.lib(fe-connect.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _pqGetHomeDirectory .\Release\libpq.dll : fatal error LNK1120: 1 unresolved externals One part of the home-dir change involved adding shell32.dll (I think) to the link commands for libpq and/or psql. Probably this needs to propagate into the msvc and borland makefiles? regards, tom lane ---(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] Home dir changes have broken MSVC builds
Andrew Dunstan [EMAIL PROTECTED] writes: Creating library .\Release\libpqdll.lib and object .\Release\libpqdll.exp libpq.lib(fe-connect.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _pqGetHomeDirectory .\Release\libpq.dll : fatal error LNK1120: 1 unresolved externals One part of the home-dir change involved adding shell32.dll (I think) to the link commands for libpq and/or psql. Probably this needs to propagate into the msvc and borland makefiles? Most definitly. //Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Home dir changes have broken MSVC builds
The error appears to be on line that uses NEAR and complains about it ... I see that the MinGW windef.h defines NEAR as empty, while the MSVC windef.h defines it as near. Don't know if that makes a difference. Some reading up on MSDN gives this: http://msdn.microsoft.com/library/default.asp?url=/library/en- us/vccore9 8/html/_core_removing_near_and_far_type_declarations.asp From what I can tell, NEAR is defined to near, which is then defined to blank in my windef.h (from the platform SDK included in VS2003) Could it be that we need to include windef.h explicitly, before we include this one? Worth a try. I tried but it didn't work. However, I made some progress with changing the section to look like this: #ifdef WIN32 #include win32.h #ifndef _WIN32_IE #define _WIN32_IE 0x0400 I beleive his will break if _WIN32_IE is previously defined as something 0x0400. Not sure if we build with a patform SDK with that old defaults at all, but just to be sure it's probably better to #undef it and then #define it. #endif #ifdef near #undef near #endif #define near #include shlobj.h #else //Magnus ---(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] Home dir changes have broken MSVC builds
Magnus Hagander wrote: #ifdef WIN32 #include win32.h #ifndef _WIN32_IE #define _WIN32_IE 0x0400 I beleive his will break if _WIN32_IE is previously defined as something 0x0400. Not sure if we build with a patform SDK with that old defaults at all, but just to be sure it's probably better to #undef it and then #define it. #endif #ifdef near #undef near #endif #define near #include shlobj.h #else Ok, I did that, made identical changes to src/port/path.c, and added shell32.lib (not shell32.dll) to src/win32.mak - and with that it does indeed complete. The make traces are shown below. Do any of these warnings matter, or is this good enough to wrap up and send in a patch? What's that one about the DESCRIPTION statement? cheers andrew --- Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. cd include if not exist pg_config.h copy pg_config.h.win32 pg_config.h cd .. cd interfaces\libpq nmake /f win32.mak Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. Building the Win32 static library... cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12CF.tmp getaddrinfo.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12D0.tmp pgstrcasecmp.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12D1.tmp thread.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12D2.tmp inet_aton.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12D3.tmp crypt.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12D4.tmp noblock.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12D5.tmp md5.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12D6.tmp ip.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12D7.tmp wchar.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12D8.tmp encnames.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12D9.tmp win32.c fe-auth.c fe-protocol2.c fe-protocol3.c fe-connect.c fe-exec.c fe-lobj.c fe-misc.c fe-print.c fe-secure.c pqexpbuffer.c pqsignal.c pthread-win32.c link.exe -lib @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12DA.tmp cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12DB.tmp libpqdll.c rc.exe /l 0x409 /fo.\Release\libpq.res libpq.rc link.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12DC.tmp libpqdll.def(3) : warning LNK4017: DESCRIPTION statement not supported for the target platform; ignored Creating library .\Release\libpqdll.lib and object .\Release\libpqdll.exp cd ..\..\bin\psql nmake /f win32.mak Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12E2.tmp exec.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12E3.tmp getopt.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12E4.tmp getopt_long.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12E5.tmp path.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12E6.tmp pgstrcasecmp.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12E7.tmp sprompt.c cl.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12E8.tmp command.c C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\direct.h(124) : warning C4003: not enough actual parameters for macro 'mkdir' common.c common.c(616) : warning C4018: '' : signed/unsigned mismatch copy.c describe.c help.c input.c large_obj.c mainloop.c mbprint.c print.c print.c(1238) : warning C4090: 'function' : different 'const' qualifiers print.c(1239) : warning C4090: 'function' : different 'const' qualifiers prompt.c psqlscan.c startup.c stringutils.c tab-complete.c variables.c link.exe @C:\DOCUME~1\adunstan\LOCALS~1\Temp\nm12E9.tmp cd ..\.. echo All Win32 parts have been built! All Win32 parts have been built! ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] PG 8.0: the launch clock is running
Current plans are to wrap the PG 8.0 final tarball Monday evening, with public announcement Wednesday morning (morning and evening measured in North American east coast time zones). The slightly longer than usual delay is to let the Windows installer team put up a final Windows installer package before public announcement; also we may be able to have RPMs etc available at launch. If you've got a problem with this plan, speak now ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [pgsql-hackers-win32] [BUGS] More SSL questions..
Magnus Hagander wrote: My feeling is that the *.txt is actually misleading because people will think of it as a file full of freeform text (paragraphs) and not a configuration file. Why would they think that? If notepad tends to auto-wrap files then this argument has some force; I'm not very familar with it though. It does not. There is an option to make it *show* the file with wrapped line, but it does not even have the capability to wordwrap the files themselves. FWIW, I've seen several apps that use .txt for config files, but I can't think of an example right now. Most don't though - .cfg or .conf is probably most common. Except for the majority of windows programs that don't use config files - they use the registry. But I see no reason *at all* for us to want to do that :-) It also more or less requires you to write a GUI to change the config stuff and in that case the file extension becomes irrelevant. Where are we on this? I think Andrew and I both think *.txt is confusing. We need to decide on Monday if we should change the current *.txt names. We can either leave it unchanged, remove *.txt, or change it to *.config. Currently the two Win32 files with *.txt extensions are: APPDATA/postgresql/pgpass.txt APPDATA/postgresql/psqlrc.txt *.txt was added on Win32 to make them automatically start notepad.exe when clicked on. Here is a copy of the Mozilla directory on XP: [.][..] 1138945.s 1138945.w abook.mab bookmarks-1.html bookmarks-2.html bookmarks-3.html bookmarks-4.html bookmarks-5.html bookmarks-6.html bookmarks.html [Cache][Cache.Trash] cert8.db [chatzilla] [chrome] cookies.txtcookperm.txt downloads.rdf history.dathistory.mabhostperm.1 key3.db localstore.rdf [Mail] mailViews.dat mimeTypes.rdf panacea.datpanels.rdf parent.lockprefs.js search.rdf secmod.db URL.tblXUL.mfl There are no *.txt files even though they are all text files. They are not meant to be edited by hand though. I don't have any *.txt files under \Application Data on my machine. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-hackers-win32] [BUGS] More SSL questions..
Bruce Momjian wrote: [.][..] 1138945.s 1138945.w abook.mab bookmarks-1.html bookmarks-2.html bookmarks-3.html bookmarks-4.html bookmarks-5.html bookmarks-6.html bookmarks.html [Cache][Cache.Trash] cert8.db [chatzilla] [chrome] cookies.txtcookperm.txt downloads.rdf history.dathistory.mabhostperm.1 key3.db localstore.rdf [Mail] mailViews.dat mimeTypes.rdf panacea.datpanels.rdf parent.lockprefs.js search.rdf secmod.db URL.tblXUL.mfl There are no *.txt files even though they are all text files. They are Oops, sorry there are two *.txt files for cookies, but most of the configuration files are not *.txt. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 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] [pgsql-hackers-win32] [BUGS] More SSL questions..
Bruce Momjian wrote: Magnus Hagander wrote: My feeling is that the *.txt is actually misleading because people will think of it as a file full of freeform text (paragraphs) and not a configuration file. Why would they think that? If notepad tends to auto-wrap files then this argument has some force; I'm not very familar with it though. It does not. There is an option to make it *show* the file with wrapped line, but it does not even have the capability to wordwrap the files themselves. FWIW, I've seen several apps that use .txt for config files, but I can't think of an example right now. Most don't though - .cfg or .conf is probably most common. Except for the majority of windows programs that don't use config files - they use the registry. But I see no reason *at all* for us to want to do that :-) It also more or less requires you to write a GUI to change the config stuff and in that case the file extension becomes irrelevant. Where are we on this? I think Andrew and I both think *.txt is confusing. We need to decide on Monday if we should change the current *.txt names. We can either leave it unchanged, remove *.txt, or change it to *.config. APPDATA/postgresql/pgpass.txt APPDATA/postgresql/psqlrc.txt Another idea is to use *.conf. We already have: pg_hba.conf pg_ident.conf pg_service.conf postgresql.conf recovery.conf If we want an extension on those two files, it seems *.conf is it, and one hopes they would have already configured XP to pull up their favorite editor for *.conf. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Information Required
Can anyone please tell me where in the source code, I can find the compelte query. -- Regards Imad ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
