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:
On Tue, 2006-02-28 at 22:38 -0500, Tom Lane wrote:
> There are one or two "cannot"s that should be "could not"s 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
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 "cannot"s that should be "could not"s in your
hit list, per the style guidelines.
While you're at it -- I notic
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 mista
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
Martijn van Oosterhout 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 in PostgreSQL.
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
*** src/pl/plpython/expected/p
> >> (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
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
> >>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 tes
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
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 functi
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
> > 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
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:
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 doesn'
Bruce Momjian 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 understandable macro names c
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 agre
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
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
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
> > >
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
> > designation. I thi
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. Att
23 matches
Mail list logo
