I wrote:
> Nobuhiro Iwamatsu <[EMAIL PROTECTED]> writes:
>> +#if defined(__sh__) /* Renesas SuperH */
> Do they have any longer form of that macro?
I looked into the gcc sources, and the answer seems to be "no" :-(.
So we're stuck with __sh__.
I'm still pretty skeptical about the adequacy of the
On Sun, Apr 13, 2008 at 01:42:02AM +0100, Gregory Stark wrote:
> "Gavin Sherry" <[EMAIL PROTECTED]> writes:
>
> > On Sat, Apr 12, 2008 at 07:07:48PM -0400, Tom Lane wrote:
> >> Gavin Sherry <[EMAIL PROTECTED]> writes:
> >> > I wish. It was actually thrown up when we (Greenplum) changed the macros
"Gavin Sherry" <[EMAIL PROTECTED]> writes:
> On Sat, Apr 12, 2008 at 07:07:48PM -0400, Tom Lane wrote:
>> Gavin Sherry <[EMAIL PROTECTED]> writes:
>> > I wish. It was actually thrown up when we (Greenplum) changed the macros
>> > to be inline functions as part of changing Datum to be 8 bytes.
>>
Gavin Sherry <[EMAIL PROTECTED]> writes:
>> might as well just use PG_RETURN_DATUM instead of casting twice.
> Oh of course. Updated patch attached.
Applied, thanks.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes
On Sat, Apr 12, 2008 at 07:07:48PM -0400, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > I wish. It was actually thrown up when we (Greenplum) changed the macros
> > to be inline functions as part of changing Datum to be 8 bytes.
>
> Hmmm ... Datum has been 8 bytes for many years,
Gavin Sherry <[EMAIL PROTECTED]> writes:
> I wish. It was actually thrown up when we (Greenplum) changed the macros
> to be inline functions as part of changing Datum to be 8 bytes.
Hmmm ... Datum has been 8 bytes for many years, on 64-bit machines.
What is it you're trying to accomplish by making
On Sat, Apr 12, 2008 at 06:02:39PM -0400, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > This may seem a little pedantic but I noticed a few places where we pass
> > a datum to a macro which treats the datum as a pointer. This works now
> > but might not in the future (if, say, Datu
Gavin Sherry <[EMAIL PROTECTED]> writes:
> This may seem a little pedantic but I noticed a few places where we pass
> a datum to a macro which treats the datum as a pointer. This works now
> but might not in the future (if, say, Datum were to be 8 bytes).
Yeah, definitely something to fix. I thin
This may seem a little pedantic but I noticed a few places where we pass
a datum to a macro which treats the datum as a pointer. This works now
but might not in the future (if, say, Datum were to be 8 bytes).
Thanks,
Gavin
Index: src/backend/utils/adt/varlena.c
===
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> When we get the termination signal, why can't we just set a global
> >> boolean, do a query cancel, and in the setjmp() code block check the
> >> global and exit --- at that stage we know we have released all locks and
> >> can exit c
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> When we get the termination signal, why can't we just set a global
>> boolean, do a query cancel, and in the setjmp() code block check the
>> global and exit --- at that stage we know we have released all locks and
>> can exit cleanly.
> I have implemen
Andrew Chernow <[EMAIL PROTECTED]> writes:
> The requirements for the connCreate hook are that the PGconn is ready
> for use. I am currently hooking in connectDBStart, which is dead wrong.
I looked at the "object hooks" patch and it looked like a complete mess.
AFAICS the only way you could use
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > I have an idea for this TODO item:
> >
> > * Allow administrators to safely terminate individual sessions either
> > via an SQL function or SIGTERM
> >
> > Lock table corruption following SIGTERM of an individual backend
> >
Bruce Momjian wrote:
> I have an idea for this TODO item:
>
> * Allow administrators to safely terminate individual sessions either
> via an SQL function or SIGTERM
>
> Lock table corruption following SIGTERM of an individual backend
> has been reported in 8.0.
Should the hook only be called when the conn or result was
> successfull or should the hooks be called for failed
connections/commands as well?
ISTM that the hooks should be called on success and error (doesn't
include cases where a NULL conn or result is returned). I think this
makes th
Merlin Moncure wrote:
On Fri, Apr 11, 2008 at 1:47 PM, Andrew Chernow <[EMAIL PROTECTED]> wrote:
Here are the changes to libpq. It adds the ability to register an Object
Hook and create a home-grown result. Patch adds 4 functions.
We changed the name of PQresultSetFieldValue to PQsetvalue, w
On Sun, Mar 30, 2008 at 9:39 AM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> On 25/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> > "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > > This makes me wonder whether print.c could offer something a bit more
> > > helpful to callers wishing to DIY a tab
17 matches
Mail list logo
