Alvaro Herrera <[EMAIL PROTECTED]> writes:
> This patch removes the unnecesary TRANS_* states that supposedly
> represented "low level transaction state". The state is actually
> unnecesary because the states can be accurately represented using the
> TBLOCK_* states.
Really?
Your changes to Star
> Your patch has been added to the PostgreSQL unapplied patches list at:
Bruce, please cancel the original patch.
The attached patch is for (possible) application to HEAD, following
meritocratic "contest" [socket.c for src/port]
Been iterating with Magnus extensively off-list, and he is well on
Patchers,
This patch removes the unnecesary TRANS_* states that supposedly
represented "low level transaction state". The state is actually
unnecesary because the states can be accurately represented using the
TBLOCK_* states. This simplifies the code somewhat.
It also allows the state machiner
Kris Jurka <[EMAIL PROTECTED]> writes:
> Compiling with ssl without thread safety still broken.
> pq_initssllib is being incorrectly guarded by ENABLE_THREAD_SAFETY.
Not to mention that it has NO business being declared at some random
place in the middle of the file. Fix committed, but some furth
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> The third option is to redefine all these functions into our own, and
> implement our own emulation layer. This means our own select(), send(),
> recv() (more? I don't think so). And have these call the native winsock
> APIs (WSAEventSelect(), WSASend
>> The third option is to redefine all these functions into our own, and
>> implement our own emulation layer. This means our own
>select(), send(),
>> recv() (more? I don't think so). And have these call the
>native winsock
>> APIs (WSAEventSelect(), WSASend(), WSARecv() etc). These
>functions
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> I *think* we can do a better job with a not-so-large amount of effort,
> ...
> I'm willing to give it a try. If it turns out to be a lot of work, or
> way too much code, I'll drop the idea.
Sure, give it a shot and see what you get.
Compiling with ssl without thread safety still broken.
pq_initssllib is being incorrectly guarded by ENABLE_THREAD_SAFETY.
Kris JurkaIndex: src/interfaces/libpq/fe-secure.c
===
RCS file: /projects/cvsroot/pgsql-server/src/interfaces
I uploaded from pgsql-server/contrib./dbmirror on postgresql.org. I'm not
sure who the package is being maintained or not but I may have found a small
bug which I have a fix for. I use SERIAL types (sequences) to create unique
number id's in my database and got several errors when they were bein
Hi all,
Magnus Hagander wrote:
> The third option is to redefine all these functions into our own, and
> implement our own emulation layer. This means our own select(), send(),
> recv() (more? I don't think so). And have these call the native winsock
> APIs (WSAEventSelect(), WSASend(), WSARecv()
Claudio Natoli <[EMAIL PROTECTED]> writes:
> ... However, it just occured to me that
> we could wrap select() by augmenting the read_mask with an addition socket,
> that we know will never be touched, and checking this socket on a "valid"
> return. If this socket is still set, we know we got bitten
Tom Lane wrote:
> Claudio Natoli <[EMAIL PROTECTED]> writes:
> > ... However, it just occured to me that
> > we could wrap select() by augmenting the read_mask with an
> addition socket,
> > that we know will never be touched, and checking this
> socket on a "valid"
> > return. If this socket is
> Tom Lane wrote:
> > What happens if the socket() call fails?
>
> Then we return in error. Refer to attachment.
Doh. You *were* referring to the attachment. Ok, so it'll need a check to
make sure the socket actually does get created, but this isn't a fatal flaw,
right? [is a work in progress
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>>> Hopeless, or cute, work-around?
>>
>> It's possibly workable in the limited context of the postmaster, but
>> I've got doubts about doing it in libpq where we can't assume we know
>> what the surrounding application will do.
> No need to touch the
Tom Lane wrote:
> > No need to touch the frontend parts at all. Our APCs are server side
> > only, so it's not a problem there.
>
> Oh really? What if the surrounding app uses APCs?
To my mind, that's actually a vote *for* the work-around, and in /port (in
order to have it propagate to all fron
Claudio Natoli <[EMAIL PROTECTED]> writes:
> Hopeless, or cute, work-around?
It's possibly workable in the limited context of the postmaster, but
I've got doubts about doing it in libpq where we can't assume we know
what the surrounding application will do.
regards, tom la
>> I don't think it's a good idea in general to redefine something as
>> fundamental as select, send, recv etc from libpq-fe.h (or
>files included
>> from there).
>
>Certainly not; the redefinition would have to be in files that are not
>part of the exported API. However this is not difficult.
Hopeless, or cute, work-around?
>>>
>>> It's possibly workable in the limited context of the postmaster, but
>>> I've got doubts about doing it in libpq where we can't
>assume we know
>>> what the surrounding application will do.
>
>> No need to touch the frontend parts at all. Our APCs are
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>>> No need to touch the frontend parts at all. Our APCs are server side
>>> only, so it's not a problem there.
>>
>> Oh really? What if the surrounding app uses APCs?
> Then I'd say it's that apps problem. And it's clearly nothing new - the
> proble
>> Hopeless, or cute, work-around?
>
>It's possibly workable in the limited context of the postmaster, but
>I've got doubts about doing it in libpq where we can't assume we know
>what the surrounding application will do.
No need to touch the frontend parts at all. Our APCs are server side
only, so
With most of the Win32 code done, I expected this type of review to see
how we could clean things up further. It would probably be helpful for
folks to poke around and suggest cases where we can generalize or move
things to /port or /backend/port.
>> Ugh. Is there a way we can insert a wrapper layer without
>modifying the
>> call sites? I'm thinking of some kind of macro hack, say
>> [snip]
>
>Sure. Think we've even done this before (also, prevents
>developers needing to remember to use pg_*).
Yup, it's done to redefine kill() to pqkill
> Possibly. The case that I thought was a real bad idea was actually the
> one in def_arg --- we don't want that doing any behind-the-scenes
> translation of words to other things. The ORDER BY case is just silly.
Ok. So the current code is silly, but the patch must be sound;-)
> > Or the rule
Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
[snip]
>
> OK, patch attached and applied. It adds configure tests for the 5-arg
> version of getpwuid_r() and properly falls back to the Posix draft
> version you have on Solaris. Seems Solaris 9 also still has the draft
> version.
[snip]
Well, yes a
I have again updated my two-phase commit patches. Only minor
modifications.
I haven't received any comments and there hasn't been any discussion on
the implementation, I suppose that nobody has given it a try. :(
There is still some rough edges, but I think it's good enough as a first
cut. I pers
Fabien COELHO <[EMAIL PROTECTED]> writes:
>> This seems to allow a whole lot of unintended and probably uncool things
>> as well. "ORDER BY NOT LIKE", for instance.
> Well, it seemed to me (maybe I'm wrong here/) that "ORDER BY !~~" was
> allowed anyway by the parser, so I cannot see why it shoul
26 matches
Mail list logo
