Larry Rosenman <[EMAIL PROTECTED]> writes:
> Reply from SCO:
> Indeed. For "inf", "infinity", and "nan", but not
> "nan(digits)", the pointer is left at the trailing
> matched character instead of the next.
> Moreover, checking our source history, it has been
> broken this way for nearly 12 year
--On Friday, May 14, 2004 09:41:58 -0400 Tom Lane <[EMAIL PROTECTED]> wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
Reply from SCO:
Indeed. For "inf", "infinity", and "nan", but not
"nan(digits)", the pointer is left at the trailing
matched character instead of the next.
Moreover, checkin
Please find attached a patch to integrate rotatelogs into pg_ctl. I've
noticed a couple of questions about how to do this and it seems easier
(and more elegant) to solve it in code rather than in documentation. The
patch is pretty simple and I've made it reasonably self documenting. It
test for
The following patch removes an extraneous "then" from src/template/unixware:
Index: unixware
===
RCS file: /projects/cvsroot/pgsql-server/src/template/unixware,v
retrieving revision 1.36
diff -u -r1.36 unixware
--- unixware13 May
Am Freitag, 14. Mai 2004 17:35 schrieb Andrew Hammond:
> Please find attached a patch to integrate rotatelogs into pg_ctl. I've
> noticed a couple of questions about how to do this and it seems easier
> (and more elegant) to solve it in code rather than in documentation. The
> patch is pretty simpl
Thanks. Applied.
---
Larry Rosenman wrote:
> The following patch removes an extraneous "then" from src/template/unixware:
>
>
> Index: unixware
> ===
> RCS fi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Eisentraut wrote:
| Am Freitag, 14. Mai 2004 17:35 schrieb Andrew Hammond:
|
|>Please find attached a patch to integrate rotatelogs into pg_ctl. I've
|>noticed a couple of questions about how to do this and it seems easier
|>(and more elegant) to
On Wed, 2004-05-12 at 10:37, Peter Eisentraut wrote:
> In addition to the conventions that you were already told, classes starting
> with Y are reserved for PostgreSQL clients.
They are? Under what circumstances would a PostgreSQL client produce an
error code?
(No such error codes exist at the m
Andrew Hammond wrote:
> That's essentially what the patch does. It's better because it does
> it correctly instead of requiring an admin to learn how to do it
> correctly.
That is entirely unconvincing handwaving. We already have a method to
do what you propose, and it's no less correct or harde
Neil Conway wrote:
> On Wed, 2004-05-12 at 10:37, Peter Eisentraut wrote:
> > In addition to the conventions that you were already told, classes
> > starting with Y are reserved for PostgreSQL clients.
>
> They are? Under what circumstances would a PostgreSQL client produce
> an error code?
>
> (No
On Tue, 2004-05-11 at 22:56, Neil Conway wrote:
> The only convention I can see is that subclass values not defined by the
> SQL specification begin with 'P'. (This ought to be documented; barring
> any objections, I'll commit a patch stating this in errcodes.h
> explicitly).
I've applied the atta
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Eisentraut wrote:
| Andrew Hammond wrote:
|
|>That's essentially what the patch does. It's better because it does
|>it correctly instead of requiring an admin to learn how to do it
|>correctly.
|
| That is entirely unconvincing handwaving.
There w
On Fri, May 14, 2004 at 15:31:21 -0400,
Andrew Hammond <[EMAIL PROTECTED]> wrote:
>
> - - DJB's multilog requires a whole mess of configuration, and is
> difficult to run unless you're root. In which case you'd be far better
> off to use syslog anyway. It is rsync friendly
I use multilog and it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruno Wolff III wrote:
| On Fri, May 14, 2004 at 15:31:21 -0400,
| Andrew Hammond <[EMAIL PROTECTED]> wrote:
|
|>- - DJB's multilog requires a whole mess of configuration, and is
|>difficult to run unless you're root. In which case you'd be far better
Andrew Hammond wrote:
> ~From what I've seen, I have to disagree. The documentation says to "pipe
> the stderr of the postmaster to some type of log rotation program."
> which is pretty vague. It then includes an _incorrect_ example of how to
> use logrotate (logrotate rotates existing log files, i
Hackers,
Here is my current patch implementing nested transactions.
At this point I'd like some actual testing. If you have any use for
this please test it and tell me how it behaves for you. Report any
annoyances.
Still missing:
- deal with deferred triggers.
- do something with catcache refe
On Fri, May 14, 2004 at 04:41:06PM -0400, Alvaro Herrera wrote:
> Hackers,
>
> Here is my current patch implementing nested transactions.
Turns out the patch is too big and the server won't publish it.
Meanwhile, Bruce has posted it as
ftp://candle.pha.pa.us/pub/postgresql/mypatches/nested.diff
On Fri, 2004-04-30 at 23:45, Tom Lane wrote:
> MHO: you already spent more time on this than it deserves. What you
> have sounds fine.
I applied the patch in basically its current form (I added some minimal
docs and fixed a few cosmetic details). I haven't implemented variants
of it for other dat
On Fri, May 14, 2004 at 16:02:43 -0400,
Andrew Hammond <[EMAIL PROTECTED]> wrote:
>
> Yes, if you're running daemontools, then multilog is hands down the way
> to go. Is it daemontools that really wants to be root? That might be
> what I'm confusing it with. Anyway, my goal was to provide a solu
In stock PostgreSQL, you can get the database name, the username, but
not the address that the client is connecting from (a very, very useful
piece of data).
Function: inet_client_addr()
Args: none
Return type:INET (null on AF_UNIX or some catastrophic failure)
IPv6 s
This is an updated FAQ_SCO patch that inludes yesterday's changes, and also
the float4/float8 issue I raised.
Index: FAQ_SCO
===
RCS file: /projects/cvsroot/pgsql-server/doc/FAQ_SCO,v
retrieving revision 1.9
diff -u -r1.9 FAQ_SCO
--- F
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Ouch. How long has that documentation been wrong? We have pointed
> folks to that section of the docs tons of times, and no one mentioned
> that "logrotate" is really "rotatelogs", and that it is missing
> parameters?
> I have applied the following pat
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Ouch. How long has that documentation been wrong? We have pointed
> > folks to that section of the docs tons of times, and no one mentioned
> > that "logrotate" is really "rotatelogs", and that it is missing
> > parameters?
>
> > I
SQL2003 mandates that ln() and power() emit particular SQLSTATE error
codes for a few illegal combinations of arguments (in Section 6.27 of my
copy of SQL2003). This patch adds those error codes and changes the
several variants of ln() and power() to emit them as appropriate.
I didn't change log()
24 matches
Mail list logo
