[HACKERS] translations
I've been going over the translation again and found 2 places that was broken. In libpq there was some files that was not scanned for translated strings and in scan.l there was a call to gettext() missing which made error messages into a mix of english and swedish (in my case). Normally I just commit the swedish translations, but now I commited these source fixes as well so we get fully translated error messages like: dennis=# SEL; FEL: syntaxfel vid eller nära SEL vid tecken 1 RAD 1: SEL; instead of the previous dennis=# SEL; FEL: syntax error vid eller nära SEL at character 1 RAD 1: SEL; which just looks stupid (in both english and swedish). If there are complains I can revert it and send it to -patches. Overall the translation seems to work fairly well. I have still not got a total translation, but it's getting there. Maybe for 8.1. -- /Dennis Björklund ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] psql questions: SQL, progname, copyright dates
Greg Sabino Mullane wrote: [ There is text before PGP section. ] [ PGP not available, raw data follows ] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg Stark wrote: Well there's always \dtS and \dvS I don't see why typing \dfS is any harder. It would be nice for this to be more visible in the documentation and the \? output though. I've only just found it after months of pulling hair out looking for something just like it Robert Treat replied: Wow you're not kidding. I've been using postgresql for I don't know how many years and I don't think I'd ever noticed that before. ISTM that we can make \df return only user function and \dfS return the system functions, and this would be consitant with how we handle other options. Just make sure to reword \? out put to make it clear that adding S will show system objects. So it seems there are two possible solutions to the problem of segregating user and system objects: change the order by or change the backslash operators. I like the latter way, as it seems consistent with what we already are doing (e.g. \dt \di) How about if we change the rest of the \d operators that support custom objects to support the S option? I would affect the following: \da \dc \dd \df \do \dT I would rewrite the \? docs to make this more clear as well. Agreed it would be nice to more clearly distingush user functions from system ones, but how? I can't see how 'S' is going to help us because \dS already shows system tables. Would it be \dfS? What is the logic to that? Having 'S' be a flag and a command is too confusing. And what about \dn. Seems showing system schemas vs ordinary schemas would make sense too. I wonder if just telling to people focus on the schema name is the best bet. Another idea is to add a flag to skip system stuff like '-', so \df- doesn't show system stuff. Same for the others. That does make sense to me. I know it isn't logical for \d but \d is for storage, while the others are different in that system tables aren't normally accessed by users, while system functions/schemas are. -- 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 8: explain analyze is your friend
Re: [HACKERS] psql questions: SQL, progname, copyright dates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Agreed it would be nice to more clearly distingush user functions from system ones, but how? I can't see how 'S' is going to help us because \dS already shows system tables. Would it be \dfS? What is the logic to that? Having 'S' be a flag and a command is too confusing. Um...it is already there, in the form of \dtS and \diS. This would merely elevate some of the lesser-used system objects (e.g. operators, domains) to the same status as the more common ones (e.g. tables, sequences). And what about \dn. Seems showing system schemas vs ordinary schemas would make sense too. I wonder if just telling to people focus on the schema name is the best bet. Yes, they fall in to my no differentiation pile and would not get a 'S' modifier. Simliarly with casts, tablespaces, users, etc. Another idea is to add a flag to skip system stuff like '-', so \df- doesn't show system stuff. Same for the others. That does make sense to me. I know it isn't logical for \d but \d is for storage, while the others are different in that system tables aren't normally accessed by users, while system functions/schemas are. The minus flag seems a little ugly to me, when we already have an established way of differentiating between the two. Sure, people *access* system functions, but having to look at them through \df seems to be a fairly rare event, I would think. Far more likely they would want to view their own functions. To clarify the 'S' a bit more, here is the output from \? in my new patch: Informational (S = show system objects) \llist all databases (add + for more detail) \d[S] list tables, views, and sequences \d[S] NAMEdescribe table, view, sequence, or index \dt[S] [PATTERN] list tables (add + for more detail) \dv[S] [PATTERN] list views (add + for more detail) \ds[S] [PATTERN] list sequences (add + for more detail) \di[S] [PATTERN] list indexes (add + for more detail) \df[S] [PATTERN] list functions (add + for more detail) \dD[S] [PATTERN] list domains \do[S] [NAME] list operators \da[S] [PATTERN] list aggregate functions \dT[S] [PATTERN] list data types (add + for more detail) \dc[S] [PATTERN] list conversions \db [PATTERN] list tablespaces (add + for more detail) \dC list casts \dd [PATTERN] list objects with comments \dg [PATTERN] list groups \dl list large objects, same as \lo_list \dn [PATTERN] list schemas (add + for more detail) \dp [PATTERN] list table, view and sequence access privileges \du [PATTERN] list users Note that the confusing t|i|v|s|S thing has been broken up, and the S objects are grouped together. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200409090737 -BEGIN PGP SIGNATURE- iD8DBQFBQECGvJuQZxSWSsgRAgG5AJ9EYY1+s42wBsrF+Q2g1Jpu2F+M2wCgvkB0 /prkBWW1Z7Mqc2KRtDyf0vo= =8muz -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] row wise comparison broken
Following result seems strange since it is not what the standard expects: test=# select (1,1) (0,10); ?column? -- f (1 row) On the other hand I see following in the doc: - 9.17.5. Row-wise Comparison (expression [, expression ...]) operator (expression [, expression ...]) Each side is a list of scalar expressions; the two lists must be of the same length. Each side is evaluated and they are compared row-wise. Presently, only = and operators are allowed in row-wise comparisons. - I guess this means that PostgreSQL does not fully support SQL's row-wise comparison. We need to add this to the TODO list? -- Tatsuo Ishii ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] psql questions: SQL, progname, copyright dates
I talked to Greg via chat and it looks like '' is the best choice for adding system object display: \d shows system stuff \df shows system functions etc. Greg is going to work on a patch for 8.1. --- Bruce Momjian wrote: Greg Sabino Mullane wrote: [ There is text before PGP section. ] [ PGP not available, raw data follows ] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg Stark wrote: Well there's always \dtS and \dvS I don't see why typing \dfS is any harder. It would be nice for this to be more visible in the documentation and the \? output though. I've only just found it after months of pulling hair out looking for something just like it Robert Treat replied: Wow you're not kidding. I've been using postgresql for I don't know how many years and I don't think I'd ever noticed that before. ISTM that we can make \df return only user function and \dfS return the system functions, and this would be consitant with how we handle other options. Just make sure to reword \? out put to make it clear that adding S will show system objects. So it seems there are two possible solutions to the problem of segregating user and system objects: change the order by or change the backslash operators. I like the latter way, as it seems consistent with what we already are doing (e.g. \dt \di) How about if we change the rest of the \d operators that support custom objects to support the S option? I would affect the following: \da \dc \dd \df \do \dT I would rewrite the \? docs to make this more clear as well. Agreed it would be nice to more clearly distingush user functions from system ones, but how? I can't see how 'S' is going to help us because \dS already shows system tables. Would it be \dfS? What is the logic to that? Having 'S' be a flag and a command is too confusing. And what about \dn. Seems showing system schemas vs ordinary schemas would make sense too. I wonder if just telling to people focus on the schema name is the best bet. Another idea is to add a flag to skip system stuff like '-', so \df- doesn't show system stuff. Same for the others. That does make sense to me. I know it isn't logical for \d but \d is for storage, while the others are different in that system tables aren't normally accessed by users, while system functions/schemas are. -- 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 8: explain analyze is your friend -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] psql questions: SQL, progname, copyright dates
Bruce Momjian [EMAIL PROTECTED] writes: I talked to Greg via chat and it looks like '' is the best choice for adding system object display: \d shows system stuff Yech, that's awful. It looks ugly and it commandeers a punctuation symbol that we might wish to use for something else someday. I thought the S suggestion was much better than this. Personally I am not unhappy with the existing behavior, because (unlike Greg I guess) I use \df and \do to look at system definitions all the time. However I'm willing to accept \dfS on the grounds of symmetry with the behavior for tables. I don't really want to put up with a less convenient behavior *and* a gratuitously different syntax. 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
[HACKERS] pg_autovacuum and v8.0
Hi, I was thinking that new things will appear in v8.0 about pg_autovacuum ?? But I find nothing new in README and/or Version History Any help ? Regards, -- Hervé Piedvache Elma Ingénierie Informatique 6 rue du Faubourg Saint-Honoré F-75008 - Paris - France Pho. 33-144949901 Fax. 33-144949902 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] pg_autovacuum and v8.0
pg_autovacuum will still be in contrib as of 8.0. It did not make integration with the core distribution. -tfo On Sep 9, 2004, at 11:09 AM, Hervé Piedvache wrote: Hi, I was thinking that new things will appear in v8.0 about pg_autovacuum ?? But I find nothing new in README and/or Version History Any help ? Regards, -- Hervé Piedvache Elma Ingénierie Informatique 6 rue du Faubourg Saint-Honoré F-75008 - Paris - France Pho. 33-144949901 Fax. 33-144949902 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql questions: SQL, progname, copyright dates
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I talked to Greg via chat and it looks like '' is the best choice for adding system object display: \d shows system stuff Yech, that's awful. It looks ugly and it commandeers a punctuation symbol that we might wish to use for something else someday. I thought the S suggestion was much better than this. My problem is that it uses a letter as a modifier, while all other letters are object specifications. '+' is a modifier. We need another modifier that isn't a letter. No one knew \dtS worked because 'S' doesn't look like a modifier. Personally I am not unhappy with the existing behavior, because (unlike Greg I guess) I use \df and \do to look at system definitions all the time. However I'm willing to accept \dfS on the grounds of symmetry with the behavior for tables. I don't really want to put up with a less convenient behavior *and* a gratuitously different syntax. I am also happy with the existing behavior. Another idea is to add a modifier that supresses system functions, etc. I think adding 'S' to \df confuses more than it helps. -- 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] row wise comparison broken
Tatsuo Ishii [EMAIL PROTECTED] writes: I guess this means that PostgreSQL does not fully support SQL's row-wise comparison. We need to add this to the TODO list? I thought it was there already ... certainly this has been discussed before ... regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] pg_autovacuum and v8.0
OK thanks ! Le Jeudi 9 Septembre 2004 18:14, Thomas F.O'Connell a écrit : pg_autovacuum will still be in contrib as of 8.0. It did not make integration with the core distribution. -tfo On Sep 9, 2004, at 11:09 AM, Hervé Piedvache wrote: Hi, I was thinking that new things will appear in v8.0 about pg_autovacuum ?? But I find nothing new in README and/or Version History Any help ? Regards, -- Hervé Piedvache Elma Ingénierie Informatique 6 rue du Faubourg Saint-Honoré F-75008 - Paris - France Pho. 33-144949901 Fax. 33-144949902 -- Hervé Piedvache Elma Ingénierie Informatique 6 rue du Faubourg Saint-Honoré F-75008 - Paris - France Pho. 33-144949901 Fax. 33-144949902 ---(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] psql questions: SQL, progname, copyright dates
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: I thought the S suggestion was much better than this. My problem is that it uses a letter as a modifier, while all other letters are object specifications. '+' is a modifier. We need another modifier that isn't a letter. No one knew \dtS worked because 'S' doesn't look like a modifier. I don't buy that argument in the least. I think the reason people didn't know about S was they didn't RTFM (or possibly that the FM isn't sufficiently clear). Changing to a different character won't make any difference at all, only improving the docs will make a difference. But I could live with using - to suppress system objects. That isn't a character we're likely to want to use as a command metacharacter someday. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] APR 1.0 released
Bruce Momjian wrote: Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I don't understand most of this patch. What difference does changing the preprocessor test order make? I think Bruce was mostly trying to make all the similar tests look alike. Also I agree that if a !b is clearer than if !b a; the latter requires a bit more thought to parse the extent of the ! operator... Right, just consistency. Ok. I understand now. I'm not sure exactly what Bruce checked, so I just spent a few cycles making sure that we did not inadvertantly pick up a define of WIN32 from windows.h anywhere else. I *think* we are OK on that. However, ISTM this is a foot just waiting to be shot - in retrospect using WIN32 as our marker for native Windows, which we do in a great many places (around 300 by my count) was a less than stellar choice, given that it is defined by windows.h, and especially since we use that header for Cygwin as well as for Windows native in a few places. cheers andrew ---(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] APR 1.0 released
Andrew Dunstan [EMAIL PROTECTED] writes: I'm not sure exactly what Bruce checked, so I just spent a few cycles making sure that we did not inadvertantly pick up a define of WIN32 from windows.h anywhere else. I *think* we are OK on that. However, ISTM this is a foot just waiting to be shot - in retrospect using WIN32 as our marker for native Windows, which we do in a great many places (around 300 by my count) was a less than stellar choice, given that it is defined by windows.h, and especially since we use that header for Cygwin as well as for Windows native in a few places. Well, it's easily changed, if all that's needed is a search-and-replace. Suggestions for a better name? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] psql questions: SQL, progname, copyright dates
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: I thought the S suggestion was much better than this. My problem is that it uses a letter as a modifier, while all other letters are object specifications. '+' is a modifier. We need another modifier that isn't a letter. No one knew \dtS worked because 'S' doesn't look like a modifier. I don't buy that argument in the least. I think the reason people didn't know about S was they didn't RTFM (or possibly that the FM isn't sufficiently clear). Changing to a different character won't make any difference at all, only improving the docs will make a difference. But I could live with using - to suppress system objects. That isn't a character we're likely to want to use as a command metacharacter someday. ISTM one problem is we are inconsistent about it - \d and \dt don't show system objects, but \df shows system functions. Reading TFM is a good thing, but so is consistency. '-' isn't a very nice choice, because \df-+ would be really confusing. If you don't like '', then '@' and '!' seem to be at least as free as '-' ;-) cheers andrew ---(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] psql questions: SQL, progname, copyright dates
Andrew Dunstan [EMAIL PROTECTED] writes: ISTM one problem is we are inconsistent about it - \d and \dt don't show system objects, but \df shows system functions. Reading TFM is a good thing, but so is consistency. Well, one of the subarguments here is whether we are going to change the behavior of the table-related \d commands too. If we choose a modifier other than S for \df, I'd be inclined to adopt the same behavior for the table commands. '-' isn't a very nice choice, because \df-+ would be really confusing. If you don't like '', then '@' and '!' seem to be at least as free as '-' ;-) [ shrug ] But '-' has the correct implication that you're removing something. Those other symbols are just arbitrary. I'd like to pick something with at least some mnemonic value. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] translations
On Thu, Sep 09, 2004 at 09:09:31AM +0200, Dennis Bjorklund wrote: I've been going over the translation again and found 2 places that was broken. In libpq there was some files that was not scanned for translated strings and in scan.l there was a call to gettext() missing which made error messages into a mix of english and swedish (in my case). I see this problem too. I was about to complain. Not sure if this is the best fix, but it certainly 'needs fixed'. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) The ability to monopolize a planet is insignificant next to the power of the source ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql questions: SQL, progname, copyright dates
On Thu, Sep 09, 2004 at 11:37:13AM -, Greg Sabino Mullane wrote: To clarify the 'S' a bit more, here is the output from \? in my new patch: Informational (S = show system objects) \llist all databases (add + for more detail) \d[S] list tables, views, and sequences \d[S] NAMEdescribe table, view, sequence, or index \dt[S] [PATTERN] list tables (add + for more detail) While you are it, why not make it Informational (S = show system objects) (+ = show more detail about each object) \l[+]list all databases \d[S]list tables, views, and sequences \d[S][+] NAMEdescribe table, view, sequence, or index \dt[S][+] [PATTERN] list tables Etc? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) No reniegues de lo que alguna vez creíste ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] row wise comparison broken
Tatsuo Ishii [EMAIL PROTECTED] writes: I guess this means that PostgreSQL does not fully support SQL's row-wise comparison. We need to add this to the TODO list? I thought it was there already ... certainly this has been discussed before ... This was discussed (including a possible implementation of the correct behavior) at some length on the performance list a little over a month ago. I don't think it made it to Bruce who probably would have added to the todo list...the consensus was the current behavior is wrong but there were some concerns about backwards compatibility. Merlin ---(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] APR 1.0 released
Tom Lane schrieb: Andrew Dunstan [EMAIL PROTECTED] writes: I'm not sure exactly what Bruce checked, so I just spent a few cycles making sure that we did not inadvertantly pick up a define of WIN32 from windows.h anywhere else. I *think* we are OK on that. However, ISTM this is a foot just waiting to be shot - in retrospect using WIN32 as our marker for native Windows, which we do in a great many places (around 300 by my count) was a less than stellar choice, given that it is defined by windows.h, and especially since we use that header for Cygwin as well as for Windows native in a few places. Well, it's easily changed, if all that's needed is a search-and-replace. Suggestions for a better name? MINGW32 -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(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] psql questions: SQL, progname, copyright dates
Greg Sabino Mullane [EMAIL PROTECTED] writes: To clarify the 'S' a bit more, here is the output from \? in my new patch: This looks nice perhaps do it for + as well? Informational: Modifiers S Show system objects + Additional detail \l[+] list all databases \d[S] list tables, views, and sequences \d[S] NAME describe table, view, sequence, or index \dt[S+] [PATTERN] list tables \dv[S+] [PATTERN] list views \ds[S+] [PATTERN] list sequences \di[S+] [PATTERN] list indexes \df[S+] [PATTERN] list functions \dD[S] [PATTERN] list domains \do[S] [NAME] list operators \da[S] [PATTERN] list aggregate functions \dT[S+] [PATTERN] list data types \dc[S] [PATTERN] list conversions \db[+] [PATTERN] list tablespaces -- greg ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Buffer contents
I wanted to know the contents of the buffer cache in 7.4, so I created
this function and view that seems to work ok:
/* Takes relfilenode (from pg_class) and returns the number of
* buffer cache pages it is using.
*/
PG_FUNCTION_INFO_V1(block_count);
Datum
block_count(PG_FUNCTION_ARGS)
{
Oid relfilenode = PG_GETARG_OID(0);
BufferDesc *buf;
Buffer buffer;
int count = 0;
// 0 is not a valid relfilenode although pg_xactlock
// uses it
if (relfilenode == 0) {
PG_RETURN_INT32(0);
}
for (buffer=1; BufferIsValid(buffer); ++buffer) {
buf = (BufferDescriptors[buffer - 1]);
if (buf-tag.rnode.relNode == relfilenode) {
count ++;
}
}
PG_RETURN_INT32(count);
}
/* Returns the number of buffer cache pages the specified relfilenode
* is using. Using buffer view is probably easier.
*/
CREATE OR REPLACE FUNCTION block_count (oid)
RETURNS integer
LANGUAGE 'C' STABLE STRICT AS '/foo';
/* View to look at how much of the buffer cache different tables are
* currently using.
* Example:
* foo=# select * from buffer limit 10;
* relname| block_count
* ---+-
*foo | 13782
*bar |2575
* ...
* (10 rows)
*/
CREATE OR REPLACE VIEW buffer AS
SELECT * FROM (SELECT relname, block_count(relfilenode) FROM pg_class) t
WHERE block_count 0 ORDER BY block_count DESC;
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
[HACKERS] x86_64 configure problem
On an x86_64 machine I'm finding that I cannot configure --with-python
without the attached patch. Undoubtedly there is a better way to fix
this -- any suggestions?
Another configure issue: I find that --enable-depend breaks parallel builds:
make -j 2
[...]
make[3]: Entering directory
`/opt/src/pgsql-cvs/pgsql-8.0/src/backend/utils/mb/conversion_procs/euc_tw_and_big5'
gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
-Wmissing-declarations -fpic -I../../../../../../src/include
-D_GNU_SOURCE -I/usr/include/et -c -o big5.o big5.c -MMD
gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
-Wmissing-declarations -fpic -I../../../../../../src/include
-D_GNU_SOURCE -I/usr/include/et -c -o euc_tw_and_big5.o
euc_tw_and_big5.c -MMD
mkdir: cannot create directory `.deps': File exists
make[3]: *** [big5.o] Error 1
make[3]: *** Deleting file `big5.o'
make[3]: *** Waiting for unfinished jobs
make[3]: *** Waiting for unfinished jobs
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory
`/opt/src/pgsql-cvs/pgsql-8.0/src/backend/utils/mb/conversion_procs/euc_tw_and_big5'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/opt/src/pgsql-cvs/pgsql-8.0/src/backend/utils/mb/conversion_procs'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/opt/src/pgsql-cvs/pgsql-8.0/src'
make: *** [all] Error 2
Any ideas about how to fix this?
Thanks,
Joe
Index: config/python.m4
===
RCS file: /cvsroot/pgsql-server/config/python.m4,v
retrieving revision 1.7
diff -c -r1.7 python.m4
*** config/python.m4 29 Nov 2003 19:51:17 - 1.7
--- config/python.m4 9 Sep 2004 18:02:13 -
***
*** 25,31
python_version=`${PYTHON} -c import sys; print sys.version[[:3]]`
python_prefix=`${PYTHON} -c import sys; print sys.prefix`
python_execprefix=`${PYTHON} -c import sys; print sys.exec_prefix`
! python_configdir=${python_execprefix}/lib/python${python_version}/config
python_includespec=-I${python_prefix}/include/python${python_version}
if test $python_prefix != $python_execprefix; then
python_includespec=-I${python_execprefix}/include/python${python_version} $python_includespec
--- 25,35
python_version=`${PYTHON} -c import sys; print sys.version[[:3]]`
python_prefix=`${PYTHON} -c import sys; print sys.prefix`
python_execprefix=`${PYTHON} -c import sys; print sys.exec_prefix`
! if test `arch` != x86_64; then
! python_configdir=${python_execprefix}/lib/python${python_version}/config
! else
! python_configdir=${python_execprefix}/lib64/python${python_version}/config
! fi
python_includespec=-I${python_prefix}/include/python${python_version}
if test $python_prefix != $python_execprefix; then
python_includespec=-I${python_execprefix}/include/python${python_version} $python_includespec
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] x86_64 configure problem
On Thu, 2004-09-09 at 11:17, Joe Conway wrote:
On an x86_64 machine I'm finding that I cannot configure --with-python
without the attached patch. Undoubtedly there is a better way to fix
this -- any suggestions?
python_configdir=`${PYTHON} -c from distutils.sysconfig import
get_python_lib as f; import os; print os.path.join(f(plat_specific=1,
standard_lib=1),'config')`
That should work, regardless of the lib directory that Python is
installed to.
(at least it works on my system):
[EMAIL PROTECTED]:~ % py -c from distutils.sysconfig import get_python_lib as
f; import os; print
os.path.join(f(plat_specific=1,standard_lib=1),'config')
/usr/local/lib/python2.3/config
--
Regards,
James William Pye
signature.asc
Description: This is a digitally signed message part
[HACKERS] tablespace question ... pg vs oracle
I have someone that is asking if you can recover some tablespaces in a database, but leave the others online ... apparently its a feature of tablespaces under Oracle ... I could see it for schemas, but sounds like it could cause problems depeending on how you are using tablespaces ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] x86_64 configure problem
On Thu, 2004-09-09 at 12:28, James William Pye wrote: That should work, regardless of the lib directory that Python is installed to. Looking at get_python_lib(), I'm not so sure that I'm correct: if os.name == posix: libpython = os.path.join(prefix, lib, python + get_python_version()) Although, I'm getting a bit confused. I just compiled and installed Python(CVS) configured as: ./configure --prefix=/usr/dev --libdir=/usr/dev/pylib But it didn't install anything in /usr/dev/pylib, as one would expect. It just threw everything in /usr/dev/lib. I even gmake'd distclean to make sure there wasn't some configure option cache of some sort. Same thing. ISTM that Python's libdir wasn't meant to be located anywhere other than EPREFIX/lib. -- Regards, James William Pye signature.asc Description: This is a digitally signed message part
Re: [HACKERS] x86_64 configure problem
James William Pye wrote:
Looking at get_python_lib(), I'm not so sure that I'm correct:
It does seem to work for me:
# python -c from distutils.sysconfig import get_python_lib as f; import
os; print os.path.join(f(plat_specific=1,standard_lib=1),'config')
/usr/lib64/python2.3/config
Any other proposals? If not, any objections to the attached patch?
Joe
Index: config/python.m4
===
RCS file: /cvsroot/pgsql-server/config/python.m4,v
retrieving revision 1.7
diff -c -r1.7 python.m4
*** config/python.m4 29 Nov 2003 19:51:17 - 1.7
--- config/python.m4 9 Sep 2004 20:28:14 -
***
*** 25,31
python_version=`${PYTHON} -c import sys; print sys.version[[:3]]`
python_prefix=`${PYTHON} -c import sys; print sys.prefix`
python_execprefix=`${PYTHON} -c import sys; print sys.exec_prefix`
! python_configdir=${python_execprefix}/lib/python${python_version}/config
python_includespec=-I${python_prefix}/include/python${python_version}
if test $python_prefix != $python_execprefix; then
python_includespec=-I${python_execprefix}/include/python${python_version} $python_includespec
--- 25,31
python_version=`${PYTHON} -c import sys; print sys.version[[:3]]`
python_prefix=`${PYTHON} -c import sys; print sys.prefix`
python_execprefix=`${PYTHON} -c import sys; print sys.exec_prefix`
! python_configdir=`${PYTHON} -c from distutils.sysconfig import get_python_lib as f; import os; print os.path.join(f(plat_specific=1,standard_lib=1),'config')`
python_includespec=-I${python_prefix}/include/python${python_version}
if test $python_prefix != $python_execprefix; then
python_includespec=-I${python_execprefix}/include/python${python_version} $python_includespec
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Supporting Encryption in Postgresql
For our research project, I need to implement an encryption support for Postgressql. At this current phase, I need to at least support page level encryption In other words, each page that belongs to a certain sensitive table will be stored encrypted on the harddisk. Since we are trying to have a new design that can start the decryption before even we see the data, I need to have some kind of thread support. My questions are in order to support page level encryption(i,e encrypt each page before writing back to disk and decrypt each page after we read from disk.) which parts of the code should be changed? Our more simply, is /src/backend/storage/smgr/md.c the only code that does the disk access? Since our design requires thread support (we will do some of the decryption, before we see the data, therefore during disk access, we need to continue decryption) Can you suggest me a good thread lib you think will work fine with postgresql ? Thanks for your help. Murat Kantarcioglu, PhD Candidate, Computer Science Department, Purdue University ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Clarification of action on Delete
I've just been asked to clarify what actually happens when a DELETE takes place, and what happens to TOASTed data. The MVCC never-update-in-place phrase caused some debate over what happens. I couldn't find a specific and conclusive comment on this that I trust to be completely up to date. One may exist however? My answer was this, though this was not thought accurate (on the DELETE aspect): For DELETEs, the xmax field on the tuple/row header is updated-in-place to show the xid that deleted the row. Thus, DELETEs of long data rows are just as efficient as DELETEs of shorter data rows, since both effect only a single data page. This still allows concurrent access because only one backend may hold the page lock at any time, so nobody is actively reading the row at the time of the setting of xmax for the DELETE. MVCC uses a never-update-in-place algorithm to allow concurrency during UPDATEs. In general, the whole row is re-written, just as if the data had been DELETEd and then re-INSERTed. If there are TOASTed fields, then the TOASTed data is only re-written if it is has changed as part of the UPDATE. Thus an UPDATE of a row with TOASTed data, yet that doesn't alter the TOASTed data itself, is no more expensive than an UPDATE of a shorter row, since it will change only one page (with an equal risk of requiring a new block write as a result of the insertion of the new main row version). DELETE does NOT take a full copy of the row and THEN mark the xmax field as the xid of the deleting transaction, so is NOT similar to an UPDATE action on the same row. I've checked heapam.c and tuptoaster.c, and think this is correct. Any differing views? If possible, please refer me to the code - I'm still working my way around the heap access code, so feel free to show me the light... Best regards, Simon Riggs ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Supporting Encryption in Postgresql
On R, 2004-09-10 at 00:03, Murat Kantarcioglu wrote: My questions are in order to support page level encryption(i,e encrypt each page before writing back to disk and decrypt each page after we read from disk.) which parts of the code should be changed? Our more simply, is /src/backend/storage/smgr/md.c the only code that does the disk access? Since our design requires thread support (we will do some of the decryption, before we see the data, therefore during disk access, we need to continue decryption) Why do you think that you need threads to do the (en/de)cryption? Why is it not sufficient to just replace the page read/write functions with ones supporting encryption ? Or just use encrypted filesystem ;) evil grin - Hannu ---(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] Clarification of action on Delete
Simon Riggs [EMAIL PROTECTED] writes: I've just been asked to clarify what actually happens when a DELETE takes place, and what happens to TOASTed data. What does this have to do with x86_64 configure problem? -- greg ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] translations
On Thu, 9 Sep 2004, Alvaro Herrera wrote: In libpq there was some files that was not scanned for translated strings and in scan.l there was a call to gettext() missing which made error messages into a mix of english and swedish (in my case). I see this problem too. I was about to complain. Not sure if this is the best fix, but it certainly 'needs fixed'. Since the parser calls yyerror() with strings we can't do the gettext call beforehand, which only leaves it to be done inside the yyerror() function. xgettext sees yyerror as a markup functions, so the strings generated by the parser are all in the po file (but was not used since there was no call to gettext). -- /Dennis Björklund ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Clarification of action on Delete
Simon Riggs [EMAIL PROTECTED] writes: My answer was this, though this was not thought accurate (on the DELETE aspect): This is correct as far as it goes, but given the question I imagine some further detail is appropriate: * When deleting a row that has out-of-line-toasted fields, we must also find the TOAST row(s) for those fields and mark them deleted. So it is not strictly true that deleting a wide row has the same cost as deleting a narrow one: you will have to touch all the pages containing TOAST data as well. * UPDATE is indeed basically equivalent to a DELETE and INSERT, with the sole optimization being that we carry over any unchanged toasted fields. So in particular, any changed toasted fields will need to be marked deleted in the TOAST table. It would be nice to push the TOAST deletions off to become the responsibility of VACUUM, but I'm not entirely sure how to do that without giving up the UPDATE optimization of shared values. 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] Clarification of action on Delete
Tom Lane wrote Simon Riggs [EMAIL PROTECTED] writes: My answer was this, though this was not thought accurate (on the DELETE aspect): This is correct as far as it goes, but given the question I imagine some further detail is appropriate: * When deleting a row that has out-of-line-toasted fields, we must also find the TOAST row(s) for those fields and mark them deleted. So it is not strictly true that deleting a wide row has the same cost as deleting a narrow one: you will have to touch all the pages containing TOAST data as well. * UPDATE is indeed basically equivalent to a DELETE and INSERT, with the sole optimization being that we carry over any unchanged toasted fields. So in particular, any changed toasted fields will need to be marked deleted in the TOAST table. Thanks! It would be nice to push the TOAST deletions off to become the responsibility of VACUUM, but I'm not entirely sure how to do that without giving up the UPDATE optimization of shared values. That could be optimised, but there are advantages to removing TOASTed values immediately since they are potentially big space hogs, so I'm actually glad to hear that it works that way. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] psql questions: SQL, progname, copyright dates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While you are it, why not make it Informational (S = show system objects) (+ = show more detail about each object) \l[+]list all databases \d[S]list tables, views, and sequences \d[S][+] NAMEdescribe table, view, sequence, or index Very good idea. I guess I am once again in the 'S' camp, after a brief foray into '' land. Sorry, Bruce! :) I'll keep working on the patch when I have the time. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200409091808 -BEGIN PGP SIGNATURE- iD8DBQFBQNScvJuQZxSWSsgRAv5JAKC9uvu+SZ6vszLhe3sytjUby9cgRACfaW2v BVJ2JcLzpJi8hp47tdh16gw= =GrSh -END PGP SIGNATURE- ---(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] Clarification of action on Delete
Simon Riggs [EMAIL PROTECTED] writes: Tom Lane wrote It would be nice to push the TOAST deletions off to become the responsibility of VACUUM, but I'm not entirely sure how to do that without giving up the UPDATE optimization of shared values. That could be optimised, but there are advantages to removing TOASTed values immediately since they are potentially big space hogs, so I'm actually glad to hear that it works that way. Well, they certainly aren't going to be *removed* immediately; we couldn't roll back the deletion if we did. The physical removal will happen during VACUUM, same as for ordinary table rows. So there's not really any functional reason why we couldn't have VACUUM do the marking for removal too, except that it does not know when looking at the deleted table row whether the toast entries are shared with other versions of the row. 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] row wise comparison broken
Tatsuo Ishii [EMAIL PROTECTED] writes: I guess this means that PostgreSQL does not fully support SQL's row-wise comparison. We need to add this to the TODO list? I thought it was there already ... certainly this has been discussed before ... This was discussed (including a possible implementation of the correct behavior) at some length on the performance list a little over a month ago. I don't think it made it to Bruce who probably would have added to the todo list...the consensus was the current behavior is wrong but Yes, I found the following thread started by you in the pgsql-performance list: Subject: [PERFORM] best way to fetch next/prev record based on index Date: Tue, 27 Jul 2004 06:18:43 -0700 there were some concerns about backwards compatibility. IMO 8.0 is a good chance to fix it. Maybe we could add a GUC switch to fall back to pre-8.0 behavior... -- Tatsuo Ishii ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Supporting Encryption in Postgresql
Murat, For our research project, I need to implement an encryption support for Postgressql. At this current phase, I need to at least support page level encryption In other words, each page that belongs to a certain sensitive table will be stored encrypted on the harddisk. Are you planning on doing the decryption on the back-end, or on the client? It certainly seems to me that doing it on the client would make more sense; if the data is decrypted on the back-end, then you will still need the overhead of an SSL connection. In any case, I'm glad that you're looking into this; encryption-on-disk is one of those missing features that we might never have gotten around to as a project ... -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(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] Supporting Encryption in Postgresql
Paul Tillotson [EMAIL PROTECTED] writes: Given that the client does not write pages to the disk, this would be back-end encryption. Just out of curiosity, what threat model does this sort of encryption protect against? Surely any attacker who can read the files off the disk can also get the password used to encrypt them. Or would this be provided by the client and kept in RAM only? If I have root- or postgres-level access to the machine, I can snarf the encryption key out of RAM even if it's never written to disk. I don't see what this (backend page-level encryption) would buy you over just using an encrypted partition, which is already available on most OSs... -Doug -- Let us cross over the river, and rest under the shade of the trees. --T. J. Jackson, 1863 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Supporting Encryption in Postgresql
Murat Kantarcioglu wrote: For our research project, I need to implement an encryption support for Postgressql. At this current phase, I need to at least support page level encryption In other words, each page that belongs to a certain sensitive table will be stored encrypted on the harddisk. Since we are trying to have a new design that can start the decryption before even we see the data, I need to have some kind of thread support. I have to say that this is becoming an important problem in the European market. In Italy for example the law impose that if you store personal data about your customers then this information shall be stored in an encrypted form. The bast way I found to accomplish this is using an encrypted file system. Google for cryptoloop or if you are brave enough look for StegFS. Regards Gaetano Mendola ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] x86_64 configure problem
Joe Conway wrote: James William Pye wrote: Looking at get_python_lib(), I'm not so sure that I'm correct: It does seem to work for me: # python -c from distutils.sysconfig import get_python_lib as f; import os; print os.path.join(f(plat_specific=1,standard_lib=1),'config') /usr/lib64/python2.3/config Any other proposals? If not, any objections to the attached patch? No one, we have to check also for the presence of distutils package installation. It's not installed by default and I was bitten by it during the RPM building for RH AS 2.1 Regards Gaetano Mendola ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Clarification of action on Delete
Greg Stark wrote: Simon Riggs [EMAIL PROTECTED] writes: I've just been asked to clarify what actually happens when a DELETE takes place, and what happens to TOASTed data. What does this have to do with x86_64 configure problem? I believe this was a new thread but Outlook or the new server had a glitch. Regards Gaetano Mendola ---(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] Clarification of action on Delete
On Fri, Sep 10, 2004 at 02:10:08AM +0200, Gaetano Mendola wrote: Greg Stark wrote: Simon Riggs [EMAIL PROTECTED] writes: I've just been asked to clarify what actually happens when a DELETE takes place, and what happens to TOASTed data. What does this have to do with x86_64 configure problem? I believe this was a new thread but Outlook or the new server had a glitch. No, Simon used another thread. The Reply-To: header was present. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Uno combate cuando es necesario... ¡no cuando está de humor! El humor es para el ganado, o para hacer el amor, o para tocar el baliset. No para combatir. (Gurney Halleck) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql questions: SQL, progname, copyright dates
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: ISTM one problem is we are inconsistent about it - \d and \dt don't show system objects, but \df shows system functions. Reading TFM is a good thing, but so is consistency. Well, one of the subarguments here is whether we are going to change the behavior of the table-related \d commands too. If we choose a modifier other than S for \df, I'd be inclined to adopt the same behavior for the table commands. '-' isn't a very nice choice, because \df-+ would be really confusing. If you don't like '', then '@' and '!' seem to be at least as free as '-' ;-) [ shrug ] But '-' has the correct implication that you're removing something. Those other symbols are just arbitrary. I'd like to pick something with at least some mnemonic value. One question is whether we want to suppress system functions by default in \df. From my perspective, the issue is whether we would use those objects in normal application queries. Clearly we would use system functions in application queries, so we display them. (We might be able to suppress display of interally called functions if we still display them). We don't refer to system tables in normal application queries so it makes sense we don't display them by default. As far as the symbol, I think we should keep letters as object specifiers and not use 'S' to mean system. The idea for '' was to say and system objects, and if we go for an options to supress system objects, '-' seems best. I don't imagine people using -+ very often. -- 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 8: explain analyze is your friend
Re: [HACKERS] [BUGS] 8.0.0beta1: Ownership of implicit sequences after dump/restore
Added to open items list:
* fix permissions on sequences restored via pg_dump
---
Michael Fuhr wrote:
PostgreSQL version: 8.0.0beta1
Operating system : Solaris 9
Backups created by pg_dump/pg_dumpall don't set the ownership of
implicitly-created sequences. When backups are restored, users who
created sequences may not be able to use them.
How to repeat:
1. Create a test user and a test database.
createuser -P -Upostgres testuser
Enter password for new user:
Enter it again:
Shall the new user be allowed to create databases? (y/n) n
Shall the new user be allowed to create more new users? (y/n) n
createdb -Upostgres testdb
2. Connect to the test database as the test user, create explicit
and implicit sequences, then list the sequences.
psql -Utestuser testdb
CREATE SEQUENCE test_seq;
CREATE TABLE stuff (id SERIAL PRIMARY KEY, name TEXT NOT NULL);
\ds
List of relations
Schema | Name | Type | Owner
+--+--+--
public | stuff_id_seq | sequence | testuser
public | test_seq | sequence | testuser
(2 rows)
3. Make a backup of the test database.
pg_dump -Upostgres testdb backup.sql
4. Drop the test database.
dropdb -Upostgres testdb
5. Recreate the test database and restore it.
createdb -Upostgres testdb
psql -Upostgres -f backup.sql testdb
6. Connect to the test database as the test user, show the sequences,
and try to use the implicitly-created one.
psql -Utestuser testdb
\ds
List of relations
Schema | Name | Type | Owner
+--+--+--
public | stuff_id_seq | sequence | postgres
public | test_seq | sequence | testuser
(2 rows)
SELECT nextval('stuff_id_seq');
ERROR: permission denied for sequence stuff_id_seq
pg_dump sets the ownership of the explicitly-created sequence via
an ALTER TABLE statement (I see ALTER SEQUENCE ... OWNER TO on the
TODO list):
ALTER TABLE public.test_seq OWNER TO testuser;
No such statement is issued for the implicitly-created sequence,
resulting in the sequence being owned by the user who restored the
database. This would typically be a database superuser.
Is this a bug in pg_dump/pg_dumpall, or is it a bug in the ALTER
TABLE ... OWNER TO statement that set the ownership of the table
that implicitly created the sequence? It seems reasonable that
changing a table's ownership should also change the ownership of
any implicitly-created sequences, or has that already been discussed
and rejected?
Thanks.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
---(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
--
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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] APR 1.0 released
Andrew Dunstan wrote: I think Bruce was mostly trying to make all the similar tests look alike. Also I agree that if a !b is clearer than if !b a; the latter requires a bit more thought to parse the extent of the ! operator... Right, just consistency. Ok. I understand now. I'm not sure exactly what Bruce checked, so I just spent a few cycles making sure that we did not inadvertantly pick up a define of WIN32 from windows.h anywhere else. I *think* we are OK on that. However, ISTM this is a foot just waiting to be shot - in retrospect using WIN32 as our marker for native Windows, which we do in a great many places (around 300 by my count) was a less than stellar choice, given that it is defined by windows.h, and especially since we use that header for Cygwin as well as for Windows native in a few places. The use of WIN32 was because it usually does mean MinGW and Cygwin. We had lots of Cygwin-specific defines in there already so Win32 just means both Mingw and Cygwin. You will see only a few cases where we want Mingw and not Cygwin, but in those case we often also want MSVC and Borland, so it really is WIN32 ! __CYGWIN__. We do have one or two tests for __MINGW32__ where we really do want just that. Would you look around and see if this can be improved. I can't see any. -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] psql questions: SQL, progname, copyright dates
On Thursday 09 September 2004 21:30, Bruce Momjian wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
ISTM one problem is we are inconsistent about it - \d and \dt don't
show system objects, but \df shows system functions. Reading TFM is a
good thing, but so is consistency.
Well, one of the subarguments here is whether we are going to change the
behavior of the table-related \d commands too. If we choose a modifier
other than S for \df, I'd be inclined to adopt the same behavior for the
table commands.
'-' isn't a very nice choice, because \df-+ would be really confusing.
If you don't like '', then '@' and '!' seem to be at least as free as
'-' ;-)
[ shrug ] But '-' has the correct implication that you're removing
something. Those other symbols are just arbitrary. I'd like to pick
something with at least some mnemonic value.
One question is whether we want to suppress system functions by default
in \df. From my perspective, the issue is whether we would use those
objects in normal application queries. Clearly we would use system
functions in application queries, so we display them. (We might be able
to suppress display of interally called functions if we still display
them). We don't refer to system tables in normal application queries so
it makes sense we don't display them by default.
FWIW in phppgadmin we do suppress system functions by default and I can't
recall anyone ever asking us to do otherwise. Its actually one of the
reasons I use phppgadmin, because when trying to work through complex
function code, having all of the system functions is just to cumbersome.
As far as the symbol, I think we should keep letters as object
specifiers and not use 'S' to mean system. The idea for '' was to say
and system objects, and if we go for an options to supress system
objects, '-' seems best. I don't imagine people using -+ very often.
Ugh. If I want to see the syntax of my functions, I'd be forced to use the
\df-+ syntax, and I'd argue people spend far more time wanting to see \df+
output on their own functions than they ever do on system functions.
imho the argument against \dfS is pretty weak. Letters are not only used as
object specifiers, they are also used for setting field separators, html
output, switching to and from expanded output, and listing table access
permissions, among other things. Telling folks that the S modifier is for
system objects mnemonic, simple, and FWIW keeps with backward compatability.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] row wise comparison broken
Tatsuo Ishii wrote: Tatsuo Ishii [EMAIL PROTECTED] writes: I guess this means that PostgreSQL does not fully support SQL's row-wise comparison. We need to add this to the TODO list? I thought it was there already ... certainly this has been discussed before ... This was discussed (including a possible implementation of the correct behavior) at some length on the performance list a little over a month ago. I don't think it made it to Bruce who probably would have added to the todo list...the consensus was the current behavior is wrong but Yes, I found the following thread started by you in the pgsql-performance list: Subject: [PERFORM] best way to fetch next/prev record based on index Date: Tue, 27 Jul 2004 06:18:43 -0700 there were some concerns about backwards compatibility. IMO 8.0 is a good chance to fix it. Maybe we could add a GUC switch to fall back to pre-8.0 behavior... I remember the thread but didn't see a TODO in there at the time. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] row wise comparison broken
Bruce Momjian [EMAIL PROTECTED] writes: I remember the thread but didn't see a TODO in there at the time. * Make row-wise comparisons work per SQL spec regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
