Michael Meskes wrote:
> On Thu, Apr 25, 2002 at 12:42:00PM +0100, Lee Kindness wrote:
>>Should the input pointers be NULL initialised? How should the memory
>>be freed?
>
>
> A simple free() will do. You also can free all automatically
> allocated memory from the most recent executed statement b
Marc G. Fournier wrote:
> hr ... do you have a working Windows development environment? I'm
> running WinXP at home, but don't have any of the compilers or anything
> yet, so all my work for the first part is going to be done under Unix ...
>
> but someone that knows something about buildin
Lee Kindness wrote:
> Okay, lets see if i've got this right...
>
> If I allocate the memory before the FETCH then I (naturally) free
> it. However If I NULL initialise the pointer then libecpg will
> allocate the memory and I must NOT free it - libecpg will free it
> automatically... Yeah?
No, I
Neil Conway wrote:
(6) Protocol-level support for prepared queries, in order to
bypass the parser (and maybe be more compatible with the
implementation of prepared queries in other databases).
Let me add
(6b) Protocol level support for query parameters. This wou
Christof Petig wrote:
Neil Conway wrote:
(6) Protocol-level support for prepared queries, in order to
bypass the parser (and maybe be more compatible with the
implementation of prepared queries in other databases).
Let me add
(6b)Protocol level support
"Marc G. Fournier" wrote:
> Okay, its updated effective a few minutes ago ... and the upate should
> work as well ...
Should ...
~/pgsql-cvs/pgsql/src/interfaces/ecpg/preproc > cvs status preproc.y
cvs server: failed to create lock directory for
`/projects/cvsroot/pgsql/src/interfaces/ecpg/prep
Chamanya wrote:
> I am currently building a small web based app, with postgres as back end. I
> found that in ecpg you can declare and use cursor without declaring a
> transaction. In several places I have used cursors for selects only. That's
> the only way I found to make ecpg fetch multiple ro
Haller Christoph wrote:
> My first message:
> In a C application I want to run several
> insert commands within a chained transaction
> (for faster execution).
> >From time to time there will be an insert command
> causing an
> ERROR: Cannot insert a duplicate key into a unique index
>
> As a re
Michael Meskes wrote:
> On Tue, Oct 16, 2001 at 10:27:42AM +0100, Lee Kindness wrote:
> > And the patch below corrects a pet peeve I have with ecpg, all errors
> > and warnings are output with a line number one less than reality...
>
> I wish I knew where this comes from. I've been trying to trac
Hi Bruce,
you might add that I did the following useful enhancement to ECPG:
- EXECUTE ... INTO ...implemented
- multiple row descriptor support (e.g. CARDINALITY)
I don't feel that my humble contribution of a few lines is important but
the improvement made really is important (n times perf
Tom Lane wrote:
> >> Well at least on glibc-2.2 it seems that setlocale retuns a pointer to
> >> malloced memory, and frees this pointer on subsequent calls to
> >> setlocale.
> >> So I would kindly ask you to take a second look at every invokation of
> >> setlocale.
>
> I looked around, and am w
Michael Meskes wrote:
> On Thu, Sep 27, 2001 at 12:08:29AM -0400, Tom Lane wrote:
> > I looked around, and am worried about the behavior of PGLC_current()
> > in src/backend/utils/adt/pg_locale.c. It doesn't change locale but
> > does retrieve several successive setlocale() results. Does that w
"Marc G. Fournier" wrote:
> should be four hours, but I haven't had a chance, with the newest
> worm/virus going around right now having killed our core router yesterday,
> to redirect the sync'ag with the new server ... will do that first thing
> tomorrow ...
>
> On Wed, 19 Sep 2001, Tom Lane wr
Christopher Kings-Lynne wrote:
> > While you're at it, could you please fix this error:
> >
> > ~/pgsql-cvs/pgsql > cvs -z3 update -dP
> > cannot create_adm_p /tmp/cvs-serv2966/ChangeLogs
> > Permission denied
>
> Instead of checking out over your existing checkout, checkout to a new dir
> and th
Hi Bruce, Hi Michael,
here is the really short patch for shutting out all postgres definitions
from ecpg
programs. (e.g. Datum, Pointer, DEBUG, ERROR).
Someone really should take a look into libpq and do the same.
But I had to copy a small part of c.h (bool,true,false,TRUE,FALSE) into
ecpg/includ
Denis Perchine wrote:
> Hello,
>
> Having some expirience with catching errors with BLOBs, I realised, that it
> is really hard to understand that you forget to enclose BLOB operations in
> transaction...
>
> I would like to add a check for each BLOB operation which will check whether
> we are in
Karel Zak wrote:
> On Thu, 2 Nov 2000, Zeugswetter Andreas SB wrote:
>
> >
> > > Well I can re-write and resubmit this patch. Add it as a
> > > compile time option
> > > is not bad idea. Second possibility is distribute it as patch
> > > in the contrib
> > > tree. And if it until not good tested
Karel Zak wrote:
> On Fri, 3 Nov 2000, Christof Petig wrote:
>
> > Karel Zak wrote:
> >
> > > On Thu, 2 Nov 2000, Zeugswetter Andreas SB wrote:
> > >
> > > >
> > > > > Well I can re-write and resubmit this patch. Add it as a
Karel Zak wrote:
> On Wed, 8 Nov 2000, Christof Petig wrote:
>
> > Karel Zak wrote:
> >
> > > > What about parameters? Normally you can prepare a statement and execute it
> > >
> > > We have in PG parameters, see SPI, but now it's used i
Maurizio wrote:
> But, how can I do ?
> I have to recall the same routine many times. I tried to prepare and declare
> the cursor inside the routine but when I compile with ecpg I receive the
> error Cursor already defined.
you should drop the cursor (exec sql close name;)
But there is trouble a
Zeugswetter Andreas SB wrote:
> > PS: You might consider applying the patch for (update where > not_found) -> 100
>
> No, this is not allowed. sqlcode is supposed to be 0 in above case.
> You need to explicitly check for the number of rows updated in your
> program if needed.
>
> Andreas
Accordi
x27;ve frequently had
questions on the lists where it was interesting to know if any
transactions were being held open --- and right now there's no easy
way to tell.
regards, tom lane
--
Subject: Small patch to replace 'idle' by 'trans&#x
Hello,
We noticed that after upgrading to 7.1beta[245] the execution time for
some often used queries went up by a factor of 2 or more. Considering
the early beta state I was not alarmed. But since I noticed that
yesterday's snapshot still has the problem, I'd really like to tell you
about it.
H
Justin Clift wrote:
> Hi Christof,
>
> I'm not aware of the problem with int2 indexes collapsing. Can you give
> me some more info, and I'll put it on the techdocs.postgresql.org
> website.
Oh, I'm sorry for my strange wording.
I said that the index search collapses to a sequential scan if you
Hello,
We noticed that after upgrading to 7.1beta[245] the execution time for
some often used queries went up by a factor of 2 or more. Considering
the early beta state I was not alarmed. But since I noticed that
yesterday's snapshot still has the problem, I'd really like to tell you
about it.
H
Justin Clift wrote:
> Hi Christof,
>
> I'm not aware of the problem with int2 indexes collapsing. Can you give
> me some more info, and I'll put it on the techdocs.postgresql.org
> website.
Oh, I'm sorry for my strange wording.
I said that the index search collapses to a sequential scan if you
Zeugswetter Andreas SB wrote:
> > Here is one of the queries, it takes about half a second on our computer
> > (PII 233 with 256MB RAM) to execute and returns typically 1-4 rows via
> > two index scans with high selectivity. So it looks to me that planning
> > time outwages execution time by far.
Tom Lane wrote:
> Christof Petig <[EMAIL PROTECTED]> writes:
> > We noticed that after upgrading to 7.1beta[245] the execution time for
> > some often used queries went up by a factor of 2 or more.
>
> I get the desired plan after doing VACUUM ANALYZE ...
>
>
Barry Lind wrote:
3) Protocol level support for CURSORs. It would be nice if cursor
support was done at the protocol level and not as a SQL command.
I want to second this proposal. Currently I avoid using cursors in my
programs since
a) they need much more logic and _string_concatenation_ to be
Tom Lane wrote:
Barry Lind <[EMAIL PROTECTED]> writes:
The describe request is generally only
done once even though you may do multiple fetchs (unlike todays protocol
which includes the describe information on every fetch, even if you are
fetching one row at a time).
I'm less than excited abou
Christof Petig wrote:
If you know you are never interested in metadata, you can omit the
describe flag at all. [null indication and type specification is of
course always needed to access the actual data]
More exactly they are sent separately:
null indication is per row 'D'/&#
Peter Eisentraut wrote:
I don't get it. Say I execute SELECT a, b, c FROM foo;. In order to
update that query, the application needs to create some update statement,
say UPDATE foo SET a = entered_value;. So the application already knows
that "foo" is the table and "a" is the column. So if the
Tom Lane wrote:
Sebastien Lemieux <[EMAIL PROTECTED]> writes:
Then I get:
ERROR: Can't find function add_one in file /[PathToTheObject]/pgsql_bio.so
Hmm. I can't see anything wrong with what you did, either.
It's possible that the dynamic linker has printed additional messages to
the backend'
Rod Taylor schrieb:
Is this syntax ok?
ALTER TABLE ALTER COLUMN TYPE
shouldn't that be
ALTER TABLE ALTER [COLUMN] [TYPE]
which I clearly remember from different database systems.
Christof
---(end of broadcast)---
T
Bruce Momjian schrieb:
Peter Eisentraut wrote:
Bruce Momjian writes:
Oh, I forgot about that. This leaves datetime.h and decimal.h in
/pgsql/include. I don't see how 7.4.1 can fix that because people will
not be using initdb.
This has nothing to do with initdb.
Right. I mean install isn't g
Tatsuo Ishii wrote:
> > On Fri, Sep 22, 2000 at 03:31:59PM +0900, Tatsuo Ishii wrote:
> > > pgc.o(.text+0x582): undefined reference to `pg_mbcliplen'
> > > pgc.o(.text+0x953): undefined reference to `pg_mbcliplen'
> > > ...
> > > pg_mbcliplen cannot be used in the frontend. Remove them, please.
>
Magnus Hagander wrote:
> If you do decide to prefix DEBUG, please consider prefixing at least ERROR
> as well. It produces a lot of warnings when compiling on Win32 (ERROR is
> already defined as part of the standard windows headers). It's just
> warnings, though.
>
> //Magnus
>
> > Do other peop
"Vladimir V. Zolotych" wrote:
> Hello all,
>
> Compile with
> $ g++ -I/usr/local/qt/include -o days.so -shared days.cpp
IIRC you have to compile as days.o and then link to .so:
g++ -o days.o
ld -shared -o days.so days.o
I don't know if the compiler gets it right in one line. It might.
C
Bruce Momjian wrote:
> > > > > PostgreSQL would probably "play" better with other products if
> > > > > the DEBUG macro had a prefix, maybe PGSQLDEBUG or similar.
> > > > >
> > > > > Until there is some fix in this area, plperl will not build with
> > > > > a version of perl that has debugging en
Michael Meskes wrote:
> What do other DBs do with their output variables if there is an embedded SQL
> query resulting in a NULL return value? What I mean is:
>
> exec sql select text into :txt:ind from ...
>
> If text is NULL, ind will be set, but does txt change?
>
> I was just told Informix bl
40 matches
Mail list logo
