Dear all,
Sorry if I post in the wrong list, but I've been tortured by the
problem for quite sometime.
I've been tring for several combinations, say
BACKEND FRONTEND
MULE_INTERNAL EUC_TW
BIG5
EUC
* Tom Lane <[EMAIL PROTECTED]> [00 12:06] wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> I have to agree with Alfred here: this does not sound like a feature,
> >> it sounds like a horrid hack. You're giving up *all* consistency
> >> guarantees for a performance gain that is really g
At 20:30 11/11/00 -0500, Tom Lane wrote:
>
>The current fmgr implementation requires PL handlers to be newC or
>newInternal. That could be relaxed, but I don't see any reason to do
>so, since an old-style handler would be incapable of handling null
>arguments/results or supporting triggers.
OK,
At 21:15 11/11/00 -0500, Bruce Momjian wrote:
>
>This is interesting. It allows us to control the default behavour of
>"C". I would vote to default to 7.0-style when no version is used for
>7.1, then default to 7.1 style in 7.2 and later. We don't need
>backward C function compatibility for more
> > No. 'C' is really a misnomer, since it does NOT imply anything about
> > whether the code is in C or not --- in theory you could use any language
> > that's link-compatible with C. What LANGUAGE 'C' really implies is
> > "dynamically linked, compiled function following fmgr interface
> > con
On Sat, Nov 11, 2000 at 08:30:48PM -0500, Tom Lane wrote:
> Philip Warner <[EMAIL PROTECTED]> writes:
...
> > It does avoid "language 'evenNewerC'" in the furture.
>
> How so? It appears to me it would just move the 'evenNewerFoo'
> dirtiness to a different keyword, which would still be essent
Philip Warner <[EMAIL PROTECTED]> writes:
> Is it the PL manager stuff that requires the new interface for all
> languages, or is it up to the PL implementor to choose the language for
> their handler?
The current fmgr implementation requires PL handlers to be newC or
newInternal. That could be
At 10:55 11/11/00 -0500, Tom Lane wrote:
>
>Just outputting a warning is possible, but it still leaves you with a
>broken database after you reload your 7.0 dump file :-(. (And there
>isn't any supported way to fix it, short of reloading all your function
>definitions...) I thought about the fix
I sucessfully compiled 7.0.2 on Win 2000 recently. I had a lot of problems
when I first installed cygwin and I select default text type of DOS. When i
removed cygwin, and changed that option during install it all worked (I'm
not sure if I swited it from DOS to Unix, or from Unix to DOS). I'm n
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> I have to agree with Alfred here: this does not sound like a feature,
> >> it sounds like a horrid hack. You're giving up *all* consistency
> >> guarantees for a performance gain that is really going to be pretty
> >> minimal in the WAL context.
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> I have to agree with Alfred here: this does not sound like a feature,
> >> it sounds like a horrid hack. You're giving up *all* consistency
> >> guarantees for a performance gain that is really going to be pretty
> >> minimal in the WAL context.
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> I have to agree with Alfred here: this does not sound like a feature,
>> it sounds like a horrid hack. You're giving up *all* consistency
>> guarantees for a performance gain that is really going to be pretty
>> minimal in the WAL context.
> It does n
* Gary MacDougall <[EMAIL PROTECTED]> [00 11:28] wrote:
> I'm trying to compile postgresql on Windows 2000. I've followed the directions
>accordingly.
>
> When I run the "configure" script, and I get the following error message:
>
>
> configure: error installation or configuration proble
I'm trying to compile postgresql on Windows
2000. I've followed the directions accordingly.
When I run the "configure" script, and I get the
following error message:
configure: error installation or configuration
problem: C compiler cannot create executables.
If anyone has any clues
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Not really, I thought an ack on a commit would mean that the data
> >> is actually in stable storage, breaking that would be pretty bad
> >> no?
>
> > The default is to sync on commit, but we need to give people options of
> > several seconds delay
At 06:35 PM 11/11/00 +0200, Hannu Krosing wrote:
>I took only a brief look at them, so i may be in a state of
>misunderstanding :)
>
>As I understand it, the patent is about generating/composing queries
>_before_
>submitting them to backend, not about query processing in the backend.
Yes, it's
Hans Schou wrote:
>
> Hi
>
> I hope this is the right list to write to.
>
> A danish company just got a patent which we at SSLUG www.sslug.dk do not
> think is a new invention.
>
> I want to get in contact with somebody who can confirm that this patent is
> not new and has been in PostgreSQL b
Hi
I hope this is the right list to write to.
A danish company just got a patent which we at SSLUG www.sslug.dk do not
think is a new invention.
I want to get in contact with somebody who can confirm that this patent is
not new and has been in PostgreSQL before the patent was taken.
If we can
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Not really, I thought an ack on a commit would mean that the data
>> is actually in stable storage, breaking that would be pretty bad
>> no?
> The default is to sync on commit, but we need to give people options of
> several seconds delay for performan
Philip Warner <[EMAIL PROTECTED]> writes:
> At 12:07 10/11/00 -0500, Tom Lane wrote:
>> Something's got to be done about this --- not being able to load
>> 7.0 dump files will not do.
> I assume modifying pg_dump for 7.0.x is not an option,
Not really ...
> would
> there be any value in modifyi
FINALLY, the SCO UDK Feature Supplement is released. I know
a couple of other people were waiting for it, so I figured I'd tell
people it's out.
Peter,
The released version is now on lerami.
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (
At 12:07 10/11/00 -0500, Tom Lane wrote:
>
>Something's got to be done about this --- not being able to load
>7.0 dump files will not do.
>
I assume modifying pg_dump for 7.0.x is not an option, since we really need
to support loading databases from historical dump files. If so, then would
there
Hi!
I'll be in Las Vegas (Comdex) till next week
Wednesday.
I wasn't able to implement redo for sequences but
was going to turn WAL on by default anyway.
Unfortunately, I've got core in regress:opr_sanity
test (in FileSeek code), so WAL still is not
default.
See you!
Vadim
* The Hermit Hacker <[EMAIL PROTECTED]> [001109 20:19] wrote:
> On Thu, 9 Nov 2000, Tom Lane wrote:
>
> > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > > Tom, if you can plug this one in the next, say, 48hrs (Saturday night),
> >
> > Done. Want to generate some new 7.0.3 release-candidate t
* Bruce Momjian <[EMAIL PROTECTED]> [00 00:16] wrote:
> > * Tatsuo Ishii <[EMAIL PROTECTED]> [001110 18:42] wrote:
> > > >
> > > > Yes, though we can change this. We also can implement now
> > > > feature that Bruce wanted so long and so much -:) -
> > > > fsync log not on each commit but eac
set digest
> * Tatsuo Ishii <[EMAIL PROTECTED]> [001110 18:42] wrote:
> > >
> > > Yes, though we can change this. We also can implement now
> > > feature that Bruce wanted so long and so much -:) -
> > > fsync log not on each commit but each ~ 5sec, if
> > > losing some recent commits is acceptable.
> >
>
27 matches
Mail list logo
