> [EMAIL PROTECTED] writes:
> > I have written a postgres C function that
> > uses a popen linux system call. Orginally when I first tried it I kept
> > getting an ECHILD. I read a little bit more on the pclose function
> > and the wait system calls and discoverd that on LINUX if the signal
> > h
At 18:03 21/07/01 -0400, Tom Lane wrote:
>
>Could we get away with restricting INSERT RETURNING to work only on
>inserts directly to tables (no ON INSERT DO INSTEAD allowed)? Or is
>that too much of a kluge?
>
I don't see it as a kludge, just a limitation on the first pass. If people
need the fe
Bruce Momjian <[EMAIL PROTECTED]> writes:
> At this point, I am just happy we have this WIN32 errno thing working.
My point is that it isn't "working", it's broken.
> My guess is that we should have two errno's. One the normal errno that
> is the same on Win32 and Unix and a sockerrno that is
I like the idea of adding an INSERT ... RETURNING capability,
per Philip Warner's suggestion of about a year ago
(http://fts.postgresql.org/db/mw/msg.html?mid=68704). We did not
figure out what to do if the INSERT operation is rewritten by a rule,
but I have an idea about that. ISTM that to supp
> Upon review, I don't think these patches are very good at all.
> #defining errno as WSAGetLastError() is a fairly blunt instrument,
> and it breaks all the places that do actually need to use errno,
> such as PQoidValue, lo_import, lo_export. I'm also concerned that
> PQrequestCancel may need t
Upon review, I don't think these patches are very good at all.
#defining errno as WSAGetLastError() is a fairly blunt instrument,
and it breaks all the places that do actually need to use errno,
such as PQoidValue, lo_import, lo_export. I'm also concerned that
PQrequestCancel may need to save/res
Take these queries:
select * from foo as F, (select * from bar where name = 'bla') as B where
F.name = B.name
union all
select * from foo as F, (select * from bar where name = 'bla') as B where
F.type = B.type
OR
create temp table B as select * from bar where name = 'bla';
select * from foo as
> > OK, I just applied a patch to add the final fixes to Win32 libpq.
> > Please try the CVS or later snapshot to see how it works. The patch
> > suggested adding
> >
> > #define snprintf _snprintf
> >
> > to win32.h and I have done that. There was already one there for
> > vsnprintf. I am quit
"Richard Huxton" <[EMAIL PROTECTED]> writes:
> (For those who haven't looked at that bit of the code recently
> plpgsql_read_expression() slurps up to and including a closing token -
> either a ';' or ',' above. You've then lost that finishing token)
The real problem is that this *isn't* yacc ...
"Steve Howe" <[EMAIL PROTECTED]> writes:
> ..\..\backend\lib\dllist.c(20) : fatal error C1083: Cannot open include
> file: 'sysexits.h': No such file or directory
Jan added that recently. I was wondering if it was portable or not ...
looks like now we know :-(.
For the moment, just take out the
Muggins here volunteered to get RAISE to accept any expression that
evaluates to a string rather than just a string constant. Think I can see
why it wasn't that way already.
Had a look, and this is easy enough:
RAISE NOTICE ''Hello '' || $1 || '' World'';
Also, I can do:
RAISE NOTICE ''Hello '
On Friday 20 July 2001 19:56, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > How is this search path defined? Blindly using libdir is not ok --
> Why not?
During RPM build, libdir will point to /usr/lib. This is OK and appropriate
for the generally-loadable shared libs. HOWEVER
12 matches
Mail list logo
