On Sunday 18 January 2009 08:24:47 Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On Thursday 15 January 2009 02:08:42 Bruce Momjian wrote:
Added to TODO:
Have statement-level triggers fire for all tables in an
inheritance hierarchy
I don't think that was really the
On Sunday 18 January 2009 08:28:51 Tom Lane wrote:
Yeah, the risk this is trying to guard against is variables containing
% unexpectedly. Even if that's not possible, it requires some work
to verify and it's a bit fragile. I didn't look at the specific cases
yet but in general I think this
One thing to watch out for is that the intention may have been to allow
the strings to be translated.
regards, tom lane
I'm not sure if that's the case. How does one find out?
Alan
On 2009-01-18, at 09:56, Peter Eisentraut wrote:
On Sunday 18 January 2009 08:28:51 Tom Lane wrote:
Yeah, the risk this is trying to guard against is variables
containing
% unexpectedly. Even if that's not possible, it requires some work
to verify and it's a bit fragile. I didn't look at
On Jan 17, 2009 3:34pm, Peter Eisentraut pete...@gmx.net wrote:
On Saturday 17 January 2009 11:44:07 Alan Li wrote:
Attached are patches to fix the following compiler warnings that I see
when
using gcc 4.3.2.
MASTER warning:
tablecmds.c: In function 'DropErrorMsgWrongType':
On Sat, Sep 27, 2008 at 4:25 AM, Brendan Jurd dire...@gmail.com wrote:
Currently, Postgres accepts four separate flavours for specifying
meridiem markers, given by uppercase/lowercase and with/without
periods:
* am/pm
* AM/PM
* a.m./p.m.
* A.M./P.M.
I would go so far as to say that
Tom Lane wrote:
Andrew Chernow a...@esilo.com writes:
Any objections adding the below to postgres.h?
#define VARLEN(PTR) (VARSIZE(PTR) - VARHDRSZ)
For the most part, you should probably be using VARSIZE_ANY_EXHDR
anyplace that that might be a good idea.
regards, tom
Grzegorz Jaskiewicz wrote:
On 2009-01-18, at 09:56, Peter Eisentraut wrote:
-Wformat-security warns about
printf(var);
but not about
printf(var, a);
I don't understand that; the crash or exploit potential is pretty much
the
same in both cases.
not at all. First case allows you to
alan...@gmail.com writes:
One thing to watch out for is that the intention may have been to allow
the strings to be translated.
I'm not sure if that's the case. How does one find out?
If the origin of the variable format is a constant or set of constants
decorated with gettext_noop(), then
Tom Lane t...@sss.pgh.pa.us writes:
The really nasty cases are like this:
const char *myfmt = gettext_noop(Some bleat about object \%s\.);
...
errmsg(myfmt, objectname)
where there really is no simple way to convince the compiler that you
know what you're doing without
Tom Lane wrote:
alan...@gmail.com writes:
One thing to watch out for is that the intention may have been to allow
the strings to be translated.
I'm not sure if that's the case. How does one find out?
If the origin of the variable format is a constant or set of constants
decorated with
Andrew Chernow wrote:
Magnus Hagander wrote:
Andrew Chernow wrote:
WSACleanup is not really needed during a PQfinish. Its horribly slow if
the library ref count is 0 and it actually unloads the winsock library,
adds 225ms to PQfinish.
Solution:
A) Call WSAStartup once and never clean it
Gregory Stark st...@enterprisedb.com writes:
Tom Lane t...@sss.pgh.pa.us writes:
The really nasty cases are like this:
const char *myfmt = gettext_noop(Some bleat about object \%s\.);
...
errmsg(myfmt, objectname)
It makes sense to me: if you have arguments for the format string then
Magnus Hagander mag...@hagander.net writes:
Yeah. So the question is, do we want to bite the bullet and create
init() and uninit() functions for libpq?
I think if calling them is an optimization that improves performance
(by eliminating per-connection-start overhead), this could fly. If
the
On Sunday 18 January 2009 21:15:28 Tom Lane wrote:
BTW, does the gettext infrastructure make any checks to ensure that
translators didn't bollix the format codes? It seems like that should
be doable with just a SMOP, but I don't know if it's in there or not.
Yes, that is all taken care of.
On Sunday 18 January 2009 12:43:46 Grzegorz Jaskiewicz wrote:
-Wformat-security warns about
printf(var);
but not about
printf(var, a);
I don't understand that; the crash or exploit potential is pretty
much the
same in both cases.
not at all. First case allows you to
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
Yeah. So the question is, do we want to bite the bullet and create
init() and uninit() functions for libpq?
I think if calling them is an optimization that improves performance
(by eliminating per-connection-start overhead), this
Personally, I don't think its the job of libpq to call wsa startup or
shutdown. Pulling it out now will surely break existing apps and piss
I'm afraid it is. Looking at the API docs, the very first paragraph says:
The WSAStartup function must be the first Windows Sockets function
called by an
Brendan Jurd dire...@gmail.com writes:
On Sun, Jan 18, 2009 at 5:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Interesting --- it works as expected in 8.2. The problem seems to have
been created by the introduction of arrays over composites in 8.3.
Congratulations on identifying the source!
On Mon, Jan 19, 2009 at 7:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I've applied a patch for this to HEAD and 8.3.
Cool, thanks Tom.
Just noting that I've tested your fix on both branches, and in both
cases pg_dump's output came out nice, clean and consistent.
Cheers,
BJ
--
Sent via
Magnus Hagander wrote:
The use-case of rapidly creating and dropping connections isn't
particularly common, I think. And there is a perfectly functioning
workaround - something that we should perhaps document in the FAQ or
somewhere in the documentation?
Would it be accetable to do initialise
James Mansion wrote:
If you have a DLL for libpq, could you do it in process attach and
detach? Wouldn't
that be the most common case anyway?
m$ docs indicate that wsastartup can't be called from dllmain :(
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via
Gregory Stark st...@enterprisedb.com wrote:
I don't think we can perfectly capture the meaning of these GUCs in the
name. I think our goal should be to avoid confusion between them.
I was thinking it would be clearer if the options which control *when*
autovacuum fires off a worker
On Fri, 2009-01-16 at 17:42 +0300, Teodor Sigaev wrote:
Unfortunately, that means numeric is not supportable for btree-gin
because there is no left-most value from which to start the scan. Do you
see an easy workaround to support numeric?
Hmm, let we use minimal varlena struct (with size
Andrew Chernow wrote:
m$ docs indicate that wsastartup can't be called from dllmain :(
OK, fair cop. Says it in the MSDN online version but not in the SDK 6.1
version. :-( Some helper(s)
must start threads I guess.
Re the counting and doing it on first/last socket - of course WSAStartup
On Fri, 2009-01-16 at 15:39 +0300, Teodor Sigaev wrote:
START_CRIT_SECTION();
...
l = PageAddItem(...);
if (l == InvalidOffsetNumber)
elog(ERROR, failed to add item to index page in \%s\,
RelationGetRelationName(index));
It's no use using ERROR, because it will turn
Simon Riggs wrote:
On Fri, 2009-01-16 at 22:09 +0200, Heikki Linnakangas wrote:
RecentGlobalXmin is just a hint, it lags behind the real oldest xmin
that GetOldestXmin() would return. If another backend has a more recent
RecentGlobalXmin value, and has killed more recent tuples on the page,
27 matches
Mail list logo
