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 t
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 l
On Tuesday 13 April 2004 01:14, Kevin Brown wrote:
> Tom Lane 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.
>
> The reason is that if PG_DATA is used to specify the location of th
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
> 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 quer
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 betw
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
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 Francis
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 sti
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. Th
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 postgr
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 losin
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 b
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 sho
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 sho
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.
--
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
>
> 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 r
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
unsubscribe
---(end of broadcast)---
TIP 8: explain analyze is your friend
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:
>
> 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
Fabien,
> You're arguing that pg should help its "customers" to leave it easilly,
> what is quite paradoxical! ;-)
If we're going to "embrace and extend", we need more market share first. ;-)
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast
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 i
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 t
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)---
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 t
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
> 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 yo
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 th
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
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
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
[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 l
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 distributio
35 matches
Mail list logo
