On Tue, Feb 28, 2006 at 12:45:18AM -0500, Bruce Momjian wrote:
I have developed a patch which creates a new pg_config.h define called
PG_VERSION_NUM, which is a number like 80200, with no beta/devel
designation. I think this will be helpful (eventually) for people
writing plug-ins.
Bruce Momjian wrote:
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Tue, Feb 28, 2006 at 12:45:18AM -0500, Bruce Momjian wrote:
I have developed a patch which creates a new pg_config.h define
called PG_VERSION_NUM, which is a number like 80200, with no
beta/devel
Peter Eisentraut wrote:
Bruce Momjian wrote:
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Tue, Feb 28, 2006 at 12:45:18AM -0500, Bruce Momjian wrote:
I have developed a patch which creates a new pg_config.h define
called PG_VERSION_NUM, which is a number like
Peter Eisentraut [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
OK, updated version of the patch attached and applied.
I still object to this. What is wrong with using the catalog version
number?
It's partially redundant, but only partially, and I agree that it'll
probably be easier for
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
OK, updated version of the patch attached and applied.
I still object to this. What is wrong with using the catalog version
number?
It's partially redundant, but only partially, and I agree that it'll
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
It's partially redundant, but only partially, and I agree that it'll
probably be easier for people to use than the catversion number.
Also, that macro block where Joe Conway compared catalog version numbers
and defined
Attached is a patch that replaces a bunch of places where StringInfos
are unnecessarily allocated on the heap rather than the stack. That is,
this is sub-optimal:
{
StringInfo str;
str = makeStringInfo();
/* use str */
pfree(str-data);
pfree(str);
}
If the StringInfo
On Mon, 2006-02-27 at 11:37 +0800, Qingqing Zhou wrote:
Does it make sense to implementation or for the tid type?
I can't get too excited about it, but I wouldn't object if someone can
see a use for it.
-Neil
---(end of broadcast)---
TIP 4:
I was very surprised by this issue as well. I am just assuming that
not many people have a c:\dev directory on their machines
where they
run postgreSQL from. That is the only way that you would be able to
open the file '/dev/tty', if the cwd is c:.
If I switch my cwd to a drive
On Sun, 2006-02-26 at 18:40 -0500, Neil Conway wrote:
Tom Lane wrote:
This sort of thing normally requires more thought than just removing
the safety check. What happens when the python code does/doesn't return
a value, in both cases (declared return type void or not)?
Attached is a
Neil Conway [EMAIL PROTECTED] writes:
Applied to HEAD. I'm still not quite satisfied with the error message:
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg(unexpected return value from plpython procedure),
errdetail(void-returning functions must
Magnus Hagander wrote:
I was very surprised by this issue as well. I am just assuming that
not many people have a c:\dev directory on their machines
where they
run postgreSQL from. That is the only way that you would be able to
open the file '/dev/tty', if the cwd is c:.
If I
So yes, it looks like this patch will be needed. A very good catch,
Robert! This one has been annoying me for a long time!
Tom - if you're unsure the patch fixes the problem, I'll
try to test
it soonest. But the problem definitly exists!
I have now tested the patch, and it
Andrew Dunstan [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
(Specifically, it's bad that we open /dev/tty for writing even if we
failed it for reading (that will create a new file), and that we don't
check if it's a tty at all).
Maybe we should stat the file and check that it's actually
(Specifically, it's bad that we open /dev/tty for writing
even if we
failed it for reading (that will create a new file), and that we
don't check if it's a tty at all).
Maybe we should stat the file and check that it's actually
a character
special device.
On any sane Unix
On Tue, 2006-02-28 at 15:26 -0500, Tom Lane wrote:
Yeah, unexpected doesn't seem the mot juste here. [...]
All good points -- thanks for the suggestions. I've applied the attached
patch to HEAD.
-Neil
***
Martijn van Oosterhout kleptog@svana.org writes:
The only thing I considered wrong with the previous patch was it's odd
behaviour w.r.t. creation of types with the same name as one in
pg_catalog. However, Tom said this is not a serious issue given the
same problem exists in many other places
I have added the attached pg_service.conf documentation to CVS HEAD and
8.1.X.
---
Mark Woodward wrote:
On Fri, Feb 03, 2006 at 08:05:48AM -0500, Mark Woodward wrote:
Like I said, in this thread of posts, yes there are
Attached is a patch that makes the message strings used in elogs and
ereports more consistent with the style guidelines: errdetail should
begin with a capital letter and end with a period, whereas errmsg should
not. Most of the corrections are for contrib/, although the patch also
fixes a few
Neil Conway [EMAIL PROTECTED] writes:
Attached is a patch that makes the message strings used in elogs and
ereports more consistent with the style guidelines:
There are one or two cannots that should be could nots in your
hit list, per the style guidelines.
While you're at it -- I noticed
On Tue, 2006-02-28 at 22:38 -0500, Tom Lane wrote:
There are one or two cannots that should be could nots in your
hit list, per the style guidelines.
While you're at it -- I noticed several of the tsearch2 messages refer
to lexem(s). The word is lexeme, the plural lexemes, so this
should
On Tue, 2006-02-28 at 14:21 -0500, Neil Conway wrote:
Attached is a patch that replaces a bunch of places where StringInfos
are unnecessarily allocated on the heap rather than the stack.
Applied to HEAD.
-Neil
---(end of broadcast)---
TIP 6:
22 matches
Mail list logo
