Re: [HACKERS] PostgreSQL configuration
Bruce Momjian wrote: Let me tell you the compromise I thought of. First, we put the config files (postgresql.conf, pg_hba.conf, pg_ident.conf) in data/etc by default. Sorry Bruce, I was being slow :-) , I was thinking you were going to associate the config files with the binary distribution - I think I now realize that you were looking at pushing them down into $PGDATA/etc, which is quite nice and tidy. best wishes Mark ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL configuration
[EMAIL PROTECTED] wrote: ii) I think the -C switch *WITH* the -D switch has viable usability. Consider this, you are testing two different database layouts and/or RAID controllers. You could easily bounce back and forth from *identical* configurations like this: Convenient indeed, but I would like to see the association of .conf file - data dir remain reasonably solid. Its all about the foot gun. iii) I don't like the PID file at all. Not one bit, but I had a few people ask for it in the patch, it works as advertized and expected. It isn't my place to say how someone should use something. One of my customers wanted it, so I provided them with it. That is the beauty of open source. I think that there is a difference between a special patch suitable for a particular customer and general release, and that maybe this addition falls right in there. best wishes Mark ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL configuration
Tom Lane wrote: I think if you spelled the subdir name config rather than etc, it would be more obvious what's what. How about 'conf' - (familiar to anyone who has used apache or tomcat ) regards Mark ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] sql92 character sets
For my own amusement I'm reading the sql 92 spec about character sets. There are some concepts that are a bit difficult that maybe someone can explain for me: character set character repertoire for example in 4.2.1 it says: A character set is described by a character set descriptor. A character set descriptor includes: - the name of the character set or character repertoire, - if the character set is a character repertoire, then the name of the form-of-use, - an indication of what characters are in the character set, and - the name of the default collation of the character set. What I have understod so far is that form-of-use is the encoding. So if the character set is UNICODE then the form-of-use could be UTF-8, UTF-16 and so on. The character repertoire however I don't have an intuition about it all. Then we have this little section: The implementation-defined character repertoire name SQL_TEXT specifies the name of a character repertoire and implied form-of- use that can represent every character that is in SQL language character and all other characters that are in character sets supported by the implementation. Had unicode been a superset of all character sets, then one could just have used unicode for SQL_TEXT. Exactly how do we create a character repertoire that can store any character from any character set.. Storing the character set for each character is not such a cool thing to do even if it would work :-) SQL_ASCII in pg is similar, it's basically a number of bytes. But the spec seems to say that one should be able to count the characters as well (not the bytes) so SQL_ASCII is not the same as SQL_TEXT. ps. This is not me volunteering to implement all this :-) -- /Dennis Björklund ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] make == as = ?
Dear Josh, Thanks for you reply at length. It helps me understand the raw about my suggestion. Some short comments and joke signs: Adding == would cause harm in the following three ways: 1) It would impair portability between PostgreSQL and other databases that support the SQL standard. Oracle, M$ and others spend a lot of energy so that what you write for their tool won't be so easilly portable, thus once you've started with them, you'll stay forever. You're arguing that pg should help its customers to leave it easilly, what is quite paradoxical! ;-) 3) It would, in my opinion, confuse Java and C coders I have different classes, and not all classes would be elligible to a '==' for '=' shorthand (well, I should write long-hand as it is longer;-). So I partially aggree with your opinion. Your Java students would be lulled into a false sense of understanding out of the belief that == in PostgreSQL would work exactly like == in Java ... when it wouldn't work the same in corner cases. For the class I have in mind, there are no corner cases, just concepts and basic practice. They are not going to be db developers, not even computer professionnals for most of them. I want them to remember that there is something beside word, powerpoint and excel;-) Finally, when your students leave your classroom and need to write a program that interfaces with Oracle or SQL Server, then what? They'll look at their notebooks from class and try the examples, and get a syntax error. Sure. They should have used postgresql ;-) From my perspective, it is better to teach a student nothing at all than to teach them something which is wrong. Formation is what you need to get a job. Education is what you need as a human being. We need both... Have a nice day, -- Fabien Coelho - [EMAIL PROTECTED] ---(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] user-defined default public acl
sorry, I resend this as I have not received it from the list, and it does
not appear in the archives...
Dear Tom,
defaults in src/backend/utils/adt/acl.c.
I'm unconvinced that this is a good idea.
Hmmm.
In the first place I am unsure what sorts of surprising behaviors might
result from nontraditional defaults for these ACL settings.
Sure, this should be thought of.
(I find the precedent of umask 077 unconvincing because a Unix
filesystem only deals with two kinds of objects, files and directories,
with not-so-different protection behaviors. I don't know that that
scales up to SQL.)
I wouldn't want default rights for different objects to be mixed.
Also, it is about public rights, that is other wrt unix umask.
public means anybody, and my opinion is that anybody should not
be given anything implicitly.
Also, I'm afraid that empty acl arrays (from what is seen from acl fields
when dumping pg_database or other tables) have a meaning at the time,
which is default... this may interact with new user-defined defaults.
Yup, it would, and that strikes me as another fertile place for problems.
You will have to make some basic changes in the way that default ACLs
are handled, or else such a feature would introduce security holes.
Sure.
I'm not sure how much user-facing behavior would have to change, but
I doubt it could be a completely transparent change.
Should be investigated.
Another area to think about is the implications for pg_dump, and
especially the implications for reloading existing dump scripts.
If the postgresql.conf settings for default ACLs are nonstandard,
wouldn't that result in reloaded objects acquiring different ACLs
than they had before? Is that a good idea?
Well, I thought that pg_dump/restore would restore anything, including
ACL. However, if some assumptions are made about default ACL this
may be an issue.
Before buying into all this, it would be nice to see a better rationale
than this surprised me and it's easy to fix. The latter at least is
wrong.
For the former, I mean that I'm used to create something that has no
rights to other people by default. Then I give the rights I want, and if
I don't give anything, then nothing is given by default. That's my
idea of security by default.
The current status with postgresql is that some rights are given by
default, so I have to fix everything by hand with revoke (I'm pretty
sure I'll forget something) and then grant what I want. I'll never
grant anything to public, but rather to some groups.
As I can't and don't want to make all people share my point of view, I
would need some parametrizable default setting, so that I can at least
share my point of view with myself;-)
Also maybe the default may be different and still hardwired for system
stuffs.
A still better fix for me would be that default public rights are the
most restrictive, as some comments suggest it could be the case:
case ACL_OBJECT_FUNCTION:
/* Grant EXECUTE by default, for now */
^^^
world_default = ACL_EXECUTE;
...
case ACL_OBJECT_LANGUAGE:
/* Grant USAGE by default, for now */
world_default = ACL_USAGE;
The patch would be quick;-)
Have a nice day,
--
Fabien COELHO _ http://www.cri.ensmp.fr/~coelho _ [EMAIL PROTECTED]
CRI-ENSMP, 35, rue Saint-Honoré, 77305 Fontainebleau cedex, France
phone: (+33|0) 1 64 69 {voice: 48 52, fax: 47 09, standard: 47 08}
All opinions expressed here are mine _
---(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] rotatelogs integration in pg_ctl
quote who=Andrew Hammond Tom Lane wrote: Andrew Hammond [EMAIL PROTECTED] writes: I've attached a patch for pg_ctl which integrates the Apache project's rotatelogs for logging. Why bother? You just pipe pg_ctl's output to rotatelogs and you're done. It's not difficult to do, once you know how and once you know that there aren't any gotchas. However, the question comes up often enough it's clear that not everybody knows how. This provides a simple, clean, standardized way of using rotatelog. The patch is simple, low risk, and limited impact. So, why not? Is there a reason the postmasters cannot just close/reopen-recreate the log file when a SIGHUP or other signal is issued like apache? This would allow for almost any scheme for log rotation to be handled by the system or third party like logrotate and removes any duplicate effort between projects. I know on most distributions /var/log is not world writeable, so renaming and and opening a file as postgres will not succeed. If the log files are put in, for example, /var/log/pgsql with pgsql being rwx by postgres, then it will work. The current packaging may need to be redone if you want to enable loggin by default (if only startup and shutdown messages) ---(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] make == as = ?
On Tue, 13 Apr 2004, Fabien COELHO wrote: Your Java students would be lulled into a false sense of understanding out of the belief that == in PostgreSQL would work exactly like == in Java ... when it wouldn't work the same in corner cases. For the class I have in mind, there are no corner cases, just concepts and basic practice. They are not going to be db developers, not even computer So no string comparisons? I know that's a mostly unused corner case and all, but... ;) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] rotatelogs integration in pg_ctl
On Tue, Apr 13, 2004 at 09:33:42 -0500, Thomas Swan [EMAIL PROTECTED] wrote: Is there a reason the postmasters cannot just close/reopen-recreate the log file when a SIGHUP or other signal is issued like apache? This would allow for almost any scheme for log rotation to be handled by the system or third party like logrotate and removes any duplicate effort between projects. Wouldn't that break logs piped to a program? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] rotatelogs integration in pg_ctl
Thomas Swan wrote: Is there a reason the postmasters cannot just close/reopen-recreate the log file when a SIGHUP or other signal is issued like apache? Yes, because there is no log file. The postmaster writes to stdout or stderr. ---(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] make == as = ?
Dear Stephan, For the class I have in mind, there are no corner cases, just concepts and basic practice. They are not going to be db developers, not even computer So no string comparisons? I know that's a mostly unused corner case and all, but... ;) They survive to the idea that text/date/... are basic types in SQL. Maybe I'm lucky... they could prefer java references with new/equals...;-) If I take your example about details of vs AND semantics, while teaching programming concepts I'm not going to discuss the fact that is shortcut by the evaluator, as this is very specific. I'm not planing my students to know what i=++i+i++; could mean. If I teach about java/c/c++/java, this may be an issue. So it depends on the course goal. Well, I'm happy that so many people have ideas about what to teach and how to teach it;-) Have a nice day, -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] sql92 character sets
Dennis Bjorklund wrote: What I have understod so far is that form-of-use is the encoding. So if the character set is UNICODE then the form-of-use could be UTF-8, UTF-16 and so on. Exactly. The character repertoire however I don't have an intuition about it all. A character repertoire is basically an abstract bag of characters (say, a to z or all modern greek characters) that you plan to represent using a character set. In SQL 99, this terminology was altered a little (unfortunately not quite compatibly). There, a character repertoire is an abstract set of characters whose internal representation is irrelevant. Add to that an encoding (how to convert characters to bits) and a form-of-use (how to assemble characters into a string (for stateful encodings?, endianness?)), and that together makes a character set. And then they say that character repertoire and character set are used interchangeably except where communication with external systems is concerned. The only real consequence of this difference is that character strings of the same repertoire but possibly using different encodings/forms-of-use should still be comparable or assignable. But that should only concern us if we allowed different character sets per datum and we actually had cases of different encodings for the same repertoire. Had unicode been a superset of all character sets, then one could just have used unicode for SQL_TEXT. Exactly how do we create a character repertoire that can store any character from any character set.. Storing the character set for each character is not such a cool thing to do even if it would work :-) Actually that's exactly what Mule Internal Code does. SQL_ASCII in pg is similar, it's basically a number of bytes. But the spec seems to say that one should be able to count the characters as well (not the bytes) so SQL_ASCII is not the same as SQL_TEXT. SQL_ASCII is a kludge, albeit a practical one. We should not design further extensions around it. ---(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] make == as = ?
Fabien, You're arguing that pg should help its customers to leave it easilly, what is quite paradoxical! ;-) grin If we're going to embrace and extend, we need more market share first. ;-) -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] make == as = ?
Dear Stephan, For the class I have in mind, there are no corner cases, just concepts and basic practice. They are not going to be db developers, not even computer So no string comparisons? I know that's a mostly unused corner case and all, but... ;) They survive to the idea that text/date/... are basic types in SQL. Maybe I'm lucky... they could prefer java references with new/equals...;-) If I take your example about details of vs AND semantics, while teaching programming concepts I'm not going to discuss the fact that is shortcut by the evaluator, as this is very specific. I'm not planing my students to know what i=++i+i++; could mean. And I wouldn't expect that in a programming concepts course. But, if you're going to (for example) say that, preincrement and postincrement work exactly as in C, you've got to realize that there's a chance a student will know that the i++ + ++i is undefined and expect it to be undefined in the language you're talking about. That's the problem with using shorthand phrases like exactly in X without the except ... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Lexing with different charsets
I've spent some more time reading specs today. Together with Peter E's explanataion (Thanks!) I think I've got a farily good understanding of the parts talking about locales now. My next question is about lexing. The spec says that one can use strings of different charsets in the queries, like: ... WHERE field1 = _latin1'FooBar' and field2 = _utf8'Åäö' I can see that the lexer either needs to be taught about all the different charsets or this is not going to work very well. What if one wants to include a string in utf-16 in the query, the lexer can not handle that without understanding utf-16. The query can also be in different charsets. If it's in utf-8 for example, then we can not embed latin1 strings and still have a validating utf-8 query. With the above we can not think of the query as being in a single charset anymore. That's strange but okay I guess. The new wire protocol allows us to send data seperatly from the query which is nice, but the standard talked about strings as above so it's not a solution to the problem. Maybe I should have adressed this to Peter directly :-) -- /Dennis Björklund ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] unsubscribe
unsubscribe ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] FRONTEND in ecpg
Hi! Is there any reason why FRONTEND is not specified in the ecpg build (specifically the pgtypeslib)? I'm running into build problems because it pulls backend-specific stuff from port.h in (postgres_fe.h-c.h-port.h) when tweaking the timezone code. Or should FRONTEND perhaps even be explicitly #defined in postgres_fe.h? Or am I misunderstanding what FRONTEND is for? //Magnus ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] rotatelogs integration in pg_ctl
quote who=Peter Eisentraut Thomas Swan wrote: Is there a reason the postmasters cannot just close/reopen-recreate the log file when a SIGHUP or other signal is issued like apache? Yes, because there is no log file. The postmaster writes to stdout or stderr. Ok, my misunderstanding. stdout/stderr are redirected to a file on startup. This is why when I move/rename the logfile I have to stop/start postgresql to start appending to the empty file. Would there be any interest in modifying postmaster to support native file logging in addition to stderr and stdout output? Are there any terrible drawbacks that you could foresee? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Lexing with different charsets
Dennis Bjorklund [EMAIL PROTECTED] writes: My next question is about lexing. The spec says that one can use strings of different charsets in the queries, like: ... WHERE field1 = _latin1'FooBar' and field2 = _utf8'Åäö' I can see that the lexer either needs to be taught about all the different charsets or this is not going to work very well. Yeah. I'm not sure that we're ever going to support that part of the spec; doing so would break too many useful things without adding very much useful functionality. We could possibly do it if we restrict to ASCII-superset character sets (not UTF-16 for instance), so that the string quoting boundaries can be found without hardwired knowledge about every character set. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] rotatelogs integration in pg_ctl
Thomas Swan wrote: Would there be any interest in modifying postmaster to support native file logging in addition to stderr and stdout output? Are there any terrible drawbacks that you could foresee? We have about 8 years of mailing list archives describing them. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] FRONTEND in ecpg
Magnus Hagander wrote: Hi! Is there any reason why FRONTEND is not specified in the ecpg build (specifically the pgtypeslib)? I'm running into build problems because it pulls backend-specific stuff from port.h in (postgres_fe.h-c.h-port.h) when tweaking the timezone code. Or should FRONTEND perhaps even be explicitly #defined in postgres_fe.h? You know, that is an excellent idea. I have been adding FRONTEND to specific Makefiles just in cases where I need special src/port compiles of files, but putting it in postgres_fe.h would hit all of them nicely. Let me make that change now. -- 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 7: don't forget to increase your free space map settings
Re: [HACKERS] FRONTEND in ecpg
Magnus Hagander wrote: Hi! Is there any reason why FRONTEND is not specified in the ecpg build (specifically the pgtypeslib)? I'm running into build problems because it pulls backend-specific stuff from port.h in (postgres_fe.h-c.h-port.h) when tweaking the timezone code. Or should FRONTEND perhaps even be explicitly #defined in postgres_fe.h? Or am I misunderstanding what FRONTEND is for? Looking now, it is a chicken and egg thing. Some port/src C files need to know which file to include: #ifndef FRONTEND #include postgres.h #else #include postgres_fe.h #endif so it looks like we have to a keep adding to Makefiles. Sorry. -- 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 7: don't forget to increase your free space map settings
Re: [HACKERS] Lexing with different charsets
Tom Lane wrote: Dennis Bjorklund [EMAIL PROTECTED] writes: My next question is about lexing. The spec says that one can use strings of different charsets in the queries, like: ... WHERE field1 = _latin1'FooBar' and field2 = _utf8'Åäö' I can see that the lexer either needs to be taught about all the different charsets or this is not going to work very well. Yeah. I'm not sure that we're ever going to support that part of the spec; doing so would break too many useful things without adding very much useful functionality. Like what? I think it could be fairly useful. We would have to restrict ourselves to character sets that are supersets of ASCII, but there are boatloads of reasons to do that besides this issue. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Lexing with different charsets
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane wrote: Yeah. I'm not sure that we're ever going to support that part of the spec; doing so would break too many useful things without adding very much useful functionality. Like what? The first things that came to mind were losing psql's ability to tell what's a literal, losing the existing capability for queries to be translated from client-side to server-side character set, and losing the capability to have character sets defined by plug-in extensions rather than being hard-wired into the lexer. (Before you claim that the last is easily solved, consider that the lexer is not allowed to do database accesses.) I think it could be fairly useful. We would have to restrict ourselves to character sets that are supersets of ASCII, but there are boatloads of reasons to do that besides this issue. If we do that then some of the problems go away, but I'm not sure they all do. Are you willing to drop support for non-ASCII-superset character sets on the client side as well as the server? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] FRONTEND in ecpg
Bruce Momjian [EMAIL PROTECTED] writes: Or should FRONTEND perhaps even be explicitly #defined in postgres_fe.h? You know, that is an excellent idea. I have been adding FRONTEND to specific Makefiles just in cases where I need special src/port compiles of files, but putting it in postgres_fe.h would hit all of them nicely. There are some source files that #include c.h instead of either postgres.h or postgres_fe.h; this would *not* hit those. Let me make that change now. Better test before committing. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Lexing with different charsets
On Tue, 13 Apr 2004, Tom Lane wrote: We could possibly do it if we restrict to ASCII-superset character sets (not UTF-16 for instance), so that the string quoting boundaries can be found without hardwired knowledge about every character set. It's a reasonable compromise I guess. One can still support utf-16 and others using the new wire protocol and maybe with some escaping extension like: _utf16 H'a42a1121311' where H would be a way to form a string from hexencoded bytes (or using the same as for bytea, or whatever). It's a problem for the future. -- /Dennis Björklund ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Remove MySQL Tools from Source?
Folks, I'm thinking it's time to remove the MySQL conversion tools from the PostgreSQL source tree and put them somewhere they might be maintained. I've just done some testing, and neither one works with current versions of MySQLdump. -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] 7.5 beta version
On Mon, Apr 12, 2004 at 10:00:05PM +0200, Jeroen T. Vermeulen wrote: On Mon, Apr 12, 2004 at 12:35:15PM -0700, Dann Corbit wrote: I do know of important differences in compilers in this regard. You can (for instance) have 80 bit floating point on one compiler using double but it is only 64 bits on another. But in the case of x86 (among others) that's the in-register representation, no? IIRC they are stored to memory as 64-bit doubles at best. You also have long doubles on some compilers which could be 80 bit. In C++, ABI compatibility is normally protected through a side effect of name mangling. By maintaining different name mangling schemes for different ABI conventions, compiler vendors ensure that object files will refuse to link to other object files that adhere to different ABIs. We gave up trying to make C++ dlls on windows because of ABI/name mangling problems, never tried it again though. The compilers from Microsoft and Borland atleast aren't compatible. Kurt ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] make == as = ?
Fabien COELHO [EMAIL PROTECTED] wrote: Dear Josh, Thanks for you reply at length. It helps me understand the raw about my suggestion. Some short comments and joke signs: Adding == would cause harm in the following three ways: 1) It would impair portability between PostgreSQL and other databases that support the SQL standard. Oracle, M$ and others spend a lot of energy so that what you write for their tool won't be so easilly portable, thus once you've started with them, you'll stay forever. You're arguing that pg should help its customers to leave it easilly, what is quite paradoxical! ;-) [remainder elided] Perhaps the PostgreSQL community is sufficiently confident in the quality of its product that it doesn't feel the need to resort to odious lock-in tricks? ;) Jim ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Lexing with different charsets
I've spent some more time reading specs today. Together with Peter E's explanataion (Thanks!) I think I've got a farily good understanding of the parts talking about locales now. My next question is about lexing. The spec says that one can use strings of different charsets in the queries, like: ... WHERE field1 = _latin1'FooBar' and field2 = _utf8'Åäö' In my understanding this was removed as of SQL:1999. I'm not sure about SQL:2003 though. -- Tatsuo Ishii I can see that the lexer either needs to be taught about all the different charsets or this is not going to work very well. What if one wants to include a string in utf-16 in the query, the lexer can not handle that without understanding utf-16. The query can also be in different charsets. If it's in utf-8 for example, then we can not embed latin1 strings and still have a validating utf-8 query. With the above we can not think of the query as being in a single charset anymore. That's strange but okay I guess. The new wire protocol allows us to send data seperatly from the query which is nice, but the standard talked about strings as above so it's not a solution to the problem. Maybe I should have adressed this to Peter directly :-) -- /Dennis Björklund ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(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] Lexing with different charsets
On Wed, 14 Apr 2004, Tatsuo Ishii wrote:
I've spent some more time reading specs today. Together with Peter E's
explanataion (Thanks!) I think I've got a farily good understanding of the
parts talking about locales now.
My next question is about lexing. The spec says that one can use strings
of different charsets in the queries, like:
... WHERE field1 = _latin1'FooBar' and field2 = _utf8'Åäö'
In my understanding this was removed as of SQL:1999. I'm not sure
about SQL:2003 though.
AFAICS, it still basically has:
character string literal ::=
[ introducercharacter set specification ]
quote [ character representation... ] quote
[ { separator quote [ character representation... ] quote }... ]
---(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] PostgreSQL configuration
On Tuesday 13 April 2004 01:14, Kevin Brown wrote:
Tom Lane wrote:
snip
To be honest, I think the use of the PG_DATA environment variable is the
biggest impediment to self documentation - the postmaster should not
use it.
The reason is that if PG_DATA is used to specify the location of the
data directory, you won't be able to find out where a running
postmaster's data directory is located without doing some heavy-duty
investigation. Not all operating systems make it possible to determine
the values of a particular process' environment variables.
I think this is another vote for store the PGDATA dir value inside a running
postgresql so you can query the running database to find out what datafiles
it is using.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(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] PostgreSQL configuration
Robert Treat [EMAIL PROTECTED] writes: On Tuesday 13 April 2004 01:14, Kevin Brown wrote: To be honest, I think the use of the PG_DATA environment variable is the biggest impediment to self documentation - the postmaster should not use it. I think this is another vote for store the PGDATA dir value inside a running postgresql so you can query the running database to find out what datafiles it is using. I agree --- we could answer this by adding some readout capability (think show datadir) rather than by taking away functionality. Personally I rely quite a lot on setting PGDATA to keep straight which installation I'm currently working with, so I'm not going to be happy with a redesign that eliminates that variable without providing an adequate substitute :-( 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] [GENERAL] Join works in 7.3.6, fails in 7.4.2
I wrote: Michael Fuhr [EMAIL PROTECTED] writes: I have a query that works in 7.3.6 but not in 7.4.2 unless I turn off enable_hashjoin. I'm joining a table of network interfaces and a table of networks so I can find additional info about a particular interface's network. Hmm. The inet = operator is marked hashable in 7.4 but not in 7.3 ... I wonder if that is a mistake? Digging further, I find that indeed this seems to be a mistake. CIDR and INET values that have the same address and masklen compare as equal according to network_eq(), but they will not hash the same because there's a flag identifying whether a given value is considered CIDR or INET. And what the network() function returns is marked as a CIDR. It's a bit surprising that your hash join produces any matches at all... I believe I got misled on this because there is a hash index operator class for inet; at one point during the 7.4 cycle I went around and cleaned up cases where the equality operator's canhash flag was inconsistent with the set of hash index opclasses. Arguably the hash opclass is broken, although in practice people probably don't notice the failure since a given column is likely to contain either all inet or all cidr values. (And of course it's entirely likely that there *aren't* any people using the inet hash opclass, period...) I can think of a number of possible fixes: 1. Mark inet = as not hashjoinable. We'd probably want to remove the inet hash opclass too. 2. Redefine inet = so that CIDR and INET values are never considered equal, thus eliminating the unused field. This could be back-patched into 7.4 but otherwise seems to have little to recommend it. It would certainly not help solve Michael's problem. 3. Provide a specialized hash method for type inet that ignores the iptype field. #3 seems the most desirable going forward, but is probably impractical to back-patch into 7.4.*, so I'm not sure what to do about the problem in that branch. Given the relatively low incidence of the problem, maybe it's okay to just clear the oprcanhash flag in future 7.4.* releases. This would not fix the problem for existing installations (unless they initdb) but any complainers could be told how to adjust their catalogs manually. Can anyone think of any other approaches? 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] Remove MySQL Tools from Source?
Josh Berkus [EMAIL PROTECTED] writes: I'm thinking it's time to remove the MySQL conversion tools from the PostgreSQL source tree and put them somewhere they might be maintained. I've just done some testing, and neither one works with current versions of MySQLdump. Hmm ... seems like the big question is not where to keep them but who's gonna maintain them ... without active maintenance they're just dead bits wherever they're stored, because MySQL and Postgres are both moving targets. These tools are a not insignificant part of our Plan for World Domination ;-) so it would be good if somebody stepped up to the plate and volunteered to take care of 'em. Anybody? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
